From john.coomes at oracle.com Fri Mar 1 04:54:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:54:38 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b79 for changeset 70d8658d2a30 Message-ID: <20130301045442.DD4B4474FD@hg.openjdk.java.net> Changeset: b0224010e2f0 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b0224010e2f0 Added tag jdk8-b79 for changeset 70d8658d2a30 ! .hgtags From john.coomes at oracle.com Fri Mar 1 04:54:16 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:54:16 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b79 for changeset 91d35211e744 Message-ID: <20130301045416.5B2CC474FA@hg.openjdk.java.net> Changeset: 85b5b4cc388c Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/85b5b4cc388c Added tag jdk8-b79 for changeset 91d35211e744 ! .hgtags From john.coomes at oracle.com Fri Mar 1 04:54:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:54:21 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b79 for changeset e41fb1aa0329 Message-ID: <20130301045423.1C186474FB@hg.openjdk.java.net> Changeset: 5f3d4a6bdd02 Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/5f3d4a6bdd02 Added tag jdk8-b79 for changeset e41fb1aa0329 ! .hgtags From john.coomes at oracle.com Fri Mar 1 04:54:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:54:28 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b79 for changeset 58fa065dd5d6 Message-ID: <20130301045433.5752E474FC@hg.openjdk.java.net> Changeset: 4873a0499bc3 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/4873a0499bc3 Added tag jdk8-b79 for changeset 58fa065dd5d6 ! .hgtags From john.coomes at oracle.com Fri Mar 1 04:55:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:55:01 +0000 Subject: hg: hsx/hotspot-gc/jdk: 3 new changesets Message-ID: <20130301045622.698C5474FE@hg.openjdk.java.net> Changeset: 5245b2f1c53d Author: ngthomas Date: 2013-02-21 17:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5245b2f1c53d 8008691: Build failure (NEWBUILD=false) on Mac Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: c933505d75c2 Author: dcherepanov Date: 2013-02-26 12:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c933505d75c2 Merge Changeset: d967dd39a5ca Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d967dd39a5ca Added tag jdk8-b79 for changeset c933505d75c2 ! .hgtags From john.coomes at oracle.com Fri Mar 1 04:57:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:57:56 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b79 for changeset 56dfafbb9e1a Message-ID: <20130301045803.19EA147500@hg.openjdk.java.net> Changeset: a8227c617684 Author: katleman Date: 2013-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a8227c617684 Added tag jdk8-b79 for changeset 56dfafbb9e1a ! .hgtags From erik.helin at oracle.com Fri Mar 1 11:34:33 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 01 Mar 2013 12:34:33 +0100 Subject: RFR (S): 8009232: Improve stats gathering code for reference processor Message-ID: <51309249.3030006@oracle.com> Hi all, this change refactors the way the reference processing statistics are being collected from the reference processor. Summary: Before, the statistics were collected by calling ReferenceProcessor::collect_statistics immediately after a call to ReferenceProcessor::process_discovered_references. With this change, the method process_discovered_references instead returns the statistics. The benefit is that there is now no need to keep track of an internal state in ReferenceProcessor since the ReferenceProcessorStats can be put on the stack in process_discovered_references. Furthermore, the code is more maintainable, since the old code required the calls to process_discovered_references and collect_statistics to go "hand in hand". Now, one only has to care about the call to process_discovered_references. Webrev: http://cr.openjdk.java.net/~ehelin/8009232/webrev.00/ Bug: https://jbs.oracle.com/bugs/browse/JDK-8009232 Testing: JPRT Thanks, Erik From jesper.wilhelmsson at oracle.com Fri Mar 1 12:13:27 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 01 Mar 2013 13:13:27 +0100 Subject: RFR (S): 8008737: The trace event vm/gc/heap/summary is missing for CMS In-Reply-To: <512E46DC.5070605@oracle.com> References: <5129E024.2040900@oracle.com> <512E46DC.5070605@oracle.com> Message-ID: <51309B67.4090504@oracle.com> Looks good, ship it! /Jesper On 27/2/13 6:48 PM, Erik Helin wrote: > All, > > the previous change, webrev.00, sent two heap summary events when CMS used the > GenMarkSweep collector for doing an old GC. One heap summary events was being > sent in CMSCollector::do_compaction_work and another one in > GenMarkSweep::invoke_at_safepoint. > > Please see the following updated webrev which only sends the heap summary event > for the concurrent collector: > > http://cr.openjdk.java.net/~ehelin/8008737/webrev.01/ > > Thanks, > Erik > > On 02/24/2013 10:40 AM, Erik Helin wrote: >> Hi all, >> >> this change adds the trace event vm/gc/heap/summary to the CMS collector. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8008737/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008737 >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From erik.helin at oracle.com Fri Mar 1 14:09:22 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 01 Mar 2013 15:09:22 +0100 Subject: RFR (M): 8008918: Reference statistics events for the tracing framework Message-ID: <5130B692.6070908@oracle.com> Hi all, this change adds the vm/gc/reference/statistics event to all collectors. Please note that this change depends on "8009232: Improve stats gathering code for reference processor" which is also out for review on hotspot-gc-dev at openjdk.java.net. Webrev: http://cr.openjdk.java.net/~ehelin/8008918/webrev.00/ Bug: https://jbs.oracle.com/bugs/browse/JDK-8008918 Testing: JPRT Thanks, Erik From kevin.walls at oracle.com Fri Mar 1 17:34:02 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 01 Mar 2013 17:34:02 +0000 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event Message-ID: <5130E68A.4040806@oracle.com> Hi, I'd like some reviews on this CMS Concurrent Mode Failure event: http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ The event doesn't actually carry any new information, but it is a warning we need to capture. This is against hsx24, I'll prepare the same, or reviewed, changes against very latest hotspot also. Thanks Kevin From jon.masamitsu at oracle.com Fri Mar 1 17:54:27 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 01 Mar 2013 09:54:27 -0800 Subject: RFR: 8000754: NPG: Implement a MemoryPool MXBean for Metaspace In-Reply-To: <512E3D5E.6010200@oracle.com> References: <5124AD41.2060307@oracle.com> <5124C4C0.9060607@oracle.com> <5124FFBA.90004@oracle.com> <512E3D5E.6010200@oracle.com> Message-ID: <5130EB53.4080503@oracle.com> Erik, I'm going to have to straighten some things out in my head before I respond. There is more than a little confusion in the use of the term capacity I think so please bear with me. Jon On 2/27/2013 9:07 AM, Erik Helin wrote: > Jon, > > On 02/20/2013 05:54 PM, Jon Masamitsu wrote: >> >> On 2/20/2013 4:42 AM, Stefan Karlsson wrote: >>> Hi Erik, >>> >>> This fix seems reasonable to me. >>> >>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/src/share/vm/services/memoryPool.cpp.udiff.html >>> >>> >>> >>> +MemoryUsage MetaspacePoolBase::get_memory_usage() { >>> + size_t used = MetaspaceAux::used_in_bytes(_md_type); >>> + size_t committed = MetaspaceAux::capacity_in_bytes(_md_type); >>> + return MemoryUsage(initial_size(), used, committed, max_size()); >>> +} >>> >>> I'm not sure if capacity is the right value to use for committed, so >>> you'll need to verify that with Jon. >> >> In general we only commit memory when we allocate a chunk for that >> memory so this is mostly correct. The exception is that the >> allocation of >> a chunk smaller than a page can will cause more than the chunk size to >> be committed. I think this is the right value to use modulo a page >> size. > > I have changed the code to: > > size_t committed = > align_size_down_(MetaspaceAux::capacity_in_bytes(_md_type), > os::vm_page_size()); > > Is that what you meant? > > A new webrev can be found at: > http://cr.openjdk.java.net/~ehelin/8000754/webrev.02/ > > Thanks, > Erik > >> Jon >>> >>> thanks, >>> StefanK >>> >>> On 02/20/2013 12:02 PM, Erik Helin wrote: >>>> Hi, >>>> >>>> this change implements a new MemoryManagerMXBean, MetaspaceManager, as >>>> well as two new MemoryPoolMXBeans: Metaspace and Class Metaspace. I >>>> have >>>> also written a tests that tests the new beans. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000754 >>>> >>>> Testing: >>>> JPRT >>>> New jtreg test >>>> >>>> Thanks, >>>> Erik >>> >> > From alejandro.murillo at oracle.com Fri Mar 1 22:41:06 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 01 Mar 2013 22:41:06 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 21 new changesets Message-ID: <20130301224153.85AF7477CA@hg.openjdk.java.net> Changeset: 5d395eb2626f Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5d395eb2626f Added tag jdk8-b79 for changeset 6691814929b6 ! .hgtags Changeset: 1b0dc9f87e75 Author: mgerdin Date: 2013-02-19 18:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1b0dc9f87e75 8006753: fix failed for JDK-8002415 White box testing API for HotSpot Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileInstaller to resolve the boot class path issue Reviewed-by: ctornqvi, dsamersoff, coleenp, kvn ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/vm.make - make/bsd/makefiles/wb.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make - make/linux/makefiles/wb.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make - make/solaris/makefiles/wb.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/runtime/NMT/AllocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/SummarySanityCheck.java ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java + test/testlibrary/ClassFileInstaller.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4c1d8002ffb1 Author: hseigel Date: 2013-02-20 07:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4c1d8002ffb1 8004495: [parfait] False positive Buffer overflow in hotspot/src/os/linux/vm/os_linux.cpp Summary: Delete the questionable source code because it is for no-longer supported versions of Linux. Reviewed-by: mikael, coleenp ! src/os/linux/vm/os_linux.cpp Changeset: b861c8af2510 Author: hseigel Date: 2013-02-20 07:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b861c8af2510 Merge - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: b6d5b3e50379 Author: dcubed Date: 2013-02-20 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b6d5b3e50379 6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors. Reviewed-by: dcubed, dholmes, coleenp, acorn Contributed-by: ron.durbin at oracle.com ! src/share/vm/utilities/debug.cpp Changeset: fc64254f5579 Author: zgu Date: 2013-02-21 07:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fc64254f5579 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Summary: Added NULL pointer check for arena size record Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/memSnapshot.cpp Changeset: 5ed317b25e23 Author: sla Date: 2013-02-22 10:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5ed317b25e23 7165259: Remove BugSpot Reviewed-by: coleenp, mgronlun ! agent/make/Makefile - agent/make/bugspot.bat ! agent/make/marks_notes.html ! agent/src/os/win32/windbg/sawindbg.cpp - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp ! make/sa.files Changeset: f16e75e0cf11 Author: coleenp Date: 2013-02-22 08:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f16e75e0cf11 8000797: NPG: is_pseudo_string_at() doesn't work Summary: Zero Symbol* for constant pool strings to indicate pseudo_strings (objects that aren't strings). Clean up JVM_CONSTANT_Object and unused flags. Reviewed-by: sspitsyn, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 94478a033036 Author: sspitsyn Date: 2013-02-22 10:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/94478a033036 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp Changeset: ec2eddfed950 Author: rbackman Date: 2013-02-26 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ec2eddfed950 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Reviewed-by: kvn, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 77f9b6d0126e Author: sspitsyn Date: 2013-02-27 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/77f9b6d0126e Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: b5e03c8ead49 Author: brutisso Date: 2013-02-28 09:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b5e03c8ead49 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 6931f425c517 Author: roland Date: 2013-02-25 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6931f425c517 8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store. Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/8007294/Test8007294.java Changeset: 706c919d3b56 Author: roland Date: 2013-02-26 12:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/706c919d3b56 8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376 Summary: GetAndSetP's MachNode should capture bottom type. Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp + test/compiler/8007722/Test8007722.java Changeset: a00ed9736260 Author: drchase Date: 2013-02-26 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a00ed9736260 8007776: Test6852078.java timeouts Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed. Reviewed-by: kvn ! test/compiler/6852078/Test6852078.java Changeset: 133bf557ef77 Author: iignatyev Date: 2013-02-27 05:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/133bf557ef77 8007439: C2: adding successful message of inlining Reviewed-by: kvn, vlivanov ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: b02157cd249f Author: vlivanov Date: 2013-02-27 08:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b02157cd249f Merge Changeset: 338da89b2592 Author: vlivanov Date: 2013-02-28 15:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/338da89b2592 Merge Changeset: df5396524152 Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/df5396524152 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4a198b201f3c Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4a198b201f3c Added tag hs25-b21 for changeset df5396524152 ! .hgtags Changeset: 7f482030ff64 Author: amurillo Date: 2013-03-01 04:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7f482030ff64 8009226: new hotspot build - hs25-b22 Reviewed-by: jcoomes ! make/hotspot_version From tao.mao at oracle.com Sat Mar 2 01:19:55 2013 From: tao.mao at oracle.com (Tao Mao) Date: Fri, 01 Mar 2013 17:19:55 -0800 Subject: Request for review: 8008079 G1: Add nextObject routine to CMBitMapRO and replace nextWord In-Reply-To: <512BEE67.6040107@oracle.com> References: <5126D50B.7050700@oracle.com> <512BEE67.6040107@oracle.com> Message-ID: <513153BB.9000203@oracle.com> integrated the suggestion. A new webrev is updated. http://cr.openjdk.java.net/~tamao/8008079/webrev.01/ again, passed gc-test-suite for fastdebug build with stressing marking cycles script: ./run.sh /home/tamao/jdk1.8.0 --bits 64 --args -tamao -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=5 -XX:+UnlockDiagnosticVMOptions -XX:+VerifyDuringGC On 2/25/13 3:06 PM, John Cuthbertson wrote: > Hi Tao, > > Looks fine except for the following nits.... > > concurrentMark.hpp:100 > Can you remove the line: > > // XXX Fix these so that offsets are size_t's... > > concurrentMark.hpp:111 > It might be safer to return: > > return offsetToHeapWord(heapWordToOffset(addr + obj->size())); > > or assert something like: > > HeapWord* res = addr + obj->size(); > assert(offsetToHeapWord(heapWordToOffset(res)) == res, "sanity"); > return res; > > JohnC > On 2/21/2013 6:16 PM, Tao Mao wrote: >> 8008079 G1: Add nextObject routine to CMBitMapRO and replace nextWord >> https://jbs.oracle.com/bugs/browse/JDK-8008079 >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8008079/webrev.00/ >> >> changeset: >> When concurrent marking scans an object, the task local finger is >> updated to point to the start of the object. If the marking task is >> asked to abort, the local finger is updated to the next word where >> another could possibly start. When the marking task is restarted, we >> restart scanning the marking bitmap from the updated local finger. >> >> This is a safe implementation but has not been fully exploited for >> efficiency because the contents of the marking bitmap should be all >> 0's until the offset associated with the actual start of the next >> object. When the marking task is restarted, we will scan these 0's >> looking for the first set bit. >> >> We can avoid this redundant scanning by updating the finger to and >> re-starting the scan at the actual offset where the next object starts. >> >> testing: >> passed gc-test-suite with stressing marking cycles >> script: >> ./run.sh /home/tamao/jdk1.8.0 --bits 64 --args -tamao -XX:+UseG1GC >> -XX:InitiatingHeapOccupancyPercent=10 -XX:+UnlockDiagnosticVMOptions >> -XX:+VerifyDuringGC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Sat Mar 2 07:25:39 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 1 Mar 2013 23:25:39 -0800 Subject: Request for review: 8008079 G1: Add nextObject routine to CMBitMapRO and replace nextWord In-Reply-To: <513153BB.9000203@oracle.com> References: <5126D50B.7050700@oracle.com> <512BEE67.6040107@oracle.com> <513153BB.9000203@oracle.com> Message-ID: Looks good to me too. I'd suggest a one-line doc for the new getNextObject() method stating that the argument to the method should be the address of a valid object. I don't think an assertion is necessary in the method to check for that because, I am guessing, obj->size() will already have some form of sanity check/assertion that would assert if it's not the start address of a valid object. -- ramki On Fri, Mar 1, 2013 at 5:19 PM, Tao Mao wrote: > integrated the suggestion. A new webrev is updated. > http://cr.openjdk.java.net/~tamao/8008079/webrev.01/ > > again, passed gc-test-suite for fastdebug build with stressing marking > cycles > script: > ./run.sh /home/tamao/jdk1.8.0 --bits 64 --args -tamao -XX:+UseG1GC > -XX:InitiatingHeapOccupancyPercent=5 -XX:+UnlockDiagnosticVMOptions > -XX:+VerifyDuringGC > > > On 2/25/13 3:06 PM, John Cuthbertson wrote: > > Hi Tao, > > Looks fine except for the following nits.... > > concurrentMark.hpp:100 > Can you remove the line: > > // XXX Fix these so that offsets are size_t's... > > concurrentMark.hpp:111 > It might be safer to return: > > return offsetToHeapWord(heapWordToOffset(addr + obj->size())); > > or assert something like: > > HeapWord* res = addr + obj->size(); > assert(offsetToHeapWord(heapWordToOffset(res)) == res, "sanity"); > return res; > > JohnC > > On 2/21/2013 6:16 PM, Tao Mao wrote: > > 8008079 G1: Add nextObject routine to CMBitMapRO and replace nextWord > https://jbs.oracle.com/bugs/browse/JDK-8008079 > > webrev: > http://cr.openjdk.java.net/~tamao/8008079/webrev.00/ > > changeset: > When concurrent marking scans an object, the task local finger is updated > to point to the start of the object. If the marking task is asked to abort, > the local finger is updated to the next word where another could possibly > start. When the marking task is restarted, we restart scanning the marking > bitmap from the updated local finger. > > This is a safe implementation but has not been fully exploited for > efficiency because the contents of the marking bitmap should be all 0's > until the offset associated with the actual start of the next object. When > the marking task is restarted, we will scan these 0's looking for the first > set bit. > > We can avoid this redundant scanning by updating the finger to and > re-starting the scan at the actual offset where the next object starts. > > testing: > passed gc-test-suite with stressing marking cycles > script: > ./run.sh /home/tamao/jdk1.8.0 --bits 64 --args -tamao -XX:+UseG1GC > -XX:InitiatingHeapOccupancyPercent=10 -XX:+UnlockDiagnosticVMOptions > -XX:+VerifyDuringGC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Sat Mar 2 08:42:50 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sat, 2 Mar 2013 00:42:50 -0800 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: <512D4987.9040401@oracle.com> References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> Message-ID: Hi Jon -- I'll give a couple of code-level comments, but there's a high-level comment at the end, which might be worth pondering over. On Tue, Feb 26, 2013 at 3:47 PM, Jon Masamitsu wrote: > > I've updated the webrev for review comments (thanks, JohnCu) > > http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ > concurrent MarkSweepGeneration.cpp: 949 // compute expansion delta needed for reaching desired free percentage 950 if (free_percentage < desired_free_percentage) { 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - desired_free_percentage)); 952 assert(desired_capacity >= capacity(), "invalid expansion size"); 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), MinHeapDeltaBytes); 954 if (expand_bytes > 0) { The if test at 954 (in your changed code) will always be true because MinHeapDeltaBytes > 0 and we are taking the max at line 953. On reading your shrinking code further below at lines 989-994, it struck me that there's a small existing bug in the shrink/expand code here. It's probably more of a factor in the shrink code though because we can live with more free space than we'd ideally want, but not less than we ideally want, and we certainly do not want to chatter around the desired free percentage (hence the delta). Your shrinking arm looks like this:- 989 } else { 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - desired_free_percentage)); 991 assert(desired_capacity <= capacity(), "invalid expansion size"); 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, MinHeapDeltaBytes); 993 shrink_free_list_by(shrink_bytes); 994 } I'd modify it to:- 989 } else { 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - desired_free_percentage)); 991 assert(desired_capacity <= capacity(), "invalid expansion size"); size_t shrink_bytes = capacity() - desired_capacity; // Don't shrink unless the delta is greater than the minimum shrink we want 992 if (shrink_bytes >= MinHeapDeltaBytes) { 993 shrink_free_list_by(shrink_bytes); } 994 } Note the asymmetry between expansion and shrinking, where we expand by the min if we feel we are below the desired free, but we don't shrink even if we are above desired free unless the gap exceeds the min delta. This seems to be the correct policy. (Of course none of that is moot until shrink_free_list_by() starts doing shrinking, but probably best to fix the policy now, so that it doesn't cause chatter later. concurrentMarkSweepGeneration.hpp: 1298 virtual void compute_new_size(); 1299 void compute_new_size_free_list(); I think it would be good to add a 1-line doc comment for each of the above methods. vmStructs.cpp: I think you also have to adjust the fields _capacity_at_prologue and _used_at_prologue into the superclass. I'd also move the decls up to CardGeneration, since that's how the original code is laid out. Finally, a high level comment. While I see the reason for these mechanics, I worry a little bit about the somewhat schizophrenic expansion/shrinkage policy, as it swings between one policy used when we are presumably doing well and keeping up with the application's allocation/promotion rates and not running into concurrent mode failure, but then suddenly switching to a completely different expansion/shrinking policy when we do a compaction (presumably because we had a concurrent mode failure). I'd much rather have divorced the two, by using a more uniform policy specifically for CMS, perhaps predicated by whether this was happening after a compaction or not, but keeping it separate from the policy that might be used for stop-world kind of collectors (hence TenuredGeneraion). I'd appreciate it if you could give some thought to this final high level comment regarding the general policy approach taken here. (Also it is somewhat troubling to push policy so high up into the class hierarchy, so that every subclass must live with it; I'd much rather the policy were separated from the mechanics of what would be done when an expansion or shrinkage was needed.) -- ramki From jon.masamitsu at oracle.com Sun Mar 3 06:59:40 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Sun, 03 Mar 2013 06:59:40 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Message-ID: <20130303065948.05A63477EE@hg.openjdk.java.net> Changeset: a252e688abcf Author: jmasa Date: 2013-02-01 17:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a252e688abcf 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Reviewed-by: jmasa, johnc, ysr Contributed-by: michal at frajt.eu ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp From thomas.schatzl at oracle.com Mon Mar 4 08:24:37 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 04 Mar 2013 09:24:37 +0100 Subject: RFR (M): 8008918: Reference statistics events for the tracing framework In-Reply-To: <5130B692.6070908@oracle.com> References: <5130B692.6070908@oracle.com> Message-ID: <1362385477.2590.9.camel@cirrus> Hi, On Fri, 2013-03-01 at 15:09 +0100, Erik Helin wrote: > Hi all, > > this change adds the vm/gc/reference/statistics event to all collectors. > > Please note that this change depends on "8009232: Improve stats > gathering code for reference processor" which is also out for review on > hotspot-gc-dev at openjdk.java.net. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8008918/webrev.00/ > > Bug: > https://jbs.oracle.com/bugs/browse/JDK-8008918 Minor: Maybe, in concurrentMarkSweepGeneration.cpp the declaration of the stats record could be put inside the block. Do you think if there is an easy way to put the sequence of allocating the stats record, calling rp->process_discovered_reference and the report_gc_reference_processing into a single method that is called everywhere? This code sequence, is the same in all collectors, and seems to be a good target for refactoring. I.e. what the change basically did is to replace the call to process_discovered_reference by above sequence of three statements. Hth, Thomas From bengt.rutisson at oracle.com Mon Mar 4 11:42:47 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 04 Mar 2013 12:42:47 +0100 Subject: RFR(S): 8007036: G1: Too many old regions added to last mixed GC In-Reply-To: <512CFEBB.9090309@oracle.com> References: <5106F4D1.50200@oracle.com> <510840A0.1000709@oracle.com> <512CFEBB.9090309@oracle.com> Message-ID: <513488B7.7060305@oracle.com> On 2/26/13 7:28 PM, John Cuthbertson wrote: > Hi Everyone, > > I've only received (and incorporated) comments from Vitaly Davidovich > so I'm pinging the list again. Any takers? It's quite small - the main > part of the fix is in G1CollectorPolicy::finalize_cset(). > > Thanks, > > JohnC > > On 1/29/2013 1:35 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Here's a new webrev based upon feedback from Vitaly: >> http://cr.openjdk.java.net/~johnc/8007036/webrev.1/ >> >> JohnC >> >> >> On 1/28/2013 1:59 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers look over the changes for this CR? >>> The webrev is at: http://cr.openjdk.java.net/~johnc/8007036/webrev.0/ >>> >>> Summary: >>> When adding old regions to the collection set we don't take into >>> account whether the old regions added so far take us below the >>> G1HeapWastePercent. As a result we could end up adding (and >>> collecting) many more regions than we needed to. The actual number >>> added was the minimum between the number of candidate regions / >>> G1MixedGCCountTarget and 10% of the heap. >>> >>> Currently the calculation of the reclaimable bytes as a percentage >>> of the uses exact arithmetic. It might make sense, at some point in >>> the future, to use inexact arithmetic (rounding) in the decision on >>> whether to continue mixed GCs and use exact arithmetic when adding >>> regions. >>> >>> As part of this change I've also moved a couple routines from >>> CollectionSetChooser to G1CollectorPolicy. I think they "fit" better >>> in G1CollectorPolicy. >>> >>> Testing: >>> GCOld with tenuring threshold = 1 and a marking threshold = 10. >>> >>> Many thanks to Monica for identifying the issue. >>> >>> Thanks, >>> >>> JohnC >> > From bengt.rutisson at oracle.com Mon Mar 4 11:59:17 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 04 Mar 2013 12:59:17 +0100 Subject: RFR(S): 8007036: G1: Too many old regions added to last mixed GC In-Reply-To: <512CFEBB.9090309@oracle.com> References: <5106F4D1.50200@oracle.com> <510840A0.1000709@oracle.com> <512CFEBB.9090309@oracle.com> Message-ID: <51348C95.9000604@oracle.com> Hi John, (Happened to send an empty mail just before. Here's what I wanted to write.) Sorry for not reviewing this earlier! Changes look good, ship it! One question. You added a note to the _length field in CollectionSetChooser: // The number of candidate old regions added to the CSet chooser. // Note: this is not updated when removing a region using // remove_and_move_to_next() below. uint _length; As far as I can tell we should really decrement the _length field in remove_and_move_to_next(). Would it maybe be better to fix this (as a separate change of course) than to add the note? I guess the code works since we don't use the length information after finlalize_cset() but it feels a bit fragile. Bengt On 2/26/13 7:28 PM, John Cuthbertson wrote: > Hi Everyone, > > I've only received (and incorporated) comments from Vitaly Davidovich > so I'm pinging the list again. Any takers? It's quite small - the main > part of the fix is in G1CollectorPolicy::finalize_cset(). > > Thanks, > > JohnC > > On 1/29/2013 1:35 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Here's a new webrev based upon feedback from Vitaly: >> http://cr.openjdk.java.net/~johnc/8007036/webrev.1/ >> >> JohnC >> >> >> On 1/28/2013 1:59 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers look over the changes for this CR? >>> The webrev is at: http://cr.openjdk.java.net/~johnc/8007036/webrev.0/ >>> >>> Summary: >>> When adding old regions to the collection set we don't take into >>> account whether the old regions added so far take us below the >>> G1HeapWastePercent. As a result we could end up adding (and >>> collecting) many more regions than we needed to. The actual number >>> added was the minimum between the number of candidate regions / >>> G1MixedGCCountTarget and 10% of the heap. >>> >>> Currently the calculation of the reclaimable bytes as a percentage >>> of the uses exact arithmetic. It might make sense, at some point in >>> the future, to use inexact arithmetic (rounding) in the decision on >>> whether to continue mixed GCs and use exact arithmetic when adding >>> regions. >>> >>> As part of this change I've also moved a couple routines from >>> CollectionSetChooser to G1CollectorPolicy. I think they "fit" better >>> in G1CollectorPolicy. >>> >>> Testing: >>> GCOld with tenuring threshold = 1 and a marking threshold = 10. >>> >>> Many thanks to Monica for identifying the issue. >>> >>> Thanks, >>> >>> JohnC >> > From mikael.gerdin at oracle.com Mon Mar 4 14:44:55 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 04 Mar 2013 15:44:55 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Message-ID: <5134B367.8020708@oracle.com> Hi all, Please review this change to enable CMS to hand back memory for unloaded classes when running in concurrent mode. Bug link: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 Webrev: http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ The core change in this patch is the inserted call in sweep(): 6101 6102 if (should_unload_classes()) { 6103 ClassLoaderDataGraph::purge(); 6104 } 6105 This is needed because even though we claim to perform "class unloading" in the final remark phase we can't deallocate the memory for classes until after we've performed the sweep phase since the sweeper needs to find the size of objects even though they and their class is not considered live anymore. The rest of the changes in concurrentMarkSweepGeneration.cpp only relate to logging information about released metaspace memory and cms gen occupancy to make it easier to analyze what's happening. An example of this new logging output is: 134.069: [CMS-concurrent-sweep-start] 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 sys=0.02, real=0.01 secs] 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: 277487K->133228K(370885K/412976K)] ] 134.166: [CMS-concurrent-reset-start] 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] The change in genCollectedHeap.cpp is needed to avoid artificially inflating the size of the Metaspace memory, since memory is considered "used" until purge() has been called. By calling purge() before compute_new_size() (as the other collectors do) we use the correct figures. The disabled assert in metaspace.cpp is faulty because a thread may be allocating classes and expanding the metaspace memory while we are in compute_new_size, I've verified that this assert can in fact fail on a build without these changes. The change in ~SpaceManager is because of lock order restrictions, sum_capacity_in_chunks_in_use takes the Metaspace lock and would do it out of order with regards to the expand_lock. I've tested these changes primarily by running the ParallelClassLoading tests with a small young gen size to enable regular class unloading cycles. Thanks /Mikael From erik.helin at oracle.com Mon Mar 4 15:57:01 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Mon, 04 Mar 2013 15:57:01 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8004172: Update jstat counter names to reflect metaspace changes Message-ID: <20130304155706.07AB747810@hg.openjdk.java.net> Changeset: 0624b9d81255 Author: ehelin Date: 2013-03-04 13:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0624b9d81255 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp From john.cuthbertson at oracle.com Mon Mar 4 17:44:22 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 04 Mar 2013 09:44:22 -0800 Subject: RFR(S): 8007036: G1: Too many old regions added to last mixed GC In-Reply-To: <51348C95.9000604@oracle.com> References: <5106F4D1.50200@oracle.com> <510840A0.1000709@oracle.com> <512CFEBB.9090309@oracle.com> <51348C95.9000604@oracle.com> Message-ID: <5134DD76.80901@oracle.com> Hi Bengt, Thanks for looking over the changes. On 3/4/2013 3:59 AM, Bengt Rutisson wrote: > > One question. You added a note to the _length field in > CollectionSetChooser: > > // The number of candidate old regions added to the CSet chooser. > // Note: this is not updated when removing a region using > // remove_and_move_to_next() below. > uint _length; > > As far as I can tell we should really decrement the _length field in > remove_and_move_to_next(). Would it maybe be better to fix this (as a > separate change of course) than to add the note? I guess the code > works since we don't use the length information after finlalize_cset() > but it feels a bit fragile. Good point. They only reason not to do this is that we don't actually remove the element from the CollectionSetChooser. I'm not sure why. IIRC we only use the length to calculate out the ideal minimum number and absolute maximum number of old regions to collect each mixed GC. I'll submit a new CR for your suggestion. I think changing the CollectionSetChooser to use the RegionList abstraction would probably be the way to go. Thanks, JohnC From john.cuthbertson at oracle.com Mon Mar 4 18:11:32 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 04 Mar 2013 10:11:32 -0800 Subject: RFR(S): 8007036: G1: Too many old regions added to last mixed GC In-Reply-To: <51348C95.9000604@oracle.com> References: <5106F4D1.50200@oracle.com> <510840A0.1000709@oracle.com> <512CFEBB.9090309@oracle.com> <51348C95.9000604@oracle.com> Message-ID: <5134E3D4.6080404@oracle.com> Hi Bengt, Submitted: 8009395 G1: CollectionSetChooser cleanup to track the issue that you mentioned. Thanks again! JohnC On 3/4/2013 3:59 AM, Bengt Rutisson wrote: > > Hi John, > > (Happened to send an empty mail just before. Here's what I wanted to > write.) > > Sorry for not reviewing this earlier! > > Changes look good, ship it! > > One question. You added a note to the _length field in > CollectionSetChooser: > > // The number of candidate old regions added to the CSet chooser. > // Note: this is not updated when removing a region using > // remove_and_move_to_next() below. > uint _length; > > As far as I can tell we should really decrement the _length field in > remove_and_move_to_next(). Would it maybe be better to fix this (as a > separate change of course) than to add the note? I guess the code > works since we don't use the length information after finlalize_cset() > but it feels a bit fragile. > > Bengt > > On 2/26/13 7:28 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> I've only received (and incorporated) comments from Vitaly Davidovich >> so I'm pinging the list again. Any takers? It's quite small - the >> main part of the fix is in G1CollectorPolicy::finalize_cset(). >> >> Thanks, >> >> JohnC >> >> On 1/29/2013 1:35 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Here's a new webrev based upon feedback from Vitaly: >>> http://cr.openjdk.java.net/~johnc/8007036/webrev.1/ >>> >>> JohnC >>> >>> >>> On 1/28/2013 1:59 PM, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers look over the changes for this >>>> CR? The webrev is at: >>>> http://cr.openjdk.java.net/~johnc/8007036/webrev.0/ >>>> >>>> Summary: >>>> When adding old regions to the collection set we don't take into >>>> account whether the old regions added so far take us below the >>>> G1HeapWastePercent. As a result we could end up adding (and >>>> collecting) many more regions than we needed to. The actual number >>>> added was the minimum between the number of candidate regions / >>>> G1MixedGCCountTarget and 10% of the heap. >>>> >>>> Currently the calculation of the reclaimable bytes as a percentage >>>> of the uses exact arithmetic. It might make sense, at some point in >>>> the future, to use inexact arithmetic (rounding) in the decision on >>>> whether to continue mixed GCs and use exact arithmetic when adding >>>> regions. >>>> >>>> As part of this change I've also moved a couple routines from >>>> CollectionSetChooser to G1CollectorPolicy. I think they "fit" >>>> better in G1CollectorPolicy. >>>> >>>> Testing: >>>> GCOld with tenuring threshold = 1 and a marking threshold = 10. >>>> >>>> Many thanks to Monica for identifying the issue. >>>> >>>> Thanks, >>>> >>>> JohnC >>> >> > From jon.masamitsu at oracle.com Mon Mar 4 18:21:50 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 04 Mar 2013 10:21:50 -0800 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> Message-ID: <5134E63E.9080504@oracle.com> Ramki, Thanks for taking a look. Let's talk about the high level comment before the details. Are you saying that the amount of desired free space in the cms generation after a collection should be independent of whether the collection was a concurrent collection or a full STW collection? Jon On 03/02/13 00:42, Srinivas Ramakrishna wrote: > Hi Jon -- > > I'll give a couple of code-level comments, but there's a high-level > comment at the end, which > might be worth pondering over. > > On Tue, Feb 26, 2013 at 3:47 PM, Jon Masamitsu wrote: >> I've updated the webrev for review comments (thanks, JohnCu) >> >> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ >> > concurrent MarkSweepGeneration.cpp: > > 949 // compute expansion delta needed for reaching desired free percentage > 950 if (free_percentage< desired_free_percentage) { > 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - > desired_free_percentage)); > 952 assert(desired_capacity>= capacity(), "invalid expansion size"); > 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), > MinHeapDeltaBytes); > > 954 if (expand_bytes> 0) { > > The if test at 954 (in your changed code) will always be true because > MinHeapDeltaBytes> 0 > and we are taking the max at line 953. > > On reading your shrinking code further below at lines 989-994, it > struck me that there's a small > existing bug in the shrink/expand code here. It's probably more of a > factor in the shrink code though > because we can live with more free space than we'd ideally want, but > not less than we ideally want, > and we certainly do not want to chatter around the desired free > percentage (hence the delta). > > Your shrinking arm looks like this:- > > 989 } else { > 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - > desired_free_percentage)); > 991 assert(desired_capacity<= capacity(), "invalid expansion size"); > 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, > MinHeapDeltaBytes); > 993 shrink_free_list_by(shrink_bytes); > 994 } > > I'd modify it to:- > > 989 } else { > 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - > desired_free_percentage)); > 991 assert(desired_capacity<= capacity(), "invalid expansion size"); > size_t shrink_bytes = capacity() - desired_capacity; > // Don't shrink unless the delta is greater than the > minimum shrink we want > 992 if (shrink_bytes>= MinHeapDeltaBytes) { > 993 shrink_free_list_by(shrink_bytes); > } > 994 } > > Note the asymmetry between expansion and shrinking, where we expand by > the min if we feel we are below the desired free, but we don't shrink > even if we are above desired free unless the gap exceeds the min > delta. > > This seems to be the correct policy. (Of course none of that is moot > until shrink_free_list_by() starts doing shrinking, but probably best > to fix the policy now, so that it doesn't cause chatter later. > > concurrentMarkSweepGeneration.hpp: > > 1298 virtual void compute_new_size(); > 1299 void compute_new_size_free_list(); > > I think it would be good to add a 1-line doc comment for each of the > above methods. > > vmStructs.cpp: > > I think you also have to adjust the fields _capacity_at_prologue and > _used_at_prologue into the superclass. I'd also move the decls up to > CardGeneration, since that's how the original code is laid out. > > Finally, a high level comment. While I see the reason for these > mechanics, I worry a little bit > about the somewhat schizophrenic expansion/shrinkage policy, as it > swings between one policy > used when we are presumably doing well and keeping up with the application's > allocation/promotion rates and not running into concurrent mode > failure, but then suddenly switching > to a completely different expansion/shrinking policy when we do a > compaction (presumably because > we had a concurrent mode failure). I'd much rather have divorced the > two, by using a more uniform > policy specifically for CMS, perhaps predicated by whether this was > happening after a > compaction or not, but keeping it separate from the policy that might > be used for stop-world > kind of collectors (hence TenuredGeneraion). > > I'd appreciate it if you could give some thought to this final high > level comment regarding the > general policy approach taken here. (Also it is somewhat troubling to > push policy so high up > into the class hierarchy, so that every subclass must live with it; > I'd much rather the policy > were separated from the mechanics of what would be done when an > expansion or shrinkage > was needed.) > > -- ramki From ysr1729 at gmail.com Mon Mar 4 19:02:23 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 4 Mar 2013 11:02:23 -0800 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: <5134E63E.9080504@oracle.com> References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> <5134E63E.9080504@oracle.com> Message-ID: KInd of.... What I am saying is that the sizing policy should be based on what CMS wants, not what CardGeneration might want. Besides how does card generation know what specific policy a concrete subclass would want. The policy should be determined by the "leaf class" (or suitably over-ridden as needed) -- in this case by CMS. I see that you have here decided that the policy provided by CardGeneration is sufficient for when a concurrent mode failure happens. I was not sure if that would necessarily be the case, and perhaps more thought is needed to come up with a good _policy_ specific for CMS, and use the _mechanics_ provided by CardGeneration to affect that change. CMS _should_ distinguish between whether a concurrent mode failure occurred or not to determine how its heap should be sized, but it should probably be a policy that is cognizant of the historical metrics of CMS, which may or may not be used by or available to CardGeneration, and make decisions specific to CMS, which CardGeneration does not know about. May be I am splitting hairs here, but this is basically where mechanism, if common, might be provided by superclasses but policy by concrete subclasses (or suitably overridden when appropriate -- may be in this case you decided that when there is a compacting collection, the policy provided by the superclass is good enough; I was not sure if that was a deliberate decision -- I have not looked closely at either policy to see if it makes sense. Consider, for example, that CMS usually has larger free space needs than contiguous space collectors, so it makes sense to me that its sizing policies would be different and keep more free space available based on the application's historical behaviour, than would contiguously allocating collectors.) Does my concern make sense? -- ramki On Mon, Mar 4, 2013 at 10:21 AM, Jon Masamitsu wrote: > Ramki, > > Thanks for taking a look. Let's talk about the high level > comment before the details. > > Are you saying that the amount of desired free space in the > cms generation after a collection should be independent of > whether the collection was a concurrent collection or a > full STW collection? > > Jon > > > > On 03/02/13 00:42, Srinivas Ramakrishna wrote: >> >> Hi Jon -- >> >> I'll give a couple of code-level comments, but there's a high-level >> comment at the end, which >> might be worth pondering over. >> >> On Tue, Feb 26, 2013 at 3:47 PM, Jon Masamitsu >> wrote: >>> >>> I've updated the webrev for review comments (thanks, JohnCu) >>> >>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ >>> >> concurrent MarkSweepGeneration.cpp: >> >> 949 // compute expansion delta needed for reaching desired free >> percentage >> 950 if (free_percentage< desired_free_percentage) { >> 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - >> desired_free_percentage)); >> 952 assert(desired_capacity>= capacity(), "invalid expansion size"); >> 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), >> MinHeapDeltaBytes); >> >> 954 if (expand_bytes> 0) { >> >> The if test at 954 (in your changed code) will always be true because >> MinHeapDeltaBytes> 0 >> and we are taking the max at line 953. >> >> On reading your shrinking code further below at lines 989-994, it >> struck me that there's a small >> existing bug in the shrink/expand code here. It's probably more of a >> factor in the shrink code though >> because we can live with more free space than we'd ideally want, but >> not less than we ideally want, >> and we certainly do not want to chatter around the desired free >> percentage (hence the delta). >> >> Your shrinking arm looks like this:- >> >> 989 } else { >> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >> desired_free_percentage)); >> 991 assert(desired_capacity<= capacity(), "invalid expansion size"); >> 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, >> MinHeapDeltaBytes); >> 993 shrink_free_list_by(shrink_bytes); >> 994 } >> >> I'd modify it to:- >> >> 989 } else { >> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >> desired_free_percentage)); >> 991 assert(desired_capacity<= capacity(), "invalid expansion size"); >> size_t shrink_bytes = capacity() - desired_capacity; >> // Don't shrink unless the delta is greater than the >> minimum shrink we want >> 992 if (shrink_bytes>= MinHeapDeltaBytes) { >> 993 shrink_free_list_by(shrink_bytes); >> } >> 994 } >> >> Note the asymmetry between expansion and shrinking, where we expand by >> the min if we feel we are below the desired free, but we don't shrink >> even if we are above desired free unless the gap exceeds the min >> delta. >> >> This seems to be the correct policy. (Of course none of that is moot >> until shrink_free_list_by() starts doing shrinking, but probably best >> to fix the policy now, so that it doesn't cause chatter later. >> >> concurrentMarkSweepGeneration.hpp: >> >> 1298 virtual void compute_new_size(); >> 1299 void compute_new_size_free_list(); >> >> I think it would be good to add a 1-line doc comment for each of the >> above methods. >> >> vmStructs.cpp: >> >> I think you also have to adjust the fields _capacity_at_prologue and >> _used_at_prologue into the superclass. I'd also move the decls up to >> CardGeneration, since that's how the original code is laid out. >> >> Finally, a high level comment. While I see the reason for these >> mechanics, I worry a little bit >> about the somewhat schizophrenic expansion/shrinkage policy, as it >> swings between one policy >> used when we are presumably doing well and keeping up with the >> application's >> allocation/promotion rates and not running into concurrent mode >> failure, but then suddenly switching >> to a completely different expansion/shrinking policy when we do a >> compaction (presumably because >> we had a concurrent mode failure). I'd much rather have divorced the >> two, by using a more uniform >> policy specifically for CMS, perhaps predicated by whether this was >> happening after a >> compaction or not, but keeping it separate from the policy that might >> be used for stop-world >> kind of collectors (hence TenuredGeneraion). >> >> I'd appreciate it if you could give some thought to this final high >> level comment regarding the >> general policy approach taken here. (Also it is somewhat troubling to >> push policy so high up >> into the class hierarchy, so that every subclass must live with it; >> I'd much rather the policy >> were separated from the mechanics of what would be done when an >> expansion or shrinkage >> was needed.) >> >> -- ramki From jon.masamitsu at oracle.com Mon Mar 4 22:49:36 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 04 Mar 2013 14:49:36 -0800 Subject: Request for review: 6976528 (vs) - PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Message-ID: <51352500.9000401@oracle.com> The assertion was intended to verify that soft references would always be cleared before an out-of-memory is thrown. There is actually code that guarantees that (the soft references have been cleared before an out-of-memory is thrown) and this assertion is superfluous. 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared http://cr.openjdk.java.net/~jmasa/6976528/webrev.00/ The assertion failed in some circumstance and after looking at the code paths I decided there were too many paths for it to be obvious that the assertion should hold so I deleted the assertion. Thanks. Jon If you prefer the diffs here they are (2 deleted lines). diff --git a/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp --- a/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp +++ b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp @@ -409,7 +409,7 @@ // heap remains parsable. const bool limit_exceeded = size_policy()->gc_overhead_limit_exceeded(); const bool softrefs_clear = collector_policy()->all_soft_refs_clear(); - assert(!limit_exceeded || softrefs_clear, "Should have been cleared"); + if (limit_exceeded&& softrefs_clear) { *gc_overhead_limit_was_exceeded = true; size_policy()->set_gc_overhead_limit_exceeded(false); diff --git a/src/share/vm/memory/collectorPolicy.cpp b/src/share/vm/memory/collectorPolicy.cpp --- a/src/share/vm/memory/collectorPolicy.cpp +++ b/src/share/vm/memory/collectorPolicy.cpp @@ -620,7 +620,7 @@ const bool limit_exceeded = size_policy()->gc_overhead_limit_exceeded(); const bool softrefs_clear = all_soft_refs_clear(); - assert(!limit_exceeded || softrefs_clear, "Should have been cleared"); + if (limit_exceeded&& softrefs_clear) { *gc_overhead_limit_was_exceeded = true; size_policy()->set_gc_overhead_limit_exceeded(false); From jon.masamitsu at oracle.com Mon Mar 4 23:18:19 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 04 Mar 2013 15:18:19 -0800 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> <5134E63E.9080504@oracle.com> Message-ID: <51352BBB.4070809@oracle.com> Ramki, I think that originally CMSGen and TenuredGen shared nearly the same policy but didn't share enough code. The existing CMS policy is 1) if the incremental collection failed, expand to reserved space. else 2) use MinHeapFreeRatio to decide if generation should be expanded and by how much else 3) don't know how to shrink so don't I think that the CardGeneration::compute_new_size() (formerly the TenuredGeneration::compute_new_size()) does the same as 2) and that for a full GC we know how to shrink the generation and the CardGeneration::compute_new_size() does that when CMS does a full GC. So for the CMS compute_new_size(), keep 1) and replace 2) and 3) with a call to CardGeneration::compute_new_size(). I'll go back and verify that the original CMS compute_new_size() uses MinHeapFreeRatio the same way as CardGeneration::compute_new_size() does. If they are the same, I'll try to refactor it so that they actually share more code. A user that wants more head room in the CMS generation would have to specify a MinHeapFreeRatio and that value would be used by CardGeneration::compute_new_size() with my change just as it is used in the original CMS compute_new_size(). Jon On 03/04/13 11:02, Srinivas Ramakrishna wrote: > KInd of.... What I am saying is that the sizing policy should be based > on what CMS wants, not > what CardGeneration might want. Besides how does card generation know > what specific policy > a concrete subclass would want. The policy should be determined by the > "leaf class" (or suitably > over-ridden as needed) -- in this case by CMS. I see that you have > here decided that the policy > provided by CardGeneration is sufficient for when a concurrent mode > failure happens. I was not sure > if that would necessarily be the case, and perhaps more thought is > needed to come up with > a good _policy_ specific for CMS, and use the _mechanics_ provided by > CardGeneration to > affect that change. CMS _should_ distinguish between whether a > concurrent mode failure occurred > or not to determine how its heap should be sized, but it should > probably be a policy that is > cognizant of the historical metrics of CMS, which may or may not be > used by or available > to CardGeneration, and make decisions specific to CMS, which > CardGeneration does not know about. > > May be I am splitting hairs here, but this is basically where > mechanism, if common, might be > provided by superclasses but policy by concrete subclasses (or > suitably overridden when > appropriate -- may be in this case you decided that when there is a > compacting collection, > the policy provided by the superclass is good enough; I was not sure > if that was a deliberate > decision -- I have not looked closely at either policy to see if it > makes sense. Consider, for example, > that CMS usually has larger free space needs than contiguous space > collectors, so it makes > sense to me that its sizing policies would be different and keep more > free space available based > on the application's historical behaviour, than would contiguously > allocating collectors.) > > Does my concern make sense? > > -- ramki > > On Mon, Mar 4, 2013 at 10:21 AM, Jon Masamitsu wrote: >> Ramki, >> >> Thanks for taking a look. Let's talk about the high level >> comment before the details. >> >> Are you saying that the amount of desired free space in the >> cms generation after a collection should be independent of >> whether the collection was a concurrent collection or a >> full STW collection? >> >> Jon >> >> >> >> On 03/02/13 00:42, Srinivas Ramakrishna wrote: >>> Hi Jon -- >>> >>> I'll give a couple of code-level comments, but there's a high-level >>> comment at the end, which >>> might be worth pondering over. >>> >>> On Tue, Feb 26, 2013 at 3:47 PM, Jon Masamitsu >>> wrote: >>>> I've updated the webrev for review comments (thanks, JohnCu) >>>> >>>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ >>>> >>> concurrent MarkSweepGeneration.cpp: >>> >>> 949 // compute expansion delta needed for reaching desired free >>> percentage >>> 950 if (free_percentage< desired_free_percentage) { >>> 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - >>> desired_free_percentage)); >>> 952 assert(desired_capacity>= capacity(), "invalid expansion size"); >>> 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), >>> MinHeapDeltaBytes); >>> >>> 954 if (expand_bytes> 0) { >>> >>> The if test at 954 (in your changed code) will always be true because >>> MinHeapDeltaBytes> 0 >>> and we are taking the max at line 953. >>> >>> On reading your shrinking code further below at lines 989-994, it >>> struck me that there's a small >>> existing bug in the shrink/expand code here. It's probably more of a >>> factor in the shrink code though >>> because we can live with more free space than we'd ideally want, but >>> not less than we ideally want, >>> and we certainly do not want to chatter around the desired free >>> percentage (hence the delta). >>> >>> Your shrinking arm looks like this:- >>> >>> 989 } else { >>> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >>> desired_free_percentage)); >>> 991 assert(desired_capacity<= capacity(), "invalid expansion size"); >>> 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, >>> MinHeapDeltaBytes); >>> 993 shrink_free_list_by(shrink_bytes); >>> 994 } >>> >>> I'd modify it to:- >>> >>> 989 } else { >>> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >>> desired_free_percentage)); >>> 991 assert(desired_capacity<= capacity(), "invalid expansion size"); >>> size_t shrink_bytes = capacity() - desired_capacity; >>> // Don't shrink unless the delta is greater than the >>> minimum shrink we want >>> 992 if (shrink_bytes>= MinHeapDeltaBytes) { >>> 993 shrink_free_list_by(shrink_bytes); >>> } >>> 994 } >>> >>> Note the asymmetry between expansion and shrinking, where we expand by >>> the min if we feel we are below the desired free, but we don't shrink >>> even if we are above desired free unless the gap exceeds the min >>> delta. >>> >>> This seems to be the correct policy. (Of course none of that is moot >>> until shrink_free_list_by() starts doing shrinking, but probably best >>> to fix the policy now, so that it doesn't cause chatter later. >>> >>> concurrentMarkSweepGeneration.hpp: >>> >>> 1298 virtual void compute_new_size(); >>> 1299 void compute_new_size_free_list(); >>> >>> I think it would be good to add a 1-line doc comment for each of the >>> above methods. >>> >>> vmStructs.cpp: >>> >>> I think you also have to adjust the fields _capacity_at_prologue and >>> _used_at_prologue into the superclass. I'd also move the decls up to >>> CardGeneration, since that's how the original code is laid out. >>> >>> Finally, a high level comment. While I see the reason for these >>> mechanics, I worry a little bit >>> about the somewhat schizophrenic expansion/shrinkage policy, as it >>> swings between one policy >>> used when we are presumably doing well and keeping up with the >>> application's >>> allocation/promotion rates and not running into concurrent mode >>> failure, but then suddenly switching >>> to a completely different expansion/shrinking policy when we do a >>> compaction (presumably because >>> we had a concurrent mode failure). I'd much rather have divorced the >>> two, by using a more uniform >>> policy specifically for CMS, perhaps predicated by whether this was >>> happening after a >>> compaction or not, but keeping it separate from the policy that might >>> be used for stop-world >>> kind of collectors (hence TenuredGeneraion). >>> >>> I'd appreciate it if you could give some thought to this final high >>> level comment regarding the >>> general policy approach taken here. (Also it is somewhat troubling to >>> push policy so high up >>> into the class hierarchy, so that every subclass must live with it; >>> I'd much rather the policy >>> were separated from the mechanics of what would be done when an >>> expansion or shrinkage >>> was needed.) >>> >>> -- ramki From tao.mao at oracle.com Tue Mar 5 00:46:15 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 04 Mar 2013 16:46:15 -0800 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <51353E78.1040700@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> Message-ID: <51354057.1070308@oracle.com> Oops...sent to open list. Thanks. Tao On 3/4/2013 4:38 PM, Tao Mao wrote: > This is the proposed final webrev, with copyright dated appropriately. > http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ > > Jon, > A patch is rendered below. Please take the patch and help push the > changeset. > http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch > > Thank you. > Tao > > On 2/26/13 8:37 AM, Jon Masamitsu wrote: >> Thanks. >> >> Looks good. >> >> Jon >> >> On 02/25/13 11:09, Tao Mao wrote: >>> A new webrev is updated. >>> Thanks. >>> Tao >>> >>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>> Tao, >>>> >>>> Why this change from resize_old_gen() to >>>> resize_tenured_gen()? There are many >>>> variable names and comments referring to >>>> "old gen" still in ParallelScavengeHeap. >>> Reverted. >>>> >>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>> >>>> Jon >>>> >>>> On 02/14/13 11:18, Tao Mao wrote: >>>>> 8007762: Rename a bunch of methods in size policy across collectors >>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>> >>>>> changeset: >>>>> The motivation of this change is associated with CR 7098155 >>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>> need to split compute_generations_free_space into two routine (one >>>>> for compute_eden_space_size and the other for >>>>> compute_tenured_generation_free_space) in order to save some >>>>> overhead when we want to compute only one of the two. The next >>>>> step is to split >>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which will >>>>> be resolved in CR 8007763. >>>>> >>>>> To unify the naming, a bunch of routines are renamed here. >>>>> (1) compute_*: >>>>> compute_survivor_space_size_and_threshold() >>>>> compute_generations_free_space() = compute_eden_space_size() >>>>> + compute_tenured_generation_free_space() >>>>> (2) resize_*_gen: >>>>> resize_young_gen() >>>>> resize_tenured_gen() >>>>> (3) rename judging routine resize_geneneration() to need_resize() >>>>> to avoid ambiguity >>>>> >>>>> testing: >>>>> purely renaming; passed JPRT >>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Tue Mar 5 05:29:59 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 05 Mar 2013 05:29:59 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8007036: G1: Too many old regions added to last mixed GC Message-ID: <20130305053004.90E8A47833@hg.openjdk.java.net> Changeset: 27714220e50e Author: johnc Date: 2013-03-04 12:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/27714220e50e 8007036: G1: Too many old regions added to last mixed GC Summary: Stop adding old regions to collection set when the remaining reclaimable bytes reaches, or goes below, G1HeapWastePercent. Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp From bengt.rutisson at oracle.com Tue Mar 5 06:56:33 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Mar 2013 07:56:33 +0100 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <51354057.1070308@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> <51354057.1070308@oracle.com> Message-ID: <51359721.5030508@oracle.com> Hi Tao, The method PSAdaptiveSizePolicy::compute_generation_free_space() is a monster method. It does all kinds of things. Its comment kind of reveals this: 339 // Calculates optimial free space sizes for both the old and young 340 // generations. Stores results in _eden_size and _promo_size. 341 // Takes current used space in all generations as input, as well 342 // as an indication if a full gc has just been performed, for use 343 // in deciding if an OOM error should be thrown. So, I think that if we should rename it we should give it a name that reflects this. The current name is not good, but I don't think compute_generations_free_space() is much better. I would suggest to either leave it unchanged or change to a more descriptive name. Maybe gether_adapitve_size_statistics() or update_adaptive_size_values(). Not very happy with those names either, but at least they indicate that ther eis more than just free space calculations in there. In psGCAdaptivePolicyCounters.hpp you updated a method name that has been commented out. I would suggest removing it rather than updating it. Thanks, Bengt On 3/5/13 1:46 AM, Tao Mao wrote: > Oops...sent to open list. > > Thanks. > Tao > > On 3/4/2013 4:38 PM, Tao Mao wrote: >> This is the proposed final webrev, with copyright dated appropriately. >> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ >> >> Jon, >> A patch is rendered below. Please take the patch and help push the >> changeset. >> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch >> >> Thank you. >> Tao >> >> On 2/26/13 8:37 AM, Jon Masamitsu wrote: >>> Thanks. >>> >>> Looks good. >>> >>> Jon >>> >>> On 02/25/13 11:09, Tao Mao wrote: >>>> A new webrev is updated. >>>> Thanks. >>>> Tao >>>> >>>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>>> Tao, >>>>> >>>>> Why this change from resize_old_gen() to >>>>> resize_tenured_gen()? There are many >>>>> variable names and comments referring to >>>>> "old gen" still in ParallelScavengeHeap. >>>> Reverted. >>>>> >>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>>> >>>>> Jon >>>>> >>>>> On 02/14/13 11:18, Tao Mao wrote: >>>>>> 8007762: Rename a bunch of methods in size policy across collectors >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>>> >>>>>> changeset: >>>>>> The motivation of this change is associated with CR 7098155 >>>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>>> need to split compute_generations_free_space into two routine >>>>>> (one for compute_eden_space_size and the other for >>>>>> compute_tenured_generation_free_space) in order to save some >>>>>> overhead when we want to compute only one of the two. The next >>>>>> step is to split >>>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which >>>>>> will be resolved in CR 8007763. >>>>>> >>>>>> To unify the naming, a bunch of routines are renamed here. >>>>>> (1) compute_*: >>>>>> compute_survivor_space_size_and_threshold() >>>>>> compute_generations_free_space() = >>>>>> compute_eden_space_size() + compute_tenured_generation_free_space() >>>>>> (2) resize_*_gen: >>>>>> resize_young_gen() >>>>>> resize_tenured_gen() >>>>>> (3) rename judging routine resize_geneneration() to need_resize() >>>>>> to avoid ambiguity >>>>>> >>>>>> testing: >>>>>> purely renaming; passed JPRT >>>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Tue Mar 5 07:20:02 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 04 Mar 2013 23:20:02 -0800 Subject: Request for review: 8008368: Deprecate MaxGCMinorPauseMillis In-Reply-To: <512FAD5C.50103@oracle.com> References: <512FAD5C.50103@oracle.com> Message-ID: <51359CA2.9070600@oracle.com> Hi Tao, I would change the name of the new routine to check_deprecated_gc_flags() and I would move the call to after the check_deprecated_gcs(). Other than the above it looks good. You may want to file an enhancement to move some the other deprecated GC flags, for which we emit warnings, into the new routine. JohnC On 2/28/2013 11:17 AM, Tao Mao wrote: > 8008368: Deprecate MaxGCMinorPauseMillis > https://jbs.oracle.com/bugs/browse/JDK-8008368 > > webrev: > http://cr.openjdk.java.net/~tamao/8008368/webrev.00/ > > changeset: > We don't need the distinction between MaxGCMinorPauseMillis and > MaxGCPauseMillis. The MaxGCMinorPauseMillis flag was introduced as a > backup measure in case one pause target for all types collections was > not enough. As it has turned out it seems one pause target is enough. > Thus, we should deprecate MaxGCMinorPauseMillis and give a warning > when set. > > testing: > passed JPRT test(sanity) > From tao.mao at oracle.com Tue Mar 5 07:43:15 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 04 Mar 2013 23:43:15 -0800 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <51359721.5030508@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> <51354057.1070308@oracle.com> <51359721.5030508@oracle.com> Message-ID: <5135A213.6030001@oracle.com> Hi Bengt, As I understand (since I've investigated the resizing issue for a while) and, in fact, if you look at the comments you quoted, the routine compute_generations_free_space() just does the following: input(stats of young & old spaces) -> output(calculated eden & promo sizes). I would say, it's valid to name it this way. In fact, in another CR (8007763, one of the series of CR's you asked me to split out), we would like to split compute_generations_free_space() into compute_eden* and compute_old*. This also validates the renaming here. For commenting in psGCAdaptivePolicyCounters.hpp, the comment leads a series of routines to update stats for compute_generations_free_space(). It has some value to keep it. But, I'm ok either way for the choice here doesn't matter too much. Thanks. Tao On 2013/3/4 22:56, Bengt Rutisson wrote: > > Hi Tao, > > The method PSAdaptiveSizePolicy::compute_generation_free_space() is a > monster method. It does all kinds of things. Its comment kind of > reveals this: > > 339 // Calculates optimial free space sizes for both the old and young > 340 // generations. Stores results in _eden_size and _promo_size. > 341 // Takes current used space in all generations as input, as well > 342 // as an indication if a full gc has just been performed, for use > 343 // in deciding if an OOM error should be thrown. > > So, I think that if we should rename it we should give it a name that > reflects this. The current name is not good, but I don't think > compute_generations_free_space() is much better. I would suggest to > either leave it unchanged or change to a more descriptive name. > > Maybe gether_adapitve_size_statistics() or > update_adaptive_size_values(). Not very happy with those names either, > but at least they indicate that ther eis more than just free space > calculations in there. > > > In psGCAdaptivePolicyCounters.hpp you updated a method name that has > been commented out. I would suggest removing it rather than updating it. > > Thanks, > Bengt > > On 3/5/13 1:46 AM, Tao Mao wrote: >> Oops...sent to open list. >> >> Thanks. >> Tao >> >> On 3/4/2013 4:38 PM, Tao Mao wrote: >>> This is the proposed final webrev, with copyright dated appropriately. >>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ >>> >>> Jon, >>> A patch is rendered below. Please take the patch and help push the >>> changeset. >>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch >>> >>> Thank you. >>> Tao >>> >>> On 2/26/13 8:37 AM, Jon Masamitsu wrote: >>>> Thanks. >>>> >>>> Looks good. >>>> >>>> Jon >>>> >>>> On 02/25/13 11:09, Tao Mao wrote: >>>>> A new webrev is updated. >>>>> Thanks. >>>>> Tao >>>>> >>>>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>>>> Tao, >>>>>> >>>>>> Why this change from resize_old_gen() to >>>>>> resize_tenured_gen()? There are many >>>>>> variable names and comments referring to >>>>>> "old gen" still in ParallelScavengeHeap. >>>>> Reverted. >>>>>> >>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>>>> >>>>>> Jon >>>>>> >>>>>> On 02/14/13 11:18, Tao Mao wrote: >>>>>>> 8007762: Rename a bunch of methods in size policy across collectors >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>>>> >>>>>>> changeset: >>>>>>> The motivation of this change is associated with CR 7098155 >>>>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>>>> need to split compute_generations_free_space into two routine >>>>>>> (one for compute_eden_space_size and the other for >>>>>>> compute_tenured_generation_free_space) in order to save some >>>>>>> overhead when we want to compute only one of the two. The next >>>>>>> step is to split >>>>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which >>>>>>> will be resolved in CR 8007763. >>>>>>> >>>>>>> To unify the naming, a bunch of routines are renamed here. >>>>>>> (1) compute_*: >>>>>>> compute_survivor_space_size_and_threshold() >>>>>>> compute_generations_free_space() = >>>>>>> compute_eden_space_size() + compute_tenured_generation_free_space() >>>>>>> (2) resize_*_gen: >>>>>>> resize_young_gen() >>>>>>> resize_tenured_gen() >>>>>>> (3) rename judging routine resize_geneneration() to >>>>>>> need_resize() to avoid ambiguity >>>>>>> >>>>>>> testing: >>>>>>> purely renaming; passed JPRT >>>>>>> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Mar 5 09:16:18 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Mar 2013 10:16:18 +0100 Subject: RFR(S): 8007036: G1: Too many old regions added to last mixed GC In-Reply-To: <5134E3D4.6080404@oracle.com> References: <5106F4D1.50200@oracle.com> <510840A0.1000709@oracle.com> <512CFEBB.9090309@oracle.com> <51348C95.9000604@oracle.com> <5134E3D4.6080404@oracle.com> Message-ID: <5135B7E2.5020005@oracle.com> Hi John, On 3/4/13 7:11 PM, John Cuthbertson wrote: > Hi Bengt, > > Submitted: > > 8009395 G1: CollectionSetChooser cleanup > > to track the issue that you mentioned. Great! Thanks! Thanks for adding the comment about using RegionLists to the bug report. I agree that this is the way to go. Bengt > > Thanks again! > > JohnC > > On 3/4/2013 3:59 AM, Bengt Rutisson wrote: >> >> Hi John, >> >> (Happened to send an empty mail just before. Here's what I wanted to >> write.) >> >> Sorry for not reviewing this earlier! >> >> Changes look good, ship it! >> >> One question. You added a note to the _length field in >> CollectionSetChooser: >> >> // The number of candidate old regions added to the CSet chooser. >> // Note: this is not updated when removing a region using >> // remove_and_move_to_next() below. >> uint _length; >> >> As far as I can tell we should really decrement the _length field in >> remove_and_move_to_next(). Would it maybe be better to fix this (as a >> separate change of course) than to add the note? I guess the code >> works since we don't use the length information after >> finlalize_cset() but it feels a bit fragile. >> >> Bengt >> >> On 2/26/13 7:28 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> I've only received (and incorporated) comments from Vitaly >>> Davidovich so I'm pinging the list again. Any takers? It's quite >>> small - the main part of the fix is in >>> G1CollectorPolicy::finalize_cset(). >>> >>> Thanks, >>> >>> JohnC >>> >>> On 1/29/2013 1:35 PM, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Here's a new webrev based upon feedback from Vitaly: >>>> http://cr.openjdk.java.net/~johnc/8007036/webrev.1/ >>>> >>>> JohnC >>>> >>>> >>>> On 1/28/2013 1:59 PM, John Cuthbertson wrote: >>>>> Hi Everyone, >>>>> >>>>> Can I have a couple of volunteers look over the changes for this >>>>> CR? The webrev is at: >>>>> http://cr.openjdk.java.net/~johnc/8007036/webrev.0/ >>>>> >>>>> Summary: >>>>> When adding old regions to the collection set we don't take into >>>>> account whether the old regions added so far take us below the >>>>> G1HeapWastePercent. As a result we could end up adding (and >>>>> collecting) many more regions than we needed to. The actual number >>>>> added was the minimum between the number of candidate regions / >>>>> G1MixedGCCountTarget and 10% of the heap. >>>>> >>>>> Currently the calculation of the reclaimable bytes as a percentage >>>>> of the uses exact arithmetic. It might make sense, at some point >>>>> in the future, to use inexact arithmetic (rounding) in the >>>>> decision on whether to continue mixed GCs and use exact arithmetic >>>>> when adding regions. >>>>> >>>>> As part of this change I've also moved a couple routines from >>>>> CollectionSetChooser to G1CollectorPolicy. I think they "fit" >>>>> better in G1CollectorPolicy. >>>>> >>>>> Testing: >>>>> GCOld with tenuring threshold = 1 and a marking threshold = 10. >>>>> >>>>> Many thanks to Monica for identifying the issue. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>>> >>> >> > From erik.helin at oracle.com Tue Mar 5 09:36:08 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 05 Mar 2013 10:36:08 +0100 Subject: RFR (S): 8009232: Improve stats gathering code for reference processor In-Reply-To: <51309249.3030006@oracle.com> References: <51309249.3030006@oracle.com> Message-ID: <5135BC88.6080002@oracle.com> All, based on internal feedback, I've updated the change. The ReferenceProcessorStats class is now no longer a C++ "friend" with the ReferenceProcessor class. Furthermore, the method ReferenceProcessor::process_discovered_reflist now returns the number of discovered references. I have also renamed GCTrace::report_gc_reference_processing to GCTrace::report_gc_reference_stats and GCTrace::send_gc_reference_processing_event to GCTrace::send_gc_reference_stats_event. This was done because the name of the event was previously changed from vm/gc/reference/processing to vm/gc/reference/statistics. New webrev: http://cr.openjdk.java.net/~ehelin/8009232/webrev.01/ Thanks, Erik On 03/01/2013 12:34 PM, Erik Helin wrote: > Hi all, > > this change refactors the way the reference processing statistics are > being collected from the reference processor. > > Summary: > Before, the statistics were collected by calling > ReferenceProcessor::collect_statistics immediately after a call to > ReferenceProcessor::process_discovered_references. With this change, the > method process_discovered_references instead returns > the statistics. > > The benefit is that there is now no need to keep track of an internal > state in ReferenceProcessor since the ReferenceProcessorStats can be put > on the stack in process_discovered_references. Furthermore, the code is > more maintainable, since the old code required the calls to > process_discovered_references and collect_statistics to go "hand in > hand". Now, one only has to care about the call to > process_discovered_references. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8009232/webrev.00/ > > Bug: > https://jbs.oracle.com/bugs/browse/JDK-8009232 > > Testing: > JPRT > > Thanks, > Erik From bengt.rutisson at oracle.com Tue Mar 5 09:33:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Mar 2013 10:33:06 +0100 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <5135A213.6030001@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> <51354057.1070308@oracle.com> <51359721.5030508@oracle.com> <5135A213.6030001@oracle.com> Message-ID: <5135BBD2.6010800@oracle.com> Hi Tao, First, I realize that I am very late with this feedback. Sorry for that. On 3/5/13 8:43 AM, Tao Mao wrote: > Hi Bengt, > > As I understand (since I've investigated the resizing issue for a > while) and, in fact, if you look at the comments you quoted, the > routine compute_generations_free_space() just does the following: > > input(stats of young & old spaces) -> output(calculated eden & promo > sizes). I disagree. The method has lots of side effects. It does not just take some input and produce some output. It updates the global state in many ways. For example through the statistics gathering with at least 10-20 instance variables such as: _avg_base_footprint _avg_young_live _avg_eden_live _avg_old_live _decide_at_full_gc _change_old_gen_for_maj_pauses _change_young_gen_for_maj_pauses ..and more It also logs messages associated with PrintAdaptiveSizePolicy. In fact I would consider the calculation of free size as a very small part of what the method does. The name compute_generations_free_space() indicates to me that it would be a simple input->output method just as you suggested. But in that case I would expect that it would be safe to call it several times in a row. This is not the case with the current implementation. We can only call it exactly once at the exact right moment in the during GC. So, again, I'm fine with leaving the name untouched as compute_generation_free_space(). But if we should change it I think we should make a more meaningful change than what you proposed. Bengt > > I would say, it's valid to name it this way. > > In fact, in another CR (8007763, one of the series of CR's you asked > me to split out), we would like to split > compute_generations_free_space() into compute_eden* and compute_old*. > This also validates the renaming here. > > For commenting in psGCAdaptivePolicyCounters.hpp, the comment leads a > series of routines to update stats for > compute_generations_free_space(). It has some value to keep it. But, > I'm ok either way for the choice here doesn't matter too much. > > Thanks. > Tao > > > On 2013/3/4 22:56, Bengt Rutisson wrote: >> >> Hi Tao, >> >> The method PSAdaptiveSizePolicy::compute_generation_free_space() is a >> monster method. It does all kinds of things. Its comment kind of >> reveals this: >> >> 339 // Calculates optimial free space sizes for both the old and young >> 340 // generations. Stores results in _eden_size and _promo_size. >> 341 // Takes current used space in all generations as input, as well >> 342 // as an indication if a full gc has just been performed, for use >> 343 // in deciding if an OOM error should be thrown. >> >> So, I think that if we should rename it we should give it a name that >> reflects this. The current name is not good, but I don't think >> compute_generations_free_space() is much better. I would suggest to >> either leave it unchanged or change to a more descriptive name. >> >> Maybe gether_adapitve_size_statistics() or >> update_adaptive_size_values(). Not very happy with those names >> either, but at least they indicate that ther eis more than just free >> space calculations in there. >> >> >> In psGCAdaptivePolicyCounters.hpp you updated a method name that has >> been commented out. I would suggest removing it rather than updating it. >> >> Thanks, >> Bengt >> >> On 3/5/13 1:46 AM, Tao Mao wrote: >>> Oops...sent to open list. >>> >>> Thanks. >>> Tao >>> >>> On 3/4/2013 4:38 PM, Tao Mao wrote: >>>> This is the proposed final webrev, with copyright dated appropriately. >>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ >>>> >>>> Jon, >>>> A patch is rendered below. Please take the patch and help push the >>>> changeset. >>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch >>>> >>>> Thank you. >>>> Tao >>>> >>>> On 2/26/13 8:37 AM, Jon Masamitsu wrote: >>>>> Thanks. >>>>> >>>>> Looks good. >>>>> >>>>> Jon >>>>> >>>>> On 02/25/13 11:09, Tao Mao wrote: >>>>>> A new webrev is updated. >>>>>> Thanks. >>>>>> Tao >>>>>> >>>>>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>>>>> Tao, >>>>>>> >>>>>>> Why this change from resize_old_gen() to >>>>>>> resize_tenured_gen()? There are many >>>>>>> variable names and comments referring to >>>>>>> "old gen" still in ParallelScavengeHeap. >>>>>> Reverted. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 02/14/13 11:18, Tao Mao wrote: >>>>>>>> 8007762: Rename a bunch of methods in size policy across collectors >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>>>>> >>>>>>>> changeset: >>>>>>>> The motivation of this change is associated with CR 7098155 >>>>>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>>>>> need to split compute_generations_free_space into two routine >>>>>>>> (one for compute_eden_space_size and the other for >>>>>>>> compute_tenured_generation_free_space) in order to save some >>>>>>>> overhead when we want to compute only one of the two. The next >>>>>>>> step is to split >>>>>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which >>>>>>>> will be resolved in CR 8007763. >>>>>>>> >>>>>>>> To unify the naming, a bunch of routines are renamed here. >>>>>>>> (1) compute_*: >>>>>>>> compute_survivor_space_size_and_threshold() >>>>>>>> compute_generations_free_space() = >>>>>>>> compute_eden_space_size() + compute_tenured_generation_free_space() >>>>>>>> (2) resize_*_gen: >>>>>>>> resize_young_gen() >>>>>>>> resize_tenured_gen() >>>>>>>> (3) rename judging routine resize_geneneration() to >>>>>>>> need_resize() to avoid ambiguity >>>>>>>> >>>>>>>> testing: >>>>>>>> purely renaming; passed JPRT >>>>>>>> >>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.coomes at oracle.com Tue Mar 5 10:16:53 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 05 Mar 2013 10:16:53 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8008451: Make mac builds on 10.8 work on 10.7 Message-ID: <20130305101659.05C054783A@hg.openjdk.java.net> Changeset: d778bb46a9a5 Author: erikj Date: 2013-03-04 22:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d778bb46a9a5 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: jcoomes, ohair ! make/bsd/makefiles/gcc.make From jon.masamitsu at oracle.com Tue Mar 5 16:31:34 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 05 Mar 2013 08:31:34 -0800 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <51359721.5030508@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> <51354057.1070308@oracle.com> <51359721.5030508@oracle.com> Message-ID: <51361DE6.8070807@oracle.com> Bengt, Would a less specific name such as "update" be better? Something that says to the reader "you have to go look at what the method is doing because a name is not going to be descriptive enough". Jon On 03/04/13 22:56, Bengt Rutisson wrote: > > Hi Tao, > > The method PSAdaptiveSizePolicy::compute_generation_free_space() is a > monster method. It does all kinds of things. Its comment kind of > reveals this: > > 339 // Calculates optimial free space sizes for both the old and young > 340 // generations. Stores results in _eden_size and _promo_size. > 341 // Takes current used space in all generations as input, as well > 342 // as an indication if a full gc has just been performed, for use > 343 // in deciding if an OOM error should be thrown. > > So, I think that if we should rename it we should give it a name that > reflects this. The current name is not good, but I don't think > compute_generations_free_space() is much better. I would suggest to > either leave it unchanged or change to a more descriptive name. > > Maybe gether_adapitve_size_statistics() or > update_adaptive_size_values(). Not very happy with those names either, > but at least they indicate that ther eis more than just free space > calculations in there. > > > In psGCAdaptivePolicyCounters.hpp you updated a method name that has > been commented out. I would suggest removing it rather than updating it. > > Thanks, > Bengt > > On 3/5/13 1:46 AM, Tao Mao wrote: >> Oops...sent to open list. >> >> Thanks. >> Tao >> >> On 3/4/2013 4:38 PM, Tao Mao wrote: >>> This is the proposed final webrev, with copyright dated appropriately. >>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ >>> >>> Jon, >>> A patch is rendered below. Please take the patch and help push the >>> changeset. >>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch >>> >>> Thank you. >>> Tao >>> >>> On 2/26/13 8:37 AM, Jon Masamitsu wrote: >>>> Thanks. >>>> >>>> Looks good. >>>> >>>> Jon >>>> >>>> On 02/25/13 11:09, Tao Mao wrote: >>>>> A new webrev is updated. >>>>> Thanks. >>>>> Tao >>>>> >>>>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>>>> Tao, >>>>>> >>>>>> Why this change from resize_old_gen() to >>>>>> resize_tenured_gen()? There are many >>>>>> variable names and comments referring to >>>>>> "old gen" still in ParallelScavengeHeap. >>>>> Reverted. >>>>>> >>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>>>> >>>>>> Jon >>>>>> >>>>>> On 02/14/13 11:18, Tao Mao wrote: >>>>>>> 8007762: Rename a bunch of methods in size policy across collectors >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>>>> >>>>>>> changeset: >>>>>>> The motivation of this change is associated with CR 7098155 >>>>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>>>> need to split compute_generations_free_space into two routine >>>>>>> (one for compute_eden_space_size and the other for >>>>>>> compute_tenured_generation_free_space) in order to save some >>>>>>> overhead when we want to compute only one of the two. The next >>>>>>> step is to split >>>>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which >>>>>>> will be resolved in CR 8007763. >>>>>>> >>>>>>> To unify the naming, a bunch of routines are renamed here. >>>>>>> (1) compute_*: >>>>>>> compute_survivor_space_size_and_threshold() >>>>>>> compute_generations_free_space() = >>>>>>> compute_eden_space_size() + compute_tenured_generation_free_space() >>>>>>> (2) resize_*_gen: >>>>>>> resize_young_gen() >>>>>>> resize_tenured_gen() >>>>>>> (3) rename judging routine resize_geneneration() to >>>>>>> need_resize() to avoid ambiguity >>>>>>> >>>>>>> testing: >>>>>>> purely renaming; passed JPRT >>>>>>> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Tue Mar 5 16:39:42 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 05 Mar 2013 17:39:42 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" Message-ID: <51361FCE.30304@oracle.com> Hi all, this change adds the option "-J-d64" or "-J-d32" (depending on arch) when running jmap in the test hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. Webrev: http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 Thanks, Erik From bengt.rutisson at oracle.com Tue Mar 5 18:57:25 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Mar 2013 19:57:25 +0100 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <51361DE6.8070807@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> <51354057.1070308@oracle.com> <51359721.5030508@oracle.com> <51361DE6.8070807@oracle.com> Message-ID: <51364015.7050503@oracle.com> Jon, On 3/5/13 5:31 PM, Jon Masamitsu wrote: > Bengt, > > Would a less specific name such as "update" be > better? Something that says to the reader > "you have to go look at what the method is > doing because a name is not going to be > descriptive enough". Yes, I think so. Something that indicates that this will have side effects. In my earlier email I suggested update_adaptive_size_values(). If you come up with something better I'm happy too. :) Bengt > > Jon > > On 03/04/13 22:56, Bengt Rutisson wrote: >> >> Hi Tao, >> >> The method PSAdaptiveSizePolicy::compute_generation_free_space() is a >> monster method. It does all kinds of things. Its comment kind of >> reveals this: >> >> 339 // Calculates optimial free space sizes for both the old and young >> 340 // generations. Stores results in _eden_size and _promo_size. >> 341 // Takes current used space in all generations as input, as well >> 342 // as an indication if a full gc has just been performed, for use >> 343 // in deciding if an OOM error should be thrown. >> >> So, I think that if we should rename it we should give it a name that >> reflects this. The current name is not good, but I don't think >> compute_generations_free_space() is much better. I would suggest to >> either leave it unchanged or change to a more descriptive name. >> >> Maybe gether_adapitve_size_statistics() or >> update_adaptive_size_values(). Not very happy with those names >> either, but at least they indicate that ther eis more than just free >> space calculations in there. >> >> >> In psGCAdaptivePolicyCounters.hpp you updated a method name that has >> been commented out. I would suggest removing it rather than updating it. >> >> Thanks, >> Bengt >> >> On 3/5/13 1:46 AM, Tao Mao wrote: >>> Oops...sent to open list. >>> >>> Thanks. >>> Tao >>> >>> On 3/4/2013 4:38 PM, Tao Mao wrote: >>>> This is the proposed final webrev, with copyright dated appropriately. >>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ >>>> >>>> Jon, >>>> A patch is rendered below. Please take the patch and help push the >>>> changeset. >>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch >>>> >>>> Thank you. >>>> Tao >>>> >>>> On 2/26/13 8:37 AM, Jon Masamitsu wrote: >>>>> Thanks. >>>>> >>>>> Looks good. >>>>> >>>>> Jon >>>>> >>>>> On 02/25/13 11:09, Tao Mao wrote: >>>>>> A new webrev is updated. >>>>>> Thanks. >>>>>> Tao >>>>>> >>>>>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>>>>> Tao, >>>>>>> >>>>>>> Why this change from resize_old_gen() to >>>>>>> resize_tenured_gen()? There are many >>>>>>> variable names and comments referring to >>>>>>> "old gen" still in ParallelScavengeHeap. >>>>>> Reverted. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 02/14/13 11:18, Tao Mao wrote: >>>>>>>> 8007762: Rename a bunch of methods in size policy across collectors >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>>>>> >>>>>>>> changeset: >>>>>>>> The motivation of this change is associated with CR 7098155 >>>>>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>>>>> need to split compute_generations_free_space into two routine >>>>>>>> (one for compute_eden_space_size and the other for >>>>>>>> compute_tenured_generation_free_space) in order to save some >>>>>>>> overhead when we want to compute only one of the two. The next >>>>>>>> step is to split >>>>>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which >>>>>>>> will be resolved in CR 8007763. >>>>>>>> >>>>>>>> To unify the naming, a bunch of routines are renamed here. >>>>>>>> (1) compute_*: >>>>>>>> compute_survivor_space_size_and_threshold() >>>>>>>> compute_generations_free_space() = >>>>>>>> compute_eden_space_size() + compute_tenured_generation_free_space() >>>>>>>> (2) resize_*_gen: >>>>>>>> resize_young_gen() >>>>>>>> resize_tenured_gen() >>>>>>>> (3) rename judging routine resize_geneneration() to >>>>>>>> need_resize() to avoid ambiguity >>>>>>>> >>>>>>>> testing: >>>>>>>> purely renaming; passed JPRT >>>>>>>> >>>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Tue Mar 5 21:02:26 2013 From: tao.mao at oracle.com (Tao Mao) Date: Tue, 05 Mar 2013 13:02:26 -0800 Subject: Request for review: 8008368: Deprecate MaxGCMinorPauseMillis In-Reply-To: <51359CA2.9070600@oracle.com> References: <512FAD5C.50103@oracle.com> <51359CA2.9070600@oracle.com> Message-ID: <51365D62.5040604@oracle.com> A new webrev is updated according to your feedback. http://cr.openjdk.java.net/~tamao/8008368/webrev.01/ Plus, what are the other deprecated GC flags you mentioned? Thanks. Tao On 3/4/13 11:20 PM, John Cuthbertson wrote: > Hi Tao, > > I would change the name of the new routine to > check_deprecated_gc_flags() and I would move the call to after the > check_deprecated_gcs(). > > Other than the above it looks good. > > You may want to file an enhancement to move some the other deprecated > GC flags, for which we emit warnings, into the new routine. > > JohnC > > On 2/28/2013 11:17 AM, Tao Mao wrote: >> 8008368: Deprecate MaxGCMinorPauseMillis >> https://jbs.oracle.com/bugs/browse/JDK-8008368 >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8008368/webrev.00/ >> >> changeset: >> We don't need the distinction between MaxGCMinorPauseMillis and >> MaxGCPauseMillis. The MaxGCMinorPauseMillis flag was introduced as a >> backup measure in case one pause target for all types collections was >> not enough. As it has turned out it seems one pause target is enough. >> Thus, we should deprecate MaxGCMinorPauseMillis and give a warning >> when set. >> >> testing: >> passed JPRT test(sanity) >> > From john.cuthbertson at oracle.com Tue Mar 5 21:56:32 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 05 Mar 2013 13:56:32 -0800 Subject: Request for review: 8008368: Deprecate MaxGCMinorPauseMillis In-Reply-To: <51365D62.5040604@oracle.com> References: <512FAD5C.50103@oracle.com> <51359CA2.9070600@oracle.com> <51365D62.5040604@oracle.com> Message-ID: <51366A10.3090707@oracle.com> Hi Tao, Looks OK to me. Examples would be: -XX:CMSParPromoteBlocksToClaim= -XX:ParallelGCOldGenAllocBufferSize= Basically there are a few GC flags that we accept in Arguments::parse_each_vm_init_arg() just so that we can emit a warning message. These would be reasonable candidates. You don't need to list them all in the new CR - just list the kind of flag that is a good candidate for adding into check_deprecated_gc_flags(), namely it's accepted in Arguments::parse_each_vm_init_arg() just so as to emit a warning. Thanks, JohnC On 3/5/2013 1:02 PM, Tao Mao wrote: > A new webrev is updated according to your feedback. > http://cr.openjdk.java.net/~tamao/8008368/webrev.01/ > > Plus, what are the other deprecated GC flags you mentioned? > > Thanks. > Tao > > On 3/4/13 11:20 PM, John Cuthbertson wrote: >> Hi Tao, >> >> I would change the name of the new routine to >> check_deprecated_gc_flags() and I would move the call to after the >> check_deprecated_gcs(). >> >> Other than the above it looks good. >> >> You may want to file an enhancement to move some the other deprecated >> GC flags, for which we emit warnings, into the new routine. >> >> JohnC >> >> On 2/28/2013 11:17 AM, Tao Mao wrote: >>> 8008368: Deprecate MaxGCMinorPauseMillis >>> https://jbs.oracle.com/bugs/browse/JDK-8008368 >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/8008368/webrev.00/ >>> >>> changeset: >>> We don't need the distinction between MaxGCMinorPauseMillis and >>> MaxGCPauseMillis. The MaxGCMinorPauseMillis flag was introduced as a >>> backup measure in case one pause target for all types collections >>> was not enough. As it has turned out it seems one pause target is >>> enough. Thus, we should deprecate MaxGCMinorPauseMillis and give a >>> warning when set. >>> >>> testing: >>> passed JPRT test(sanity) >>> >> From staffan.larsen at oracle.com Tue Mar 5 16:55:27 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 5 Mar 2013 17:55:27 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <51361FCE.30304@oracle.com> References: <51361FCE.30304@oracle.com> Message-ID: <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> Looks good. I wish we could abstract this away so that not every test needs to do this work. /Staffan (mobile) On 5 mar 2013, at 17:39, Erik Helin wrote: > Hi all, > > this change adds the option "-J-d64" or "-J-d32" (depending on arch) when running jmap in the test hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 > > Thanks, > Erik From uschindler at apache.org Tue Mar 5 21:48:40 2013 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 5 Mar 2013 22:48:40 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Message-ID: <01d201ce19eb$332d5160$9987f420$@apache.org> Hi, since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. To reproduce: - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) - change to directory lucene/analysis/uima and run: ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -------------- next part -------------- GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: . Attaching to process 22925 Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/java...(no debugging symbols found)...done. Reading symbols from /lib/i386-linux-gnu/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0xcf3f7b40 (LWP 22959)] [New Thread 0xf247eb40 (LWP 22958)] [New Thread 0xcf478b40 (LWP 22957)] [New Thread 0xcf4f9b40 (LWP 22956)] [New Thread 0xf267eb40 (LWP 22955)] [New Thread 0xf287eb40 (LWP 22954)] [New Thread 0xf2a7eb40 (LWP 22953)] [New Thread 0xcf96eb40 (LWP 22952)] [New Thread 0xcf9efb40 (LWP 22951)] [New Thread 0xcfdf9b40 (LWP 22950)] [New Thread 0xcfe7ab40 (LWP 22949)] [New Thread 0xcfefbb40 (LWP 22948)] [New Thread 0xf13fdb40 (LWP 22947)] [New Thread 0xf147eb40 (LWP 22946)] [New Thread 0xf14ffb40 (LWP 22945)] [New Thread 0xf16ffb40 (LWP 22944)] [New Thread 0xf18ffb40 (LWP 22943)] [New Thread 0xf1affb40 (LWP 22942)] [New Thread 0xf1cffb40 (LWP 22941)] [New Thread 0xf1effb40 (LWP 22940)] [New Thread 0xf20ffb40 (LWP 22939)] [New Thread 0xf22ffb40 (LWP 22938)] [New Thread 0xf24ffb40 (LWP 22937)] [New Thread 0xf26ffb40 (LWP 22936)] [New Thread 0xf28ffb40 (LWP 22935)] [New Thread 0xf2affb40 (LWP 22934)] [New Thread 0xf2cffb40 (LWP 22933)] [New Thread 0xf2effb40 (LWP 22932)] [New Thread 0xf30f3b40 (LWP 22931)] [New Thread 0xf6836b40 (LWP 22930)] Loaded symbols for /lib/i386-linux-gnu/libpthread.so.0 Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/../lib/i386/jli/libjli.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/../lib/i386/jli/libjli.so Reading symbols from /lib/i386-linux-gnu/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libdl.so.2 Reading symbols from /lib/i386-linux-gnu/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so Reading symbols from /lib/i386-linux-gnu/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libm.so.6 Reading symbols from /lib/i386-linux-gnu/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/librt.so.1 Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libverify.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libverify.so Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libjava.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libjava.so Reading symbols from /lib/i386-linux-gnu/libnss_compat.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libnss_compat.so.2 Reading symbols from /lib/i386-linux-gnu/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libnsl.so.1 Reading symbols from /lib/i386-linux-gnu/libnss_nis.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libnss_nis.so.2 Reading symbols from /lib/i386-linux-gnu/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libnss_files.so.2 Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libzip.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libzip.so Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libnet.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libnet.so Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libmanagement.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libmanagement.so Reading symbols from /lib/i386-linux-gnu/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libnss_dns.so.2 Reading symbols from /lib/i386-linux-gnu/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/i386-linux-gnu/libresolv.so.2 Reading symbols from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libnio.so...(no debugging symbols found)...done. Loaded symbols for /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libnio.so 0xf7743430 in __kernel_vsyscall () Thread 31 (Thread 0xf6836b40 (LWP 22930)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98374 in Monitor::ILock(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e985cd in Monitor::lock_without_safepoint_check() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6f4e338 in SafepointSynchronize::block(JavaThread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6feab97 in JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6cfe1a9 in jni_CallObjectMethod () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf67d2d29 in JNU_GetStringPlatformChars () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libjava.so #9 0xf67cdc34 in Java_java_io_UnixFileSystem_canonicalize0 () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/libjava.so #10 0xf32e683b in ?? () #11 0xf3346784 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 30 (Thread 0xf30f3b40 (LWP 22931)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 29 (Thread 0xf2effb40 (LWP 22932)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 28 (Thread 0xf2cffb40 (LWP 22933)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 27 (Thread 0xf2affb40 (LWP 22934)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 26 (Thread 0xf28ffb40 (LWP 22935)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 25 (Thread 0xf26ffb40 (LWP 22936)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 24 (Thread 0xf24ffb40 (LWP 22937)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 23 (Thread 0xf22ffb40 (LWP 22938)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 22 (Thread 0xf20ffb40 (LWP 22939)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5fb16 in SuspendibleThreadSet::join() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6b5ea41 in ConcurrentG1RefineThread::run_young_rs_sampling() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6b5ef91 in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #9 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #10 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 21 (Thread 0xf1effb40 (LWP 22940)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 20 (Thread 0xf1cffb40 (LWP 22941)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 19 (Thread 0xf1affb40 (LWP 22942)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 18 (Thread 0xf18ffb40 (LWP 22943)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 17 (Thread 0xf16ffb40 (LWP 22944)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 16 (Thread 0xf14ffb40 (LWP 22945)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 15 (Thread 0xf147eb40 (LWP 22946)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 14 (Thread 0xf13fdb40 (LWP 22947)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5ed9e in ConcurrentG1RefineThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 13 (Thread 0xcfefbb40 (LWP 22948)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf703c53c in VMThread::execute(VM_Operation*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6b818c0 in ConcurrentMarkThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 12 (Thread 0xcfe7ab40 (LWP 22949)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 11 (Thread 0xcfdf9b40 (LWP 22950)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704e258 in GangWorker::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf704de68 in GangWorker::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 10 (Thread 0xcf9efb40 (LWP 22951)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf704f094 in WorkGangBarrierSync::enter() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6b62a09 in ConcurrentMark::enter_first_sync_barrier(unsigned int) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6b65adc in CMTask::do_marking_step(double, bool, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf6b69dc9 in G1CMDrainMarkingStackClosure::do_void() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #9 0xf6f2bdff in ReferenceProcessor::process_phase3(DiscoveredList&, bool, BoolObjectClosure*, OopClosure*, VoidClosure*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #10 0xf6f2cf6d in ReferenceProcessor::process_discovered_reflist(DiscoveredList*, ReferencePolicy*, bool, BoolObjectClosure*, OopClosure*, VoidClosure*, AbstractRefProcTaskExecutor*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #11 0xf6f2d33c in ReferenceProcessor::process_discovered_references(BoolObjectClosure*, OopClosure*, VoidClosure*, AbstractRefProcTaskExecutor*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #12 0xf6b61ea5 in ConcurrentMark::weakRefsWork(bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #13 0xf6b66638 in ConcurrentMark::checkpointRootsFinal(bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #14 0xf6b82024 in CMCheckpointRootsFinalClosure::do_void() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #15 0xf703dc65 in VM_CGC_Operation::doit() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #16 0xf703d2a7 in VM_Operation::evaluate() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #17 0xf703b44e in VMThread::evaluate_operation(VM_Operation*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #18 0xf703b9e8 in VMThread::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #19 0xf703c095 in VMThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #20 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #21 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #22 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 9 (Thread 0xcf96eb40 (LWP 22952)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6ebcb73 in ObjectMonitor::wait(long long, bool, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6fb3983 in ObjectSynchronizer::wait(Handle, long long, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6d2b7fa in JVM_MonitorWait () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf31bf2b6 in ?? () #7 0xf31b7387 in ?? () #8 0xf31b7387 in ?? () #9 0xf31b4459 in ?? () #10 0xf6cd328f in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #11 0xf6ec7ef9 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #12 0xf6cd4392 in JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #13 0xf6cd47cb in JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #14 0xf6d2362d in thread_entry(JavaThread*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #15 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #16 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #17 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #18 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #19 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 8 (Thread 0xf2a7eb40 (LWP 22953)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6ebcb73 in ObjectMonitor::wait(long long, bool, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6fb3983 in ObjectSynchronizer::wait(Handle, long long, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6d2b7fa in JVM_MonitorWait () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf31bf2b6 in ?? () #7 0xf31b7387 in ?? () #8 0xf31b751a in ?? () #9 0xf31b751a in ?? () #10 0xf31b4459 in ?? () #11 0xf6cd328f in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #12 0xf6ec7ef9 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #13 0xf6cd4392 in JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #14 0xf6cd47cb in JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #15 0xf6d2362d in thread_entry(JavaThread*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #16 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #17 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #18 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #19 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #20 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 7 (Thread 0xf287eb40 (LWP 22954)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e993f4 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5f1a5 in SurrogateLockerThread::loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #9 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #10 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 6 (Thread 0xf267eb40 (LWP 22955)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf7720cc5 in sem_wait@@GLIBC_2.1 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ecd4e2 in check_pending_signals(bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6ec6bd2 in signal_thread_entry(JavaThread*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 5 (Thread 0xcf4f9b40 (LWP 22956)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98374 in Monitor::ILock(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e985cd in Monitor::lock_without_safepoint_check() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6f4e338 in SafepointSynchronize::block(JavaThread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6feab97 in JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6adbdad in ciKlass::is_subtype_of(ciKlass*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf6ffb611 in TypeKlassPtr::xmeet(Type const*) const () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #9 0xf6ff906d in Type::meet(Type const*) const () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #10 0xf6ff9516 in Type::filter(Type const*) const () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #11 0xf6ac2c5b in PhiNode::Value(PhaseTransform*) const () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #12 0xf6f0c2d8 in PhaseCCP::analyze() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #13 0xf6b4950c in Compile::Optimize() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #14 0xf6b4bea2 in Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #15 0xf6ab359f in C2Compiler::compile_method(ciEnv*, ciMethod*, int) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #16 0xf6b52ae1 in CompileBroker::invoke_compiler_on_method(CompileTask*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #17 0xf6b53dcd in CompileBroker::compiler_thread_loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #18 0xf6fe2af8 in compiler_thread_entry(JavaThread*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #19 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #20 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #21 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #22 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #23 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 4 (Thread 0xcf478b40 (LWP 22957)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e993f4 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b4eaa7 in CompileQueue::get() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6b539d8 in CompileBroker::compiler_thread_loop() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6fe2af8 in compiler_thread_entry(JavaThread*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #9 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #10 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #11 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #12 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 3 (Thread 0xf247eb40 (LWP 22958)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6f514fb in ServiceThread::service_thread_entry(JavaThread*, Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6fe9439 in JavaThread::thread_main_inner() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6fe95b9 in JavaThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #9 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #10 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 2 (Thread 0xcf3f7b40 (LWP 22959)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771ed13 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ecd842 in os::PlatformEvent::park(long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98e5d in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6fe5bb3 in WatcherThread::sleep() const () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6fe6026 in WatcherThread::run() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6ecee79 in java_start(Thread*) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #8 0xf771ad4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #9 0xf763ed3e in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 1 (Thread 0xf754e6c0 (LWP 22925)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771be1c in pthread_join () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf770987a in ContinueInNewThread0 () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/../lib/i386/jli/libjli.so #3 0xf7704e46 in ContinueInNewThread () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/../lib/i386/jli/libjli.so #4 0xf770974b in JVMInit () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/../lib/i386/jli/libjli.so #5 0xf7707c05 in JLI_Launch () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/../lib/i386/jli/libjli.so #6 0x080485bd in main () (gdb) From jon.masamitsu at oracle.com Wed Mar 6 04:46:42 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 05 Mar 2013 20:46:42 -0800 Subject: Request for review: 8007762: Rename a bunch of methods in size policy across collectors In-Reply-To: <51364015.7050503@oracle.com> References: <5109BCB9.7040706@oracle.com> <511465FE.7000408@oracle.com> <511D388A.4010700@oracle.com> <51224CBF.8050705@oracle.com> <512BB6E6.6060503@oracle.com> <512CE4C5.6080101@oracle.com> <51353E78.1040700@oracle.com> <51354057.1070308@oracle.com> <51359721.5030508@oracle.com> <51361DE6.8070807@oracle.com> <51364015.7050503@oracle.com> Message-ID: <5136CA32.6060303@oracle.com> Tao, Bengt was ok with leaving the name compute_generation_free_space() as is so I think we should do that. Bengt's point about methods needing better names probably applies to several methods and I'd rather consider a renaming scheme after your refactoring changes have been integrated. Jon On 3/5/2013 10:57 AM, Bengt Rutisson wrote: > > Jon, > > On 3/5/13 5:31 PM, Jon Masamitsu wrote: >> Bengt, >> >> Would a less specific name such as "update" be >> better? Something that says to the reader >> "you have to go look at what the method is >> doing because a name is not going to be >> descriptive enough". > > Yes, I think so. Something that indicates that this will have side > effects. In my earlier email I suggested > update_adaptive_size_values(). If you come up with something better > I'm happy too. :) > > Bengt > >> >> Jon >> >> On 03/04/13 22:56, Bengt Rutisson wrote: >>> >>> Hi Tao, >>> >>> The method PSAdaptiveSizePolicy::compute_generation_free_space() is >>> a monster method. It does all kinds of things. Its comment kind of >>> reveals this: >>> >>> 339 // Calculates optimial free space sizes for both the old and >>> young >>> 340 // generations. Stores results in _eden_size and _promo_size. >>> 341 // Takes current used space in all generations as input, as well >>> 342 // as an indication if a full gc has just been performed, for >>> use >>> 343 // in deciding if an OOM error should be thrown. >>> >>> So, I think that if we should rename it we should give it a name >>> that reflects this. The current name is not good, but I don't think >>> compute_generations_free_space() is much better. I would suggest to >>> either leave it unchanged or change to a more descriptive name. >>> >>> Maybe gether_adapitve_size_statistics() or >>> update_adaptive_size_values(). Not very happy with those names >>> either, but at least they indicate that ther eis more than just free >>> space calculations in there. >>> >>> >>> In psGCAdaptivePolicyCounters.hpp you updated a method name that has >>> been commented out. I would suggest removing it rather than updating >>> it. >>> >>> Thanks, >>> Bengt >>> >>> On 3/5/13 1:46 AM, Tao Mao wrote: >>>> Oops...sent to open list. >>>> >>>> Thanks. >>>> Tao >>>> >>>> On 3/4/2013 4:38 PM, Tao Mao wrote: >>>>> This is the proposed final webrev, with copyright dated >>>>> appropriately. >>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/ >>>>> >>>>> Jon, >>>>> A patch is rendered below. Please take the patch and help push the >>>>> changeset. >>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.02/8007762RenameMethodsInSizePolicy.patch >>>>> >>>>> >>>>> Thank you. >>>>> Tao >>>>> >>>>> On 2/26/13 8:37 AM, Jon Masamitsu wrote: >>>>>> Thanks. >>>>>> >>>>>> Looks good. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 02/25/13 11:09, Tao Mao wrote: >>>>>>> A new webrev is updated. >>>>>>> Thanks. >>>>>>> Tao >>>>>>> >>>>>>> On 2/18/2013 7:46 AM, Jon Masamitsu wrote: >>>>>>>> Tao, >>>>>>>> >>>>>>>> Why this change from resize_old_gen() to >>>>>>>> resize_tenured_gen()? There are many >>>>>>>> variable names and comments referring to >>>>>>>> "old gen" still in ParallelScavengeHeap. >>>>>>> Reverted. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On 02/14/13 11:18, Tao Mao wrote: >>>>>>>>> 8007762: Rename a bunch of methods in size policy across >>>>>>>>> collectors >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8007762 >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~tamao/8007762/webrev.00/ >>>>>>>>> >>>>>>>>> changeset: >>>>>>>>> The motivation of this change is associated with CR 7098155 >>>>>>>>> (https://jbs.oracle.com/bugs/browse/JDK-7098155). For this, we >>>>>>>>> need to split compute_generations_free_space into two routine >>>>>>>>> (one for compute_eden_space_size and the other for >>>>>>>>> compute_tenured_generation_free_space) in order to save some >>>>>>>>> overhead when we want to compute only one of the two. The next >>>>>>>>> step is to split >>>>>>>>> PSAdaptiveSizePolicy::compute_generations_free_space(), which >>>>>>>>> will be resolved in CR 8007763. >>>>>>>>> >>>>>>>>> To unify the naming, a bunch of routines are renamed here. >>>>>>>>> (1) compute_*: >>>>>>>>> compute_survivor_space_size_and_threshold() >>>>>>>>> compute_generations_free_space() = >>>>>>>>> compute_eden_space_size() + >>>>>>>>> compute_tenured_generation_free_space() >>>>>>>>> (2) resize_*_gen: >>>>>>>>> resize_young_gen() >>>>>>>>> resize_tenured_gen() >>>>>>>>> (3) rename judging routine resize_geneneration() to >>>>>>>>> need_resize() to avoid ambiguity >>>>>>>>> >>>>>>>>> testing: >>>>>>>>> purely renaming; passed JPRT >>>>>>>>> >>>>>>> >>>> >>> > > From john.cuthbertson at oracle.com Wed Mar 6 05:55:47 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Wed, 06 Mar 2013 05:55:47 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8008079: G1: Add nextObject routine to CMBitMapRO and replace nextWord Message-ID: <20130306055554.00A1F47881@hg.openjdk.java.net> Changeset: 9def4075da6d Author: tamao Date: 2013-03-05 15:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9def4075da6d 8008079: G1: Add nextObject routine to CMBitMapRO and replace nextWord Summary: Update the task local finger to the start of the next object when marking aborts, in order to avoid the redundant scanning of all 0's when the marking task restarts, if otherwise updating to the next word. In addition, reuse the routine nextObject() in routine iterate(). Reviewed-by: johnc, ysr Contributed-by: tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp From rednaxelafx at gmail.com Wed Mar 6 06:07:43 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 6 Mar 2013 14:07:43 +0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <01d201ce19eb$332d5160$9987f420$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: Hi Uwe, If you can attach gdb onto it, and jstack -m and jstack -F should also work; that'll get you the Java stack trace. (But it probably doesn't matter in this case, because the hang is probably bug in the VM). - Kris On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler wrote: > Hi, > > since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). > > JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). > > I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. > > To reproduce: > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) > - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) > - change to directory lucene/analysis/uima and run: > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" > > I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > From bengt.rutisson at oracle.com Wed Mar 6 07:01:24 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Mar 2013 08:01:24 +0100 Subject: Request for review: 8008368: Deprecate MaxGCMinorPauseMillis In-Reply-To: <51365D62.5040604@oracle.com> References: <512FAD5C.50103@oracle.com> <51359CA2.9070600@oracle.com> <51365D62.5040604@oracle.com> Message-ID: <5136E9C4.9060307@oracle.com> Hi Tao, Looks good to me. Thanks for fixing this! As for other GC flags that are deprecated we could potentially move the check for CMSIncrementalMode from check_deprecated_gcs() into your new check_deprecated_gc_flags(). 1821 if (CMSIncrementalMode) { 1822 warning("Using incremental CMS is deprecated and will likely be removed in a future release"); 1823 } But I don't think you have to do that now. Thanks, Bengt On 3/5/13 10:02 PM, Tao Mao wrote: > A new webrev is updated according to your feedback. > http://cr.openjdk.java.net/~tamao/8008368/webrev.01/ > > Plus, what are the other deprecated GC flags you mentioned? > > Thanks. > Tao > > On 3/4/13 11:20 PM, John Cuthbertson wrote: >> Hi Tao, >> >> I would change the name of the new routine to >> check_deprecated_gc_flags() and I would move the call to after the >> check_deprecated_gcs(). >> >> Other than the above it looks good. >> >> You may want to file an enhancement to move some the other deprecated >> GC flags, for which we emit warnings, into the new routine. >> >> JohnC >> >> On 2/28/2013 11:17 AM, Tao Mao wrote: >>> 8008368: Deprecate MaxGCMinorPauseMillis >>> https://jbs.oracle.com/bugs/browse/JDK-8008368 >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/8008368/webrev.00/ >>> >>> changeset: >>> We don't need the distinction between MaxGCMinorPauseMillis and >>> MaxGCPauseMillis. The MaxGCMinorPauseMillis flag was introduced as a >>> backup measure in case one pause target for all types collections >>> was not enough. As it has turned out it seems one pause target is >>> enough. Thus, we should deprecate MaxGCMinorPauseMillis and give a >>> warning when set. >>> >>> testing: >>> passed JPRT test(sanity) >>> >> From bengt.rutisson at oracle.com Wed Mar 6 07:49:41 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Mar 2013 08:49:41 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <01d201ce19eb$332d5160$9987f420$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: <5136F515.3040603@oracle.com> Hi Uwe, Thanks for the excellent bug report! I filed a bug to track the issue. It will hopefully show up soon here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009536 It looks like we are hanging while we are doing reference processing. I think this might be related to a recent change to use the same code for parallel and single threaded reference processing. Also, very happy to hear that you are doing thorough testing of JDK8! Thanks, Bengt On 3/5/13 10:48 PM, Uwe Schindler wrote: > Hi, > > since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). > > JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). > > I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. > > To reproduce: > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) > - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) > - change to directory lucene/analysis/uima and run: > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" > > I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > From david.holmes at oracle.com Wed Mar 6 07:52:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 17:52:26 +1000 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: <5136F5BA.7010409@oracle.com> If the VM is completely unresponsive then it suggests we are at a safepoint. The GC threads are not "hung" in os::parK, they are parked - waiting to be notified of something. The thing is to find out why they are not being woken up. Can the gdb log be posted somewhere? I don't know if the attachment made it to the original posting on hotspot-gc but it's no longer available on hotspot-dev. Thanks, David On 6/03/2013 4:07 PM, Krystal Mok wrote: > Hi Uwe, > > If you can attach gdb onto it, and jstack -m and jstack -F should also > work; that'll get you the Java stack trace. > (But it probably doesn't matter in this case, because the hang is > probably bug in the VM). > > - Kris > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler wrote: >> Hi, >> >> since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). >> >> JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). >> >> I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. >> >> To reproduce: >> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) >> - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) >> - change to directory lucene/analysis/uima and run: >> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test >> After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" >> >> I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. >> >> Uwe >> >> ----- >> Uwe Schindler >> uschindler at apache.org >> Apache Lucene PMC Member / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >> From dweiss at apache.org Wed Mar 6 07:55:28 2013 From: dweiss at apache.org (Dawid Weiss) Date: Wed, 6 Mar 2013 08:55:28 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5136F5BA.7010409@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> Message-ID: Here you go: http://pastebin.com/raw.php?i=b2PHLm1e Dawid On Wed, Mar 6, 2013 at 8:52 AM, David Holmes wrote: > If the VM is completely unresponsive then it suggests we are at a > safepoint. > > The GC threads are not "hung" in os::parK, they are parked - waiting to be > notified of something. > > The thing is to find out why they are not being woken up. > > Can the gdb log be posted somewhere? I don't know if the attachment made > it to the original posting on hotspot-gc but it's no longer available on > hotspot-dev. > > Thanks, > David > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > >> Hi Uwe, >> >> If you can attach gdb onto it, and jstack -m and jstack -F should also >> work; that'll get you the Java stack trace. >> (But it probably doesn't matter in this case, because the hang is >> probably bug in the VM). >> >> - Kris >> >> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >> wrote: >> >>> Hi, >>> >>> since a few month we are extensively testing various preview builds of >>> JDK 8 for compatibility with Apache Lucene and Solr, so we can find any >>> bugs early and prevent the problems we had with the release of Java 7 two >>> years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that >>> has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) >>> installed, choosing a different one with different hotspot and garbage >>> collector settings on every run of the test suite (which takes approx. >>> 30-45 minutes). >>> >>> JDK 8 b79 works so far very well on Linux, we found some strange >>> behavior in early versions (maybe compiler errors), but no longer at the >>> moment. There is one configuration that constantly and reproducibly hangs >>> in one module that is tested: The configuration uses JDK 8 b79 (same for >>> b78), 32 bit, and G1GC (server or client does not matter). The JVM running >>> the tests hangs irresponsible (jstack or kill -3 have no effect/cannot >>> connect, standard kill does not stop it, only kill -9 actually kills it). >>> It can be reproduced in this Lucene module 100% (it hangs always). >>> >>> I was able to connect with GDB to the JVM and get a stack trace on all >>> threads (see attachment, dump.txt). As you see all threads of G1GC seem to >>> hang in a syscall (os:park(), a conditional wait in pthread library). >>> Unfortunately that?s all I can give you. A Java stacktrace is not possible >>> because the JVM reacts on neither kill -3 nor jstack. With all other >>> garbage collectors it passes the test without hangs in a few seconds, with >>> 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, >>> so only the 32 bit variant is affected. Client or Server VM makes no >>> difference. >>> >>> To reproduce: >>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should >>> not matter) >>> - Download Lucene Source code (e.g. the snapshot version we were testing >>> with: https://builds.apache.org/job/**Lucene-Artifacts-trunk/2212/** >>> artifact/lucene/dist/ >>> ) >>> - change to directory lucene/analysis/uima and run: >>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>> -Dtests.jvms=1 test >>> After a while the test framework prints "stalled" messages (because the >>> child VM actually running the test no longer responds). The PID is also >>> printed. Try to get a stack trace or kill it, no response. Only kill -9 >>> helps. Choosing another garbage collector in the above command line makes >>> the test finish after a few seconds, e.g. -Dargs="-server >>> -XX:+UseConcMarkSweepGC" >>> >>> I posted this bug report directly to the mailing list, because with >>> earlier bug reports, there seem to be a problem with bugs.sun.com - >>> there is no response from any reviewer after several weeks and we were able >>> to help to find and fix javadoc and javac-compiler bugs early. So I hope >>> you can help for this bug, too. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> Apache Lucene PMC Member / Committer >>> Bremen, Germany >>> http://lucene.apache.org/ >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed Mar 6 08:04:24 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Mar 2013 09:04:24 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5136F5BA.7010409@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> Message-ID: <5136F888.6010501@oracle.com> David, I think this is a VM bug and the thread dumps that Uwe produced are enough to start tracking down the root cause. On 3/6/13 8:52 AM, David Holmes wrote: > If the VM is completely unresponsive then it suggests we are at a > safepoint. Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > > The GC threads are not "hung" in os::parK, they are parked - waiting > to be notified of something. It looks like the reference processing thread is stuck in a loop where it does wait(). So, the VM is hanging even if that stack trace also ends up in os::park(). > > The thing is to find out why they are not being woken up. Actually, in this case we should probably not even be calling wait... > > Can the gdb log be posted somewhere? I don't know if the attachment > made it to the original posting on hotspot-gc but it's no longer > available on hotspot-dev. I received the attachment with the original email. I've attached it to the bug report that I created: 8009536. You can find it there if you want to. But I think we have a fairly good idea of what change caused the hang. Bengt > > Thanks, > David > > On 6/03/2013 4:07 PM, Krystal Mok wrote: >> Hi Uwe, >> >> If you can attach gdb onto it, and jstack -m and jstack -F should also >> work; that'll get you the Java stack trace. >> (But it probably doesn't matter in this case, because the hang is >> probably bug in the VM). >> >> - Kris >> >> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >> wrote: >>> Hi, >>> >>> since a few month we are extensively testing various preview builds >>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can >>> find any bugs early and prevent the problems we had with the release >>> of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) >>> Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, >>> IBM J9, older JRockit) installed, choosing a different one with >>> different hotspot and garbage collector settings on every run of the >>> test suite (which takes approx. 30-45 minutes). >>> >>> JDK 8 b79 works so far very well on Linux, we found some strange >>> behavior in early versions (maybe compiler errors), but no longer at >>> the moment. There is one configuration that constantly and >>> reproducibly hangs in one module that is tested: The configuration >>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client >>> does not matter). The JVM running the tests hangs irresponsible >>> (jstack or kill -3 have no effect/cannot connect, standard kill does >>> not stop it, only kill -9 actually kills it). It can be reproduced >>> in this Lucene module 100% (it hangs always). >>> >>> I was able to connect with GDB to the JVM and get a stack trace on >>> all threads (see attachment, dump.txt). As you see all threads of >>> G1GC seem to hang in a syscall (os:park(), a conditional wait in >>> pthread library). Unfortunately that?s all I can give you. A Java >>> stacktrace is not possible because the JVM reacts on neither kill -3 >>> nor jstack. With all other garbage collectors it passes the test >>> without hangs in a few seconds, with 32 bit G1GC it can stand still >>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit >>> variant is affected. Client or Server VM makes no difference. >>> >>> To reproduce: >>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this >>> should not matter) >>> - Download Lucene Source code (e.g. the snapshot version we were >>> testing with: >>> https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) >>> - change to directory lucene/analysis/uima and run: >>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>> -Dtests.jvms=1 test >>> After a while the test framework prints "stalled" messages (because >>> the child VM actually running the test no longer responds). The PID >>> is also printed. Try to get a stack trace or kill it, no response. >>> Only kill -9 helps. Choosing another garbage collector in the above >>> command line makes the test finish after a few seconds, e.g. >>> -Dargs="-server -XX:+UseConcMarkSweepGC" >>> >>> I posted this bug report directly to the mailing list, because with >>> earlier bug reports, there seem to be a problem with bugs.sun.com - >>> there is no response from any reviewer after several weeks and we >>> were able to help to find and fix javadoc and javac-compiler bugs >>> early. So I hope you can help for this bug, too. >>> >>> Uwe >>> >>> ----- >>> Uwe Schindler >>> uschindler at apache.org >>> Apache Lucene PMC Member / Committer >>> Bremen, Germany >>> http://lucene.apache.org/ >>> >>> From bengt.rutisson at oracle.com Wed Mar 6 09:05:37 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Mar 2013 10:05:37 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> Message-ID: <513706E1.2070605@oracle.com> Erik and Staffan, The ProcessTools class has the method getPlatformSpecificVMArgs() that returns "-d64" if necessary. You can't use this as is since you need to get "J-d64" but I think we should do something to make your solution more general. Either adding a possible prefix to the getPlatformSpecificVMArgs() or adding a separate method that returns "JDK-tools formatted" args. It seems a bit too limited to fix this only for your particular test. Would be nice to get it in to the testlibrary somehow. Bengt On 3/5/13 5:55 PM, Staffan Larsen wrote: > Looks good. I wish we could abstract this away so that not every test needs to do this work. > > /Staffan (mobile) > > On 5 mar 2013, at 17:39, Erik Helin wrote: > >> Hi all, >> >> this change adds the option "-J-d64" or "-J-d32" (depending on arch) when running jmap in the test hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >> >> Thanks, >> Erik From uschindler at apache.org Wed Mar 6 10:12:09 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 11:12:09 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> Message-ID: <008f01ce1a53$103416e0$309c44a0$@apache.org> Thanks, I'll try to use jstack with -F or -m! Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Krystal Mok [mailto:rednaxelafx at gmail.com] > Sent: Wednesday, March 06, 2013 7:08 AM > To: Uwe Schindler > Cc: hotspot-gc-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > Dawid Weiss; dev at lucene.apache.org > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > If you can attach gdb onto it, and jstack -m and jstack -F should also work; > that'll get you the Java stack trace. > (But it probably doesn't matter in this case, because the hang is probably bug > in the VM). > > - Kris > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > wrote: > > Hi, > > > > since a few month we are extensively testing various preview builds of JDK > 8 for compatibility with Apache Lucene and Solr, so we can find any bugs > early and prevent the problems we had with the release of Java 7 two years > ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has > various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, > choosing a different one with different hotspot and garbage collector > settings on every run of the test suite (which takes approx. 30-45 minutes). > > > > JDK 8 b79 works so far very well on Linux, we found some strange behavior > in early versions (maybe compiler errors), but no longer at the moment. > There is one configuration that constantly and reproducibly hangs in one > module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 > bit, and G1GC (server or client does not matter). The JVM running the tests > hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard > kill does not stop it, only kill -9 actually kills it). It can be reproduced in this > Lucene module 100% (it hangs always). > > > > I was able to connect with GDB to the JVM and get a stack trace on all > threads (see attachment, dump.txt). As you see all threads of G1GC seem to > hang in a syscall (os:park(), a conditional wait in pthread library). > Unfortunately that?s all I can give you. A Java stacktrace is not possible > because the JVM reacts on neither kill -3 nor jstack. With all other garbage > collectors it passes the test without hangs in a few seconds, with 32 bit G1GC > it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit > variant is affected. Client or Server VM makes no difference. > > > > To reproduce: > > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > > should not matter) > > - Download Lucene Source code (e.g. the snapshot version we were > > testing with: > > https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/luc > > ene/dist/) > > - change to directory lucene/analysis/uima and run: > > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test After a while the test framework prints "stalled" > messages (because the child VM actually running the test no longer > responds). The PID is also printed. Try to get a stack trace or kill it, no > response. Only kill -9 helps. Choosing another garbage collector in the above > command line makes the test finish after a few seconds, e.g. -Dargs="-server > -XX:+UseConcMarkSweepGC" > > > > I posted this bug report directly to the mailing list, because with earlier bug > reports, there seem to be a problem with bugs.sun.com - there is no > response from any reviewer after several weeks and we were able to help to > find and fix javadoc and javac-compiler bugs early. So I hope you can help for > this bug, too. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org For additional > commands, e-mail: dev-help at lucene.apache.org From david.holmes at oracle.com Wed Mar 6 10:23:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 20:23:10 +1000 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> Message-ID: <5137190E.1060504@oracle.com> On 6/03/2013 5:55 PM, Dawid Weiss wrote: > > Here you go: > http://pastebin.com/raw.php?i=b2PHLm1e Thanks. I would have to say this seems to be the suspicious part: Thread 22 (Thread 0xf20ffb40 (LWP 22939)): #0 0xf7743430 in __kernel_vsyscall () #1 0xf771e96b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 #2 0xf6ec849c in os::PlatformEvent::park() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #3 0xf6e98b82 in Monitor::IWait(Thread*, long long) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #4 0xf6e99370 in Monitor::wait(bool, long, bool) () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #5 0xf6b5fb16 in SuspendibleThreadSet::join() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #6 0xf6b5ea41 in ConcurrentG1RefineThread::run_young_rs_sampling() () from /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so #7 0xf6b5ef91 in ConcurrentG1RefineThread::run() () The suspendible thread set logic looks 'tricky". Time for the G1 experts to take over. :) David > Dawid > > On Wed, Mar 6, 2013 at 8:52 AM, David Holmes > wrote: > > If the VM is completely unresponsive then it suggests we are at a > safepoint. > > The GC threads are not "hung" in os::parK, they are parked - waiting > to be notified of something. > > The thing is to find out why they are not being woken up. > > Can the gdb log be posted somewhere? I don't know if the attachment > made it to the original posting on hotspot-gc but it's no longer > available on hotspot-dev. > > Thanks, > David > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > > Hi Uwe, > > If you can attach gdb onto it, and jstack -m and jstack -F > should also > work; that'll get you the Java stack trace. > (But it probably doesn't matter in this case, because the hang is > probably bug in the VM). > > - Kris > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > > wrote: > > Hi, > > since a few month we are extensively testing various preview > builds of JDK 8 for compatibility with Apache Lucene and > Solr, so we can find any bugs early and prevent the problems > we had with the release of Java 7 two years ago. Currently > we have a Linux (Ubuntu 64bit) Jenkins machine that has > various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older > JRockit) installed, choosing a different one with different > hotspot and garbage collector settings on every run of the > test suite (which takes approx. 30-45 minutes). > > JDK 8 b79 works so far very well on Linux, we found some > strange behavior in early versions (maybe compiler errors), > but no longer at the moment. There is one configuration that > constantly and reproducibly hangs in one module that is > tested: The configuration uses JDK 8 b79 (same for b78), 32 > bit, and G1GC (server or client does not matter). The JVM > running the tests hangs irresponsible (jstack or kill -3 > have no effect/cannot connect, standard kill does not stop > it, only kill -9 actually kills it). It can be reproduced in > this Lucene module 100% (it hangs always). > > I was able to connect with GDB to the JVM and get a stack > trace on all threads (see attachment, dump.txt). As you see > all threads of G1GC seem to hang in a syscall (os:park(), a > conditional wait in pthread library). Unfortunately that?s > all I can give you. A Java stacktrace is not possible > because the JVM reacts on neither kill -3 nor jstack. With > all other garbage collectors it passes the test without > hangs in a few seconds, with 32 bit G1GC it can stand still > for hours. The 64 bit JVM passes with G1GC, so only the 32 > bit variant is affected. Client or Server VM makes no > difference. > > To reproduce: > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but > this should not matter) > - Download Lucene Source code (e.g. the snapshot version we > were testing with: > https://builds.apache.org/job/__Lucene-Artifacts-trunk/2212/__artifact/lucene/dist/ > ) > - change to directory lucene/analysis/uima and run: > ant -Dargs="-server -XX:+UseG1GC" > -Dtests.multiplier=3 -Dtests.jvms=1 test > After a while the test framework prints "stalled" messages > (because the child VM actually running the test no longer > responds). The PID is also printed. Try to get a stack trace > or kill it, no response. Only kill -9 helps. Choosing > another garbage collector in the above command line makes > the test finish after a few seconds, e.g. -Dargs="-server > -XX:+UseConcMarkSweepGC" > > I posted this bug report directly to the mailing list, > because with earlier bug reports, there seem to be a problem > with bugs.sun.com - there is no > response from any reviewer after several weeks and we were > able to help to find and fix javadoc and javac-compiler bugs > early. So I hope you can help for this bug, too. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > From uschindler at apache.org Wed Mar 6 11:16:54 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 12:16:54 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5136F888.6010501@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> Message-ID: <009001ce1a5c$1bcee3a0$536caae0$@apache.org> Hi, > I think this is a VM bug and the thread dumps that Uwe produced are enough > to start tracking down the root cause. I hope it is enough! If I can help with more details, tell me what I should do to track this down. Unfortunately, we have no isolated test case (like a small java class that triggers this bug) - you have to run the test cases of this Lucene's module. It only happens there, not in any other Lucene test suite. It may be caused by a lot of GC activity in this "UIMA" module or a specific test. > On 3/6/13 8:52 AM, David Holmes wrote: > > If the VM is completely unresponsive then it suggests we are at a > > safepoint. > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > > > > > The GC threads are not "hung" in os::parK, they are parked - waiting > > to be notified of something. > > It looks like the reference processing thread is stuck in a loop where it does > wait(). So, the VM is hanging even if that stack trace also ends up in > os::park(). > > > > > The thing is to find out why they are not being woken up. > > Actually, in this case we should probably not even be calling wait... > > > > > Can the gdb log be posted somewhere? I don't know if the attachment > > made it to the original posting on hotspot-gc but it's no longer > > available on hotspot-dev. > > I received the attachment with the original email. I've attached it to > the bug report that I created: 8009536. You can find it there if you > want to. But I think we have a fairly good idea of what change caused > the hang. If it helps: Unfortunately, we had some problems with recent JDK builds, because javac and javadoc tools were not working correctly, failing to build our source code. Since b78 this was fixed. Until this was fixed, we used build b65 (which was the last one working) and the G1GC hangs did not appear on this version. So it must have happened by a change after b65 till b78. Uwe > Bengt > > > > > Thanks, > > David > > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > >> Hi Uwe, > >> > >> If you can attach gdb onto it, and jstack -m and jstack -F should also > >> work; that'll get you the Java stack trace. > >> (But it probably doesn't matter in this case, because the hang is > >> probably bug in the VM). > >> > >> - Kris > >> > >> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > > >> wrote: > >>> Hi, > >>> > >>> since a few month we are extensively testing various preview builds > >>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can > >>> find any bugs early and prevent the problems we had with the release > >>> of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) > >>> Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, > >>> IBM J9, older JRockit) installed, choosing a different one with > >>> different hotspot and garbage collector settings on every run of the > >>> test suite (which takes approx. 30-45 minutes). > >>> > >>> JDK 8 b79 works so far very well on Linux, we found some strange > >>> behavior in early versions (maybe compiler errors), but no longer at > >>> the moment. There is one configuration that constantly and > >>> reproducibly hangs in one module that is tested: The configuration > >>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client > >>> does not matter). The JVM running the tests hangs irresponsible > >>> (jstack or kill -3 have no effect/cannot connect, standard kill does > >>> not stop it, only kill -9 actually kills it). It can be reproduced > >>> in this Lucene module 100% (it hangs always). > >>> > >>> I was able to connect with GDB to the JVM and get a stack trace on > >>> all threads (see attachment, dump.txt). As you see all threads of > >>> G1GC seem to hang in a syscall (os:park(), a conditional wait in > >>> pthread library). Unfortunately that?s all I can give you. A Java > >>> stacktrace is not possible because the JVM reacts on neither kill -3 > >>> nor jstack. With all other garbage collectors it passes the test > >>> without hangs in a few seconds, with 32 bit G1GC it can stand still > >>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit > >>> variant is affected. Client or Server VM makes no difference. > >>> > >>> To reproduce: > >>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > >>> should not matter) > >>> - Download Lucene Source code (e.g. the snapshot version we were > >>> testing with: > >>> https://builds.apache.org/job/Lucene-Artifacts- > trunk/2212/artifact/lucene/dist/) > >>> - change to directory lucene/analysis/uima and run: > >>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > >>> -Dtests.jvms=1 test > >>> After a while the test framework prints "stalled" messages (because > >>> the child VM actually running the test no longer responds). The PID > >>> is also printed. Try to get a stack trace or kill it, no response. > >>> Only kill -9 helps. Choosing another garbage collector in the above > >>> command line makes the test finish after a few seconds, e.g. > >>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>> > >>> I posted this bug report directly to the mailing list, because with > >>> earlier bug reports, there seem to be a problem with bugs.sun.com - > >>> there is no response from any reviewer after several weeks and we > >>> were able to help to find and fix javadoc and javac-compiler bugs > >>> early. So I hope you can help for this bug, too. > >>> > >>> Uwe > >>> > >>> ----- > >>> Uwe Schindler > >>> uschindler at apache.org > >>> Apache Lucene PMC Member / Committer > >>> Bremen, Germany > >>> http://lucene.apache.org/ > >>> > >>> From thomas.schatzl at oracle.com Wed Mar 6 11:18:08 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 12:18:08 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5137190E.1060504@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5137190E.1060504@oracle.com> Message-ID: <1362568688.2599.15.camel@cirrus> Hi, On Wed, 2013-03-06 at 20:23 +1000, David Holmes wrote: > On 6/03/2013 5:55 PM, Dawid Weiss wrote: > > > > Here you go: > > http://pastebin.com/raw.php?i=b2PHLm1e > > Thanks. I would have to say this seems to be the suspicious part: > > Thread 22 (Thread 0xf20ffb40 (LWP 22939)): [...] > from > /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/lib/i386/server/libjvm.so > #6 0xf6b5ea41 in ConcurrentG1RefineThread::run_young_rs_sampling() () > from > The suspendible thread set logic looks 'tricky". Time for the G1 experts > to take over. :) The young gen rs sampling thread is a thread that does some statistical updates while the application is running. So that in the STW pause not so much work needs to be done. At a safepoint it is always suspended, this is normal. As Bengt mentioned, the problem seems to be thread 10, which is the VM thread (the one responsible for bringing everything to a safepoint and then distributing work). According to the stack trace, this thread seems to be waiting for synchronization with the marking threads because of a mark stack overflow during weak reference processing. However all marking threads are already waiting due to the safepointing operation, and so it waits endlessly. As Bengt mentioned, this thread shouldn't be waiting, and shouldn't need to because it seems to be the only thread working on weak references anyway (i.e. this phase is single threaded). (All imo) Thomas From thomas.schatzl at oracle.com Wed Mar 6 12:08:15 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 13:08:15 +0100 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed Message-ID: <1362571695.2599.23.camel@cirrus> Hi all, this change always adds a timestamp marker for CMS concurrent phase messages as suggested by the CR. I added an extra space between timestamp and the original message for better readability. I.e. instead of printing [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 sys=0.00, real=0.09 secs] [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] the VM now prints 20.014 [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 sys=0.00, real=0.09 secs] 20.019 [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] if -XX:+PrintGCDetails is set with CMS. Webrev: http://cr.openjdk.java.net/~tschatzl/8008684/webrev/ Bugs http://bugs.sun.com/view_bug.do?bug_id=8008684 JIRA: https://jbs.oracle.com/bugs/browse/JDK-8008684 Testing: JPRT Thanks, Thomas From bengt.rutisson at oracle.com Wed Mar 6 12:08:17 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Mar 2013 13:08:17 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5136F888.6010501@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> Message-ID: <513731B1.1090708@oracle.com> Hi all, I sent this email earlier, but I did "reply list" instead of "reply all". Sorry about that. The hang is due to the fact that we are using single threaded reference processing but end up in the multi threaded code path and get stuck in a loop that waits for the other processing threads to terminate. John Cuthbertson is working on a fix for this. I think we have all the information we need to solve this. Bengt On 3/6/13 9:04 AM, Bengt Rutisson wrote: > > David, > > I think this is a VM bug and the thread dumps that Uwe produced are > enough to start tracking down the root cause. > > On 3/6/13 8:52 AM, David Holmes wrote: >> If the VM is completely unresponsive then it suggests we are at a >> safepoint. > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > >> >> The GC threads are not "hung" in os::parK, they are parked - waiting >> to be notified of something. > > It looks like the reference processing thread is stuck in a loop where > it does wait(). So, the VM is hanging even if that stack trace also > ends up in os::park(). > >> >> The thing is to find out why they are not being woken up. > > Actually, in this case we should probably not even be calling wait... > >> >> Can the gdb log be posted somewhere? I don't know if the attachment >> made it to the original posting on hotspot-gc but it's no longer >> available on hotspot-dev. > > I received the attachment with the original email. I've attached it to > the bug report that I created: 8009536. You can find it there if you > want to. But I think we have a fairly good idea of what change caused > the hang. > > Bengt > >> >> Thanks, >> David >> >> On 6/03/2013 4:07 PM, Krystal Mok wrote: >>> Hi Uwe, >>> >>> If you can attach gdb onto it, and jstack -m and jstack -F should also >>> work; that'll get you the Java stack trace. >>> (But it probably doesn't matter in this case, because the hang is >>> probably bug in the VM). >>> >>> - Kris >>> >>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >>> wrote: >>>> Hi, >>>> >>>> since a few month we are extensively testing various preview builds >>>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can >>>> find any bugs early and prevent the problems we had with the >>>> release of Java 7 two years ago. Currently we have a Linux (Ubuntu >>>> 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 >>>> snapshot, IBM J9, older JRockit) installed, choosing a different >>>> one with different hotspot and garbage collector settings on every >>>> run of the test suite (which takes approx. 30-45 minutes). >>>> >>>> JDK 8 b79 works so far very well on Linux, we found some strange >>>> behavior in early versions (maybe compiler errors), but no longer >>>> at the moment. There is one configuration that constantly and >>>> reproducibly hangs in one module that is tested: The configuration >>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client >>>> does not matter). The JVM running the tests hangs irresponsible >>>> (jstack or kill -3 have no effect/cannot connect, standard kill >>>> does not stop it, only kill -9 actually kills it). It can be >>>> reproduced in this Lucene module 100% (it hangs always). >>>> >>>> I was able to connect with GDB to the JVM and get a stack trace on >>>> all threads (see attachment, dump.txt). As you see all threads of >>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in >>>> pthread library). Unfortunately that?s all I can give you. A Java >>>> stacktrace is not possible because the JVM reacts on neither kill >>>> -3 nor jstack. With all other garbage collectors it passes the test >>>> without hangs in a few seconds, with 32 bit G1GC it can stand still >>>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit >>>> variant is affected. Client or Server VM makes no difference. >>>> >>>> To reproduce: >>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this >>>> should not matter) >>>> - Download Lucene Source code (e.g. the snapshot version we were >>>> testing with: >>>> https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/) >>>> - change to directory lucene/analysis/uima and run: >>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>>> -Dtests.jvms=1 test >>>> After a while the test framework prints "stalled" messages (because >>>> the child VM actually running the test no longer responds). The PID >>>> is also printed. Try to get a stack trace or kill it, no response. >>>> Only kill -9 helps. Choosing another garbage collector in the above >>>> command line makes the test finish after a few seconds, e.g. >>>> -Dargs="-server -XX:+UseConcMarkSweepGC" >>>> >>>> I posted this bug report directly to the mailing list, because with >>>> earlier bug reports, there seem to be a problem with bugs.sun.com - >>>> there is no response from any reviewer after several weeks and we >>>> were able to help to find and fix javadoc and javac-compiler bugs >>>> early. So I hope you can help for this bug, too. >>>> >>>> Uwe >>>> >>>> ----- >>>> Uwe Schindler >>>> uschindler at apache.org >>>> Apache Lucene PMC Member / Committer >>>> Bremen, Germany >>>> http://lucene.apache.org/ >>>> >>>> > From uschindler at apache.org Wed Mar 6 12:49:07 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 13:49:07 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <513731B1.1090708@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> Message-ID: <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> Hi Bengt, That was fast! We are happy that you were able to analyze the bug and will fix it soon. To not make our Jenkins server get stuck in the tests, I will disable G1GC until a new update is installed. We will then only test the other garbage collectors with Lucene. Do you have an idea, why this bug is not appearing on 64 bit? It might be caused by other GC behavior as the word size is different (the Lucene tests use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to understand this! I can run the test suite with 64 bit JDK over and over, it never hangs. But when running with 32 bit it hangs in all cases. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev- > bounces at openjdk.java.net] On Behalf Of Bengt Rutisson > Sent: Wednesday, March 06, 2013 1:08 PM > To: hotspot-gc-dev at openjdk.java.net; David Holmes; Dawid Weiss; hotspot- > dev at openjdk.java.net > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > > Hi all, > > I sent this email earlier, but I did "reply list" instead of "reply all". Sorry about > that. > > The hang is due to the fact that we are using single threaded reference > processing but end up in the multi threaded code path and get stuck in a loop > that waits for the other processing threads to terminate. > > John Cuthbertson is working on a fix for this. I think we have all the > information we need to solve this. > > Bengt > > On 3/6/13 9:04 AM, Bengt Rutisson wrote: > > > > David, > > > > I think this is a VM bug and the thread dumps that Uwe produced are > > enough to start tracking down the root cause. > > > > On 3/6/13 8:52 AM, David Holmes wrote: > >> If the VM is completely unresponsive then it suggests we are at a > >> safepoint. > > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > > > >> > >> The GC threads are not "hung" in os::parK, they are parked - waiting > >> to be notified of something. > > > > It looks like the reference processing thread is stuck in a loop where > > it does wait(). So, the VM is hanging even if that stack trace also > > ends up in os::park(). > > > >> > >> The thing is to find out why they are not being woken up. > > > > Actually, in this case we should probably not even be calling wait... > > > >> > >> Can the gdb log be posted somewhere? I don't know if the attachment > >> made it to the original posting on hotspot-gc but it's no longer > >> available on hotspot-dev. > > > > I received the attachment with the original email. I've attached it to > > the bug report that I created: 8009536. You can find it there if you > > want to. But I think we have a fairly good idea of what change caused > > the hang. > > > > Bengt > > > >> > >> Thanks, > >> David > >> > >> On 6/03/2013 4:07 PM, Krystal Mok wrote: > >>> Hi Uwe, > >>> > >>> If you can attach gdb onto it, and jstack -m and jstack -F should > >>> also work; that'll get you the Java stack trace. > >>> (But it probably doesn't matter in this case, because the hang is > >>> probably bug in the VM). > >>> > >>> - Kris > >>> > >>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > >>> wrote: > >>>> Hi, > >>>> > >>>> since a few month we are extensively testing various preview builds > >>>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can > >>>> find any bugs early and prevent the problems we had with the > >>>> release of Java 7 two years ago. Currently we have a Linux (Ubuntu > >>>> 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 > >>>> snapshot, IBM J9, older JRockit) installed, choosing a different > >>>> one with different hotspot and garbage collector settings on every > >>>> run of the test suite (which takes approx. 30-45 minutes). > >>>> > >>>> JDK 8 b79 works so far very well on Linux, we found some strange > >>>> behavior in early versions (maybe compiler errors), but no longer > >>>> at the moment. There is one configuration that constantly and > >>>> reproducibly hangs in one module that is tested: The configuration > >>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client > >>>> does not matter). The JVM running the tests hangs irresponsible > >>>> (jstack or kill -3 have no effect/cannot connect, standard kill > >>>> does not stop it, only kill -9 actually kills it). It can be > >>>> reproduced in this Lucene module 100% (it hangs always). > >>>> > >>>> I was able to connect with GDB to the JVM and get a stack trace on > >>>> all threads (see attachment, dump.txt). As you see all threads of > >>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in > >>>> pthread library). Unfortunately that?s all I can give you. A Java > >>>> stacktrace is not possible because the JVM reacts on neither kill > >>>> -3 nor jstack. With all other garbage collectors it passes the test > >>>> without hangs in a few seconds, with 32 bit G1GC it can stand still > >>>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit > >>>> variant is affected. Client or Server VM makes no difference. > >>>> > >>>> To reproduce: > >>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > >>>> should not matter) > >>>> - Download Lucene Source code (e.g. the snapshot version we were > >>>> testing with: > >>>> https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/ > >>>> lucene/dist/) > >>>> - change to directory lucene/analysis/uima and run: > >>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > >>>> -Dtests.jvms=1 test > >>>> After a while the test framework prints "stalled" messages (because > >>>> the child VM actually running the test no longer responds). The PID > >>>> is also printed. Try to get a stack trace or kill it, no response. > >>>> Only kill -9 helps. Choosing another garbage collector in the above > >>>> command line makes the test finish after a few seconds, e.g. > >>>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>>> > >>>> I posted this bug report directly to the mailing list, because with > >>>> earlier bug reports, there seem to be a problem with bugs.sun.com - > >>>> there is no response from any reviewer after several weeks and we > >>>> were able to help to find and fix javadoc and javac-compiler bugs > >>>> early. So I hope you can help for this bug, too. > >>>> > >>>> Uwe > >>>> > >>>> ----- > >>>> Uwe Schindler > >>>> uschindler at apache.org > >>>> Apache Lucene PMC Member / Committer Bremen, Germany > >>>> http://lucene.apache.org/ > >>>> > >>>> > > From thomas.schatzl at oracle.com Wed Mar 6 13:43:04 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 14:43:04 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> Message-ID: <1362577384.2599.32.camel@cirrus> Hi, On Wed, 2013-03-06 at 13:49 +0100, Uwe Schindler wrote: > Hi Bengt, > > That was fast! We are happy that you were able to analyze the bug and will fix it soon. To not make our Jenkins server get stuck in the tests, I will disable G1GC until a new update is installed. We will then only test the other garbage collectors with Lucene. > > Do you have an idea, why this bug is not appearing on 64 bit? It might be caused by other GC behavior as the word size is different (the Lucene tests use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to understand this! I can run the test suite with 64 bit JDK over and over, it never hangs. But when running with 32 bit it hangs in all cases. one possible reason is that the default mark stack size much is larger on 64 bit, so no mark stack overflow occurs. E.g. in globals.hpp: product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), \ You may want to try to set MarkStackSizeMax to 4M on 64 bit too to test this. This is just a hunch though. Thomas From jesper.wilhelmsson at oracle.com Wed Mar 6 16:04:48 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 06 Mar 2013 17:04:48 +0100 Subject: RFR: JDK-8008790 - Promotion failed tracing event for all GCs In-Reply-To: <512CDA9C.3050607@oracle.com> References: <512B5EB7.4050107@oracle.com> <512CDA9C.3050607@oracle.com> Message-ID: <51376920.3030704@oracle.com> Hi, Additional feedback resulted in a new webrev: http://cr.openjdk.java.net/~jwilhelm/8008790/webrev.hsx24.3/ Thanks, /Jesper On 26/2/13 4:54 PM, Jesper Wilhelmsson wrote: > Hi, > > After some internal feedback a new version of the webrev is available at: > > http://cr.openjdk.java.net/~jwilhelm/8008790/webrev.hsx24.2/ > > The biggest change is that the promotion failed event now is sent once per > thread instead of merging the info into one event. > > Thanks, > /Jesper > > > On 25/2/13 1:53 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> I'm looking for a couple of reviews for the promotion failed tracing event, now >> implemented for ParNew and Serial GC. >> >> I have replaced the existing counters and booleans with a PromotionFailedInfo >> object and uses that throughout, so now promotion failed reporting (through the >> tracing framework) looks the same and reports the same data for all young >> collectors. >> >> I have added two new fields to the promotion failed event: firstSize as reported >> by ParNew logging, and smallestSize which is the smallest object size that >> failed to promote. >> >> Webrew: http://cr.openjdk.java.net/~jwilhelm/8008790 >> >> Testing: Passes JPRT and the existing promotion failed tests with all collectors. >> >> Thanks, >> /Jesper From erik.helin at oracle.com Wed Mar 6 17:06:34 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 06 Mar 2013 18:06:34 +0100 Subject: RFR (M): 8008918: Reference statistics events for the tracing framework In-Reply-To: <1362385477.2590.9.camel@cirrus> References: <5130B692.6070908@oracle.com> <1362385477.2590.9.camel@cirrus> Message-ID: <5137779A.7040806@oracle.com> Hi Thomas, thanks for reviewing! Please see comments inline and an updated webrev located at: http://cr.openjdk.java.net/~ehelin/8008918/webrev.01/ On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2013-03-01 at 15:09 +0100, Erik Helin wrote: >> Hi all, >> >> this change adds the vm/gc/reference/statistics event to all collectors. >> >> Please note that this change depends on "8009232: Improve stats >> gathering code for reference processor" which is also out for review on >> hotspot-gc-dev at openjdk.java.net. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8008918/webrev.00/ >> >> Bug: >> https://jbs.oracle.com/bugs/browse/JDK-8008918 > > Minor: Maybe, in concurrentMarkSweepGeneration.cpp the declaration of > the stats record could be put inside the block. Agree, updated. On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > Do you think if there is an easy way to put the sequence of allocating > the stats record, calling rp->process_discovered_reference and the > report_gc_reference_processing into a single method that is called > everywhere? I don't think there is an easy way to do it :) Ideally I would like the ReferenceProcessor to take care of whether the reference processing should be run in parallel or not. If this was the case, then the code could have looked like the following everywhere: const ReferenceProcessorStats& stats = rp->process_discovered_references(...); gc_tracer->report_gc_reference_stats(stats); On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > This code sequence, is the same in all collectors, and seems to be a > good target for refactoring. Unfortunately, is is not exactly the same. Some collectors, for example ParNew, takes advantage of the fact that the caller checks whether the reference processing should be done in parallel or not: if (rp->processing_is_mt()) { ParNewRefProcTaskExecutor task_executor(*this, thread_state_set); rp->process_discovered_references(&is_alive, &keep_alive, &evacuate_followers, &task_executor); } else { thread_state_set.flush(); gch->set_par_threads(0); // 0 ==> non-parallel. gch->save_marks(); rp->process_discovered_references(&is_alive, &keep_alive, &evacuate_followers, NULL); } If one refactor the code so that the ReferenceProcessor decides if the reference processing should run in parallel, then one has to ensure that the collector specific logic in the different branches still are correct. This is a cleanup that we definitely should do, but I would like to see it done as a separate change to ease the reviewing. On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > I.e. what the change basically did is to replace the call to > process_discovered_reference by above sequence of three statements. I would say that the change made the code go from two to three lines. Before the code looked like: if (rp->processig_is_mt()) { rp->process... } else { rp->process... } gc_tracer->report_gc_reference_processing(rp->collect_statistics()); After the change, the code looks like: ReferenceProcessorStats stats; if (rp->processig_is_mt()) { stats = rp->process... } else { stats = rp->process... } gc_tracer->report_gc_reference_processing(stats); The only difference in terms of lines is the addition of the "stats" variable. In my opinion, this is a motivated cost for providing a more robust way to collect the statistics from the reference processor. What do you think? Thanks, Erik > Hth, > Thomas > > From jon.masamitsu at oracle.com Wed Mar 6 17:07:57 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 06 Mar 2013 09:07:57 -0800 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed In-Reply-To: <1362571695.2599.23.camel@cirrus> References: <1362571695.2599.23.camel@cirrus> Message-ID: <513777ED.6030209@oracle.com> Thomas, I've added a comment to the bug report to clarify what I think should be changed. Sorry that my original description was lacking. Please take a look and let me know if it is still not clear. Jon On 3/6/2013 4:08 AM, Thomas Schatzl wrote: > Hi all, > > this change always adds a timestamp marker for CMS concurrent phase > messages as suggested by the CR. > I added an extra space between timestamp and the original message for > better readability. > > I.e. instead of printing > > [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 sys=0.00, > real=0.09 secs] > [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 sys=0.00, > real=0.00 secs] > > the VM now prints > > 20.014 [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 > sys=0.00, real=0.09 secs] > 20.019 [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 > sys=0.00, real=0.00 secs] > > if -XX:+PrintGCDetails is set with CMS. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8008684/webrev/ > > Bugs > http://bugs.sun.com/view_bug.do?bug_id=8008684 > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-8008684 > > Testing: > JPRT > > Thanks, > Thomas > From jesper.wilhelmsson at oracle.com Wed Mar 6 17:24:43 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 06 Mar 2013 18:24:43 +0100 Subject: RFR (S): 8009232: Improve stats gathering code for reference processor In-Reply-To: <5135BC88.6080002@oracle.com> References: <51309249.3030006@oracle.com> <5135BC88.6080002@oracle.com> Message-ID: <51377BDB.3060808@oracle.com> Looks good! Minor nit: EventGCReferenceProcessing probably should be called EventGCReferenceStatistics Fix it'n'ship it! :-) /Jesper On 5/3/13 10:36 AM, Erik Helin wrote: > All, > > based on internal feedback, I've updated the change. > > The ReferenceProcessorStats class is now no longer a C++ "friend" with the > ReferenceProcessor class. Furthermore, the method > ReferenceProcessor::process_discovered_reflist now returns the number of > discovered references. > > I have also renamed GCTrace::report_gc_reference_processing to > GCTrace::report_gc_reference_stats and > GCTrace::send_gc_reference_processing_event to > GCTrace::send_gc_reference_stats_event. This was done because the name > of the event was previously changed from vm/gc/reference/processing to > vm/gc/reference/statistics. > > New webrev: > http://cr.openjdk.java.net/~ehelin/8009232/webrev.01/ > > Thanks, > Erik > > On 03/01/2013 12:34 PM, Erik Helin wrote: >> Hi all, >> >> this change refactors the way the reference processing statistics are >> being collected from the reference processor. >> >> Summary: >> Before, the statistics were collected by calling >> ReferenceProcessor::collect_statistics immediately after a call to >> ReferenceProcessor::process_discovered_references. With this change, the >> method process_discovered_references instead returns >> the statistics. >> >> The benefit is that there is now no need to keep track of an internal >> state in ReferenceProcessor since the ReferenceProcessorStats can be put >> on the stack in process_discovered_references. Furthermore, the code is >> more maintainable, since the old code required the calls to >> process_discovered_references and collect_statistics to go "hand in >> hand". Now, one only has to care about the call to >> process_discovered_references. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8009232/webrev.00/ >> >> Bug: >> https://jbs.oracle.com/bugs/browse/JDK-8009232 >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From jesper.wilhelmsson at oracle.com Wed Mar 6 17:44:17 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 06 Mar 2013 18:44:17 +0100 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <5130E68A.4040806@oracle.com> References: <5130E68A.4040806@oracle.com> Message-ID: <51378071.2060107@oracle.com> Looks good! Since we want to implement this event for G1 as well, maybe we should remove the "CMS" from the event name and path? Thanks, /Jesper On 1/3/13 6:34 PM, Kevin Walls wrote: > Hi, > > I'd like some reviews on this CMS Concurrent Mode Failure event: > > http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ > > The event doesn't actually carry any new information, but it is a warning we > need to capture. > > This is against hsx24, I'll prepare the same, or reviewed, changes against very > latest hotspot also. > > Thanks > Kevin > From jesper.wilhelmsson at oracle.com Wed Mar 6 17:45:30 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 06 Mar 2013 18:45:30 +0100 Subject: RFR (M): 8008918: Reference statistics events for the tracing framework In-Reply-To: <5137779A.7040806@oracle.com> References: <5130B692.6070908@oracle.com> <1362385477.2590.9.camel@cirrus> <5137779A.7040806@oracle.com> Message-ID: <513780BA.8010202@oracle.com> Looks good! Ship it! /Jesper On 6/3/13 6:06 PM, Erik Helin wrote: > Hi Thomas, > > thanks for reviewing! > > Please see comments inline and an updated webrev located at: > http://cr.openjdk.java.net/~ehelin/8008918/webrev.01/ > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > Hi, > > > > On Fri, 2013-03-01 at 15:09 +0100, Erik Helin wrote: > >> Hi all, > >> > >> this change adds the vm/gc/reference/statistics event to all collectors. > >> > >> Please note that this change depends on "8009232: Improve stats > >> gathering code for reference processor" which is also out for review on > >> hotspot-gc-dev at openjdk.java.net. > >> > >> Webrev: > >> http://cr.openjdk.java.net/~ehelin/8008918/webrev.00/ > >> > >> Bug: > >> https://jbs.oracle.com/bugs/browse/JDK-8008918 > > > > Minor: Maybe, in concurrentMarkSweepGeneration.cpp the declaration of > > the stats record could be put inside the block. > > Agree, updated. > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > Do you think if there is an easy way to put the sequence of allocating > > the stats record, calling rp->process_discovered_reference and the > > report_gc_reference_processing into a single method that is called > > everywhere? > > I don't think there is an easy way to do it :) > > Ideally I would like the ReferenceProcessor to take care of whether the > reference processing should be run in parallel or not. If this was the case, > then the code could have looked like the following everywhere: > > const ReferenceProcessorStats& stats = > rp->process_discovered_references(...); > gc_tracer->report_gc_reference_stats(stats); > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > This code sequence, is the same in all collectors, and seems to be a > > good target for refactoring. > > Unfortunately, is is not exactly the same. Some collectors, for example > ParNew, takes advantage of the fact that the caller checks whether the > reference processing should be done in parallel or not: > > if (rp->processing_is_mt()) { > ParNewRefProcTaskExecutor task_executor(*this, thread_state_set); > rp->process_discovered_references(&is_alive, &keep_alive, > &evacuate_followers, &task_executor); > } else { > thread_state_set.flush(); > gch->set_par_threads(0); // 0 ==> non-parallel. > gch->save_marks(); > rp->process_discovered_references(&is_alive, &keep_alive, > &evacuate_followers, NULL); > } > > If one refactor the code so that the ReferenceProcessor decides if the > reference processing should run in parallel, then one has to ensure that > the collector specific logic in the different branches still are > correct. > > This is a cleanup that we definitely should do, but I would like to see > it done as a separate change to ease the reviewing. > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > I.e. what the change basically did is to replace the call to > > process_discovered_reference by above sequence of three statements. > > I would say that the change made the code go from two to three lines. > Before the code looked like: > > if (rp->processig_is_mt()) { > rp->process... > } else { > rp->process... > } > gc_tracer->report_gc_reference_processing(rp->collect_statistics()); > > After the change, the code looks like: > > ReferenceProcessorStats stats; > if (rp->processig_is_mt()) { > stats = rp->process... > } else { > stats = rp->process... > } > gc_tracer->report_gc_reference_processing(stats); > > The only difference in terms of lines is the addition of the "stats" variable. > > In my opinion, this is a motivated cost for providing a more robust way to > collect the statistics from the reference processor. What do you think? > > Thanks, > Erik > > > Hth, > > Thomas > > > > > From erik.helin at oracle.com Wed Mar 6 18:01:18 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 06 Mar 2013 19:01:18 +0100 Subject: RFR: JDK-8008790 - Promotion failed tracing event for all GCs In-Reply-To: <51376920.3030704@oracle.com> References: <512B5EB7.4050107@oracle.com> <512CDA9C.3050607@oracle.com> <51376920.3030704@oracle.com> Message-ID: <5137846E.30904@oracle.com> Hi Jesper, looks good. Thanks, Erik On 03/06/2013 05:04 PM, Jesper Wilhelmsson wrote: > Hi, > > Additional feedback resulted in a new webrev: > > http://cr.openjdk.java.net/~jwilhelm/8008790/webrev.hsx24.3/ > > Thanks, > /Jesper > > > On 26/2/13 4:54 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> After some internal feedback a new version of the webrev is available at: >> >> http://cr.openjdk.java.net/~jwilhelm/8008790/webrev.hsx24.2/ >> >> The biggest change is that the promotion failed event now is sent once >> per >> thread instead of merging the info into one event. >> >> Thanks, >> /Jesper >> >> >> On 25/2/13 1:53 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> I'm looking for a couple of reviews for the promotion failed tracing >>> event, now >>> implemented for ParNew and Serial GC. >>> >>> I have replaced the existing counters and booleans with a >>> PromotionFailedInfo >>> object and uses that throughout, so now promotion failed reporting >>> (through the >>> tracing framework) looks the same and reports the same data for all >>> young >>> collectors. >>> >>> I have added two new fields to the promotion failed event: firstSize >>> as reported >>> by ParNew logging, and smallestSize which is the smallest object size >>> that >>> failed to promote. >>> >>> Webrew: http://cr.openjdk.java.net/~jwilhelm/8008790 >>> >>> Testing: Passes JPRT and the existing promotion failed tests with all >>> collectors. >>> >>> Thanks, >>> /Jesper From john.cuthbertson at oracle.com Wed Mar 6 18:04:16 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 10:04:16 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <1362577384.2599.32.camel@cirrus> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> Message-ID: <51378520.6060908@oracle.com> Hi Everyone, All: I've looked at the bug report (haven't tried to reproduce it yet) and Bengt's analysis is correct. The concurrent mark thread is entering the synchronization protocol in a marking step call. That code is waiting for some non-existent workers to terminate before proceeding. Normally we shouldn't be entering that code but I think we overflowed the global marking stack (I updated the CR at ~1am my time with that conjecture). I think I missed a set_phase() call to tell the parallel terminator that we only have one thread and it's picking up the number of workers that executed the remark parallel task. Thomas: you were on the right track with your comment about the marking stack size. David: Thanks for helping out here. The stack trace you mentioned was for one the refinement threads - a concurrent GC thread. When a concurrent GC thread "joins" the suspendible thread set, it means that it will observe and participate in safepoint operations, i.e. the thread will notice that it should reach a safepoint and the safepoint synchronizer code will wait for it to block. When we wish a concurrent GC thread to not observe safepoints, that thread leaves the suspendible thread set. I think the name could be a bit better and Tony, before he left, had a change that used a scoped object to join and leave the STS that hasn't been integrated yet. IIRC Tony wasn't happy with the name he chose for that also. Uwe: Thanks for bringing this up and my apologies for not replying sooner. I will have a fix fairly soon. If I'm correct about it being caused by overflowing the marking stack you can work around the issue by increasing the MarkStackSize.you could try increasing it to 2M or 4M entries (which is the current max size). Cheers, JohnC On 3/6/2013 5:43 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-03-06 at 13:49 +0100, Uwe Schindler wrote: >> Hi Bengt, >> >> That was fast! We are happy that you were able to analyze the bug and will fix it soon. To not make our Jenkins server get stuck in the tests, I will disable G1GC until a new update is installed. We will then only test the other garbage collectors with Lucene. >> >> Do you have an idea, why this bug is not appearing on 64 bit? It might be caused by other GC behavior as the word size is different (the Lucene tests use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to understand this! I can run the test suite with 64 bit JDK over and over, it never hangs. But when running with 32 bit it hangs in all cases. > one possible reason is that the default mark stack size much is larger > on 64 bit, so no mark stack overflow occurs. > > E.g. in globals.hpp: > > product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), > \ > > You may want to try to set MarkStackSizeMax to 4M on 64 bit too to test > this. > > This is just a hunch though. > > Thomas > > From erik.helin at oracle.com Wed Mar 6 18:19:09 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 06 Mar 2013 19:19:09 +0100 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <5130E68A.4040806@oracle.com> References: <5130E68A.4040806@oracle.com> Message-ID: <5137889D.2080200@oracle.com> Hi Kevin, I think that there _might_ be a bug in CMS which was present even before you added the event tracing. If you look in aquire_control_and_collect, you will see that "should_compact" can be set to false by decide_foreground_collection_type. If this is the case, then we will end up in do_mark_sweep_work. The problem is that you have already reported, and CMS has already printed, that a concurrent mode failure has occurred in acquire_control_and_collect. Then, when you enter do_mark_sweep_work, you will once again report, and CMS will again print, that concurrent mode failure has happened. I am not 100% sure that I am right, by I believe that this can happen. What do you think? Thanks, Erik On 03/01/2013 06:34 PM, Kevin Walls wrote: > Hi, > > I'd like some reviews on this CMS Concurrent Mode Failure event: > > http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ > > The event doesn't actually carry any new information, but it is a > warning we need to capture. > > This is against hsx24, I'll prepare the same, or reviewed, changes > against very latest hotspot also. > > Thanks > Kevin > From uschindler at apache.org Wed Mar 6 18:50:35 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 19:50:35 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51378520.6060908@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> Message-ID: <006201ce1a9b$7ccb14a0$76613de0$@apache.org> Hi John, Thanks for the response and the analysis, very informative! > Hi Everyone, > > All: > I've looked at the bug report (haven't tried to reproduce it yet) and Bengt's > analysis is correct. The concurrent mark thread is entering the > synchronization protocol in a marking step call. That code is waiting for some > non-existent workers to terminate before proceeding. Normally we > shouldn't be entering that code but I think we overflowed the global marking > stack (I updated the CR at ~1am my time with that conjecture). I think I > missed a set_phase() call to tell the parallel terminator that we only have one > thread and it's picking up the number of workers that executed the remark > parallel task. > > Thomas: you were on the right track with your comment about the marking > stack size. > > David: > Thanks for helping out here. The stack trace you mentioned was for one the > refinement threads - a concurrent GC thread. When a concurrent GC thread > "joins" the suspendible thread set, it means that it will observe and > participate in safepoint operations, i.e. the thread will notice that it should > reach a safepoint and the safepoint synchronizer code will wait for it to block. > When we wish a concurrent GC thread to not observe safepoints, that > thread leaves the suspendible thread set. I think the name could be a bit > better and Tony, before he left, had a change that used a scoped object to > join and leave the STS that hasn't been integrated yet. IIRC Tony wasn't > happy with the name he chose for that also. > > Uwe: > Thanks for bringing this up and my apologies for not replying sooner. I will > have a fix fairly soon. If I'm correct about it being caused by overflowing the > marking stack you can work around the issue by increasing the > MarkStackSize.you could try increasing it to 2M or 4M entries (which is the > current max size). Is there a setting on the command line to raise this size? This would be great to check out if one can also do the opposite (lower the size on 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I am not so familiar with building the JVM on Ubuntu machines (including the needed IcedTea), so it's hard to me to try this out - I would not even know how to start doing this or finally how to get something like a standard JDK directory so you could use it as JAVA_HOME. If you need a verification that your patch is working, it would be good to get a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins server that found the bug. Otherwise we would need to wait until a new build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac tool and the class library that we reported earlier). I could also assist in setting up a Lucene build directory (as reported on the first email), to reproduce the problem with the Lucene source code (which is very easy). As said before, I have no isolated test case :( Thanks in any case, Uwe > Cheers, > > JohnC > > On 3/6/2013 5:43 AM, Thomas Schatzl wrote: > > Hi, > > > > On Wed, 2013-03-06 at 13:49 +0100, Uwe Schindler wrote: > >> Hi Bengt, > >> > >> That was fast! We are happy that you were able to analyze the bug and > will fix it soon. To not make our Jenkins server get stuck in the tests, I will > disable G1GC until a new update is installed. We will then only test the other > garbage collectors with Lucene. > >> > >> Do you have an idea, why this bug is not appearing on 64 bit? It might be > caused by other GC behavior as the word size is different (the Lucene tests > use -Xmx512M, so its fixed in 32 and 64 bit at the moment). I just want to > understand this! I can run the test suite with 64 bit JDK over and over, it > never hangs. But when running with 32 bit it hangs in all cases. > > one possible reason is that the default mark stack size much is > > larger on 64 bit, so no mark stack overflow occurs. > > > > E.g. in globals.hpp: > > > > product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), > \ > > > > You may want to try to set MarkStackSizeMax to 4M on 64 bit too to > > test this. > > > > This is just a hunch though. > > > > Thomas > > > > From john.cuthbertson at oracle.com Wed Mar 6 18:51:21 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 10:51:21 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <009001ce1a5c$1bcee3a0$536caae0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> Message-ID: <51379029.8090904@oracle.com> Hi Uwe, I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/ I don't have ant on my workstation so do you have a java command line to run the test(s) that generate the error? Thanks, JohnC On 3/6/2013 3:16 AM, Uwe Schindler wrote: > Hi, > >> I think this is a VM bug and the thread dumps that Uwe produced are enough >> to start tracking down the root cause. > I hope it is enough! If I can help with more details, tell me what I should do to track this down. Unfortunately, we have no isolated test case (like a small java class that triggers this bug) - you have to run the test cases of this Lucene's module. It only happens there, not in any other Lucene test suite. It may be caused by a lot of GC activity in this "UIMA" module or a specific test. > >> On 3/6/13 8:52 AM, David Holmes wrote: >>> If the VM is completely unresponsive then it suggests we are at a >>> safepoint. >> Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. >> >>> The GC threads are not "hung" in os::parK, they are parked - waiting >>> to be notified of something. >> It looks like the reference processing thread is stuck in a loop where it does >> wait(). So, the VM is hanging even if that stack trace also ends up in >> os::park(). >> >>> The thing is to find out why they are not being woken up. >> Actually, in this case we should probably not even be calling wait... >> >>> Can the gdb log be posted somewhere? I don't know if the attachment >>> made it to the original posting on hotspot-gc but it's no longer >>> available on hotspot-dev. >> I received the attachment with the original email. I've attached it to >> the bug report that I created: 8009536. You can find it there if you >> want to. But I think we have a fairly good idea of what change caused >> the hang. > If it helps: Unfortunately, we had some problems with recent JDK builds, because javac and javadoc tools were not working correctly, failing to build our source code. Since b78 this was fixed. Until this was fixed, we used build b65 (which was the last one working) and the G1GC hangs did not appear on this version. So it must have happened by a change after b65 till b78. > > Uwe > >> Bengt >> >>> Thanks, >>> David >>> >>> On 6/03/2013 4:07 PM, Krystal Mok wrote: >>>> Hi Uwe, >>>> >>>> If you can attach gdb onto it, and jstack -m and jstack -F should also >>>> work; that'll get you the Java stack trace. >>>> (But it probably doesn't matter in this case, because the hang is >>>> probably bug in the VM). >>>> >>>> - Kris >>>> >>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >> >>>> wrote: >>>>> Hi, >>>>> >>>>> since a few month we are extensively testing various preview builds >>>>> of JDK 8 for compatibility with Apache Lucene and Solr, so we can >>>>> find any bugs early and prevent the problems we had with the release >>>>> of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) >>>>> Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, >>>>> IBM J9, older JRockit) installed, choosing a different one with >>>>> different hotspot and garbage collector settings on every run of the >>>>> test suite (which takes approx. 30-45 minutes). >>>>> >>>>> JDK 8 b79 works so far very well on Linux, we found some strange >>>>> behavior in early versions (maybe compiler errors), but no longer at >>>>> the moment. There is one configuration that constantly and >>>>> reproducibly hangs in one module that is tested: The configuration >>>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client >>>>> does not matter). The JVM running the tests hangs irresponsible >>>>> (jstack or kill -3 have no effect/cannot connect, standard kill does >>>>> not stop it, only kill -9 actually kills it). It can be reproduced >>>>> in this Lucene module 100% (it hangs always). >>>>> >>>>> I was able to connect with GDB to the JVM and get a stack trace on >>>>> all threads (see attachment, dump.txt). As you see all threads of >>>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in >>>>> pthread library). Unfortunately that?s all I can give you. A Java >>>>> stacktrace is not possible because the JVM reacts on neither kill -3 >>>>> nor jstack. With all other garbage collectors it passes the test >>>>> without hangs in a few seconds, with 32 bit G1GC it can stand still >>>>> for hours. The 64 bit JVM passes with G1GC, so only the 32 bit >>>>> variant is affected. Client or Server VM makes no difference. >>>>> >>>>> To reproduce: >>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this >>>>> should not matter) >>>>> - Download Lucene Source code (e.g. the snapshot version we were >>>>> testing with: >>>>> https://builds.apache.org/job/Lucene-Artifacts- >> trunk/2212/artifact/lucene/dist/) >>>>> - change to directory lucene/analysis/uima and run: >>>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>>>> -Dtests.jvms=1 test >>>>> After a while the test framework prints "stalled" messages (because >>>>> the child VM actually running the test no longer responds). The PID >>>>> is also printed. Try to get a stack trace or kill it, no response. >>>>> Only kill -9 helps. Choosing another garbage collector in the above >>>>> command line makes the test finish after a few seconds, e.g. >>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" >>>>> >>>>> I posted this bug report directly to the mailing list, because with >>>>> earlier bug reports, there seem to be a problem with bugs.sun.com - >>>>> there is no response from any reviewer after several weeks and we >>>>> were able to help to find and fix javadoc and javac-compiler bugs >>>>> early. So I hope you can help for this bug, too. >>>>> >>>>> Uwe >>>>> >>>>> ----- >>>>> Uwe Schindler >>>>> uschindler at apache.org >>>>> Apache Lucene PMC Member / Committer >>>>> Bremen, Germany >>>>> http://lucene.apache.org/ >>>>> >>>>> From john.cuthbertson at oracle.com Wed Mar 6 18:56:06 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 10:56:06 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <006201ce1a9b$7ccb14a0$76613de0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> Message-ID: <51379146.4040106@oracle.com> Hi Uwe, You must have been reading my mind. See inline.... On 3/6/2013 10:50 AM, Uwe Schindler wrote: > Hi John, > > Thanks for the response and the analysis, very informative! > >> Uwe: >> Thanks for bringing this up and my apologies for not replying sooner. I will >> have a fix fairly soon. If I'm correct about it being caused by overflowing the >> marking stack you can work around the issue by increasing the >> MarkStackSize.you could try increasing it to 2M or 4M entries (which is the >> current max size). > Is there a setting on the command line to raise this size? This would be great to check out if one can also do the opposite (lower the size on 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I am not so familiar with building the JVM on Ubuntu machines (including the needed IcedTea), so it's hard to me to try this out - I would not even know how to start doing this or finally how to get something like a standard JDK directory so you could use it as JAVA_HOME. Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit run. > If you need a verification that your patch is working, it would be good to get a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins server that found the bug. Otherwise we would need to wait until a new build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac tool and the class library that we reported earlier). > > I could also assist in setting up a Lucene build directory (as reported on the first email), to reproduce the problem with the Lucene source code (which is very easy). As said before, I have no isolated test case :( > I just sent you email. I downloaded a zip file that contains all the jar files. I don't have ant on my system so ideally I'm looking for a java command line to tickle the crash. Can you help? Thanks, JohnC From uschindler at apache.org Wed Mar 6 19:15:24 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 20:15:24 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51379029.8090904@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> Message-ID: <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> Hi, That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. If you want to do it quicker (should be quite fast to do): - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8): http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... - put the ANT bin/ dir into your PATH - download the Apache Lucene source code from Jenkins: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) - change to the module that fails: # cd analysis/uima - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Wednesday, March 06, 2013 7:51 PM > To: Uwe Schindler > Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from > https://builds.apache.org/job/Lucene-Artifacts- > trunk/2212/artifact/lucene/dist/ > > I don't have ant on my workstation so do you have a java command line to > run the test(s) that generate the error? > > Thanks, > > JohnC > > On 3/6/2013 3:16 AM, Uwe Schindler wrote: > > Hi, > > > >> I think this is a VM bug and the thread dumps that Uwe produced are > >> enough to start tracking down the root cause. > > I hope it is enough! If I can help with more details, tell me what I should do > to track this down. Unfortunately, we have no isolated test case (like a small > java class that triggers this bug) - you have to run the test cases of this > Lucene's module. It only happens there, not in any other Lucene test suite. It > may be caused by a lot of GC activity in this "UIMA" module or a specific test. > > > >> On 3/6/13 8:52 AM, David Holmes wrote: > >>> If the VM is completely unresponsive then it suggests we are at a > >>> safepoint. > >> Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > >> > >>> The GC threads are not "hung" in os::parK, they are parked - waiting > >>> to be notified of something. > >> It looks like the reference processing thread is stuck in a loop > >> where it does wait(). So, the VM is hanging even if that stack trace > >> also ends up in os::park(). > >> > >>> The thing is to find out why they are not being woken up. > >> Actually, in this case we should probably not even be calling wait... > >> > >>> Can the gdb log be posted somewhere? I don't know if the attachment > >>> made it to the original posting on hotspot-gc but it's no longer > >>> available on hotspot-dev. > >> I received the attachment with the original email. I've attached it > >> to the bug report that I created: 8009536. You can find it there if > >> you want to. But I think we have a fairly good idea of what change > >> caused the hang. > > If it helps: Unfortunately, we had some problems with recent JDK builds, > because javac and javadoc tools were not working correctly, failing to build > our source code. Since b78 this was fixed. Until this was fixed, we used build > b65 (which was the last one working) and the G1GC hangs did not appear on > this version. So it must have happened by a change after b65 till b78. > > > > Uwe > > > >> Bengt > >> > >>> Thanks, > >>> David > >>> > >>> On 6/03/2013 4:07 PM, Krystal Mok wrote: > >>>> Hi Uwe, > >>>> > >>>> If you can attach gdb onto it, and jstack -m and jstack -F should > >>>> also work; that'll get you the Java stack trace. > >>>> (But it probably doesn't matter in this case, because the hang is > >>>> probably bug in the VM). > >>>> > >>>> - Kris > >>>> > >>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > >> > >>>> wrote: > >>>>> Hi, > >>>>> > >>>>> since a few month we are extensively testing various preview > >>>>> builds of JDK 8 for compatibility with Apache Lucene and Solr, so > >>>>> we can find any bugs early and prevent the problems we had with > >>>>> the release of Java 7 two years ago. Currently we have a Linux > >>>>> (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK > >>>>> 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a > >>>>> different one with different hotspot and garbage collector > >>>>> settings on every run of the test suite (which takes approx. 30-45 > minutes). > >>>>> > >>>>> JDK 8 b79 works so far very well on Linux, we found some strange > >>>>> behavior in early versions (maybe compiler errors), but no longer > >>>>> at the moment. There is one configuration that constantly and > >>>>> reproducibly hangs in one module that is tested: The configuration > >>>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client > >>>>> does not matter). The JVM running the tests hangs irresponsible > >>>>> (jstack or kill -3 have no effect/cannot connect, standard kill > >>>>> does not stop it, only kill -9 actually kills it). It can be > >>>>> reproduced in this Lucene module 100% (it hangs always). > >>>>> > >>>>> I was able to connect with GDB to the JVM and get a stack trace on > >>>>> all threads (see attachment, dump.txt). As you see all threads of > >>>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in > >>>>> pthread library). Unfortunately that?s all I can give you. A Java > >>>>> stacktrace is not possible because the JVM reacts on neither kill > >>>>> -3 nor jstack. With all other garbage collectors it passes the > >>>>> test without hangs in a few seconds, with 32 bit G1GC it can stand > >>>>> still for hours. The 64 bit JVM passes with G1GC, so only the 32 > >>>>> bit variant is affected. Client or Server VM makes no difference. > >>>>> > >>>>> To reproduce: > >>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > >>>>> should not matter) > >>>>> - Download Lucene Source code (e.g. the snapshot version we were > >>>>> testing with: > >>>>> https://builds.apache.org/job/Lucene-Artifacts- > >> trunk/2212/artifact/lucene/dist/) > >>>>> - change to directory lucene/analysis/uima and run: > >>>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > >>>>> -Dtests.jvms=1 test > >>>>> After a while the test framework prints "stalled" messages > >>>>> (because the child VM actually running the test no longer > >>>>> responds). The PID is also printed. Try to get a stack trace or kill it, no > response. > >>>>> Only kill -9 helps. Choosing another garbage collector in the > >>>>> above command line makes the test finish after a few seconds, e.g. > >>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>>>> > >>>>> I posted this bug report directly to the mailing list, because > >>>>> with earlier bug reports, there seem to be a problem with > >>>>> bugs.sun.com - there is no response from any reviewer after > >>>>> several weeks and we were able to help to find and fix javadoc and > >>>>> javac-compiler bugs early. So I hope you can help for this bug, too. > >>>>> > >>>>> Uwe > >>>>> > >>>>> ----- > >>>>> Uwe Schindler > >>>>> uschindler at apache.org > >>>>> Apache Lucene PMC Member / Committer Bremen, Germany > >>>>> http://lucene.apache.org/ > >>>>> > >>>>> From uschindler at apache.org Wed Mar 6 19:17:50 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 20:17:50 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51379146.4040106@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> Message-ID: <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> Hi, > Hi Uwe, > > You must have been reading my mind. See inline.... > > On 3/6/2013 10:50 AM, Uwe Schindler wrote: > > Hi John, > > > > Thanks for the response and the analysis, very informative! > > > >> Uwe: > >> Thanks for bringing this up and my apologies for not replying sooner. > >> I will have a fix fairly soon. If I'm correct about it being caused > >> by overflowing the marking stack you can work around the issue by > >> increasing the MarkStackSize.you could try increasing it to 2M or 4M > >> entries (which is the current max size). > > Is there a setting on the command line to raise this size? This would be > great to check out if one can also do the opposite (lower the size on 64 bit > JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I > am not so familiar with building the JVM on Ubuntu machines (including the > needed IcedTea), so it's hard to me to try this out - I would not even know > how to start doing this or finally how to get something like a standard JDK > directory so you could use it as JAVA_HOME. > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit run. I will give it a quick try! > > If you need a verification that your patch is working, it would be good to get > a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins > server that found the bug. Otherwise we would need to wait until a new > build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac > tool and the class library that we reported earlier). > > > > I could also assist in setting up a Lucene build directory (as > > reported on the first email), to reproduce the problem with the Lucene > > source code (which is very easy). As said before, I have no isolated > > test case :( > > > > I just sent you email. I downloaded a zip file that contains all the jar files. I > don't have ant on my system so ideally I'm looking for a java command line to > tickle the crash. Can you help? I responded. Unfortunately, the binary Lucene distribution does not contain the tests.... I will try to set something up and share via a download link from my dropbox. > Thanks, > > JohnC ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Wednesday, March 06, 2013 7:56 PM > To: Uwe Schindler > Cc: 'Thomas Schatzl'; hotspot-gc-dev at openjdk.java.net; 'David Holmes'; > 'Dawid Weiss'; hotspot-dev at openjdk.java.net > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > You must have been reading my mind. See inline.... > > On 3/6/2013 10:50 AM, Uwe Schindler wrote: > > Hi John, > > > > Thanks for the response and the analysis, very informative! > > > >> Uwe: > >> Thanks for bringing this up and my apologies for not replying sooner. > >> I will have a fix fairly soon. If I'm correct about it being caused > >> by overflowing the marking stack you can work around the issue by > >> increasing the MarkStackSize.you could try increasing it to 2M or 4M > >> entries (which is the current max size). > > Is there a setting on the command line to raise this size? This would be > great to check out if one can also do the opposite (lower the size on 64 bit > JVM to make the 64 bit one also hang). Unfortunately as a Java programmer I > am not so familiar with building the JVM on Ubuntu machines (including the > needed IcedTea), so it's hard to me to try this out - I would not even know > how to start doing this or finally how to get something like a standard JDK > directory so you could use it as JAVA_HOME. > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit run. > > > If you need a verification that your patch is working, it would be good to get > a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins > server that found the bug. Otherwise we would need to wait until a new > build appears on jdk8.java.net (including the fix + other fixes in javadoc/javac > tool and the class library that we reported earlier). > > > > I could also assist in setting up a Lucene build directory (as > > reported on the first email), to reproduce the problem with the Lucene > > source code (which is very easy). As said before, I have no isolated > > test case :( > > > > I just sent you email. I downloaded a zip file that contains all the jar files. I > don't have ant on my system so ideally I'm looking for a java command line to > tickle the crash. Can you help? > > Thanks, > > JohnC From john.cuthbertson at oracle.com Wed Mar 6 19:20:35 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 11:20:35 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> Message-ID: <51379703.5080203@oracle.com> Hi Uwe, Let me try with your detailed instructions below before you go to all of that trouble. I will let you know how I get on. Thanks, JohnC On 3/6/2013 11:15 AM, Uwe Schindler wrote: > Hi, > > That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). > If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. > > If you want to do it quicker (should be quite fast to do): > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8): http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... > - put the ANT bin/ dir into your PATH > - download the Apache Lucene source code from Jenkins: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) > - change to the module that fails: # cd analysis/uima > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). > > I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > >> -----Original Message----- >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] >> Sent: Wednesday, March 06, 2013 7:51 PM >> To: Uwe Schindler >> Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; >> dev at lucene.apache.org >> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) >> >> Hi Uwe, >> >> I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from >> https://builds.apache.org/job/Lucene-Artifacts- >> trunk/2212/artifact/lucene/dist/ >> >> I don't have ant on my workstation so do you have a java command line to >> run the test(s) that generate the error? >> >> Thanks, >> >> JohnC >> >> On 3/6/2013 3:16 AM, Uwe Schindler wrote: >>> Hi, >>> >>>> I think this is a VM bug and the thread dumps that Uwe produced are >>>> enough to start tracking down the root cause. >>> I hope it is enough! If I can help with more details, tell me what I should do >> to track this down. Unfortunately, we have no isolated test case (like a small >> java class that triggers this bug) - you have to run the test cases of this >> Lucene's module. It only happens there, not in any other Lucene test suite. It >> may be caused by a lot of GC activity in this "UIMA" module or a specific test. >>>> On 3/6/13 8:52 AM, David Holmes wrote: >>>>> If the VM is completely unresponsive then it suggests we are at a >>>>> safepoint. >>>> Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. >>>> >>>>> The GC threads are not "hung" in os::parK, they are parked - waiting >>>>> to be notified of something. >>>> It looks like the reference processing thread is stuck in a loop >>>> where it does wait(). So, the VM is hanging even if that stack trace >>>> also ends up in os::park(). >>>> >>>>> The thing is to find out why they are not being woken up. >>>> Actually, in this case we should probably not even be calling wait... >>>> >>>>> Can the gdb log be posted somewhere? I don't know if the attachment >>>>> made it to the original posting on hotspot-gc but it's no longer >>>>> available on hotspot-dev. >>>> I received the attachment with the original email. I've attached it >>>> to the bug report that I created: 8009536. You can find it there if >>>> you want to. But I think we have a fairly good idea of what change >>>> caused the hang. >>> If it helps: Unfortunately, we had some problems with recent JDK builds, >> because javac and javadoc tools were not working correctly, failing to build >> our source code. Since b78 this was fixed. Until this was fixed, we used build >> b65 (which was the last one working) and the G1GC hangs did not appear on >> this version. So it must have happened by a change after b65 till b78. >>> Uwe >>> >>>> Bengt >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/03/2013 4:07 PM, Krystal Mok wrote: >>>>>> Hi Uwe, >>>>>> >>>>>> If you can attach gdb onto it, and jstack -m and jstack -F should >>>>>> also work; that'll get you the Java stack trace. >>>>>> (But it probably doesn't matter in this case, because the hang is >>>>>> probably bug in the VM). >>>>>> >>>>>> - Kris >>>>>> >>>>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >>>> >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> since a few month we are extensively testing various preview >>>>>>> builds of JDK 8 for compatibility with Apache Lucene and Solr, so >>>>>>> we can find any bugs early and prevent the problems we had with >>>>>>> the release of Java 7 two years ago. Currently we have a Linux >>>>>>> (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK >>>>>>> 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a >>>>>>> different one with different hotspot and garbage collector >>>>>>> settings on every run of the test suite (which takes approx. 30-45 >> minutes). >>>>>>> JDK 8 b79 works so far very well on Linux, we found some strange >>>>>>> behavior in early versions (maybe compiler errors), but no longer >>>>>>> at the moment. There is one configuration that constantly and >>>>>>> reproducibly hangs in one module that is tested: The configuration >>>>>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client >>>>>>> does not matter). The JVM running the tests hangs irresponsible >>>>>>> (jstack or kill -3 have no effect/cannot connect, standard kill >>>>>>> does not stop it, only kill -9 actually kills it). It can be >>>>>>> reproduced in this Lucene module 100% (it hangs always). >>>>>>> >>>>>>> I was able to connect with GDB to the JVM and get a stack trace on >>>>>>> all threads (see attachment, dump.txt). As you see all threads of >>>>>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in >>>>>>> pthread library). Unfortunately that?s all I can give you. A Java >>>>>>> stacktrace is not possible because the JVM reacts on neither kill >>>>>>> -3 nor jstack. With all other garbage collectors it passes the >>>>>>> test without hangs in a few seconds, with 32 bit G1GC it can stand >>>>>>> still for hours. The 64 bit JVM passes with G1GC, so only the 32 >>>>>>> bit variant is affected. Client or Server VM makes no difference. >>>>>>> >>>>>>> To reproduce: >>>>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this >>>>>>> should not matter) >>>>>>> - Download Lucene Source code (e.g. the snapshot version we were >>>>>>> testing with: >>>>>>> https://builds.apache.org/job/Lucene-Artifacts- >>>> trunk/2212/artifact/lucene/dist/) >>>>>>> - change to directory lucene/analysis/uima and run: >>>>>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>>>>>> -Dtests.jvms=1 test >>>>>>> After a while the test framework prints "stalled" messages >>>>>>> (because the child VM actually running the test no longer >>>>>>> responds). The PID is also printed. Try to get a stack trace or kill it, no >> response. >>>>>>> Only kill -9 helps. Choosing another garbage collector in the >>>>>>> above command line makes the test finish after a few seconds, e.g. >>>>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" >>>>>>> >>>>>>> I posted this bug report directly to the mailing list, because >>>>>>> with earlier bug reports, there seem to be a problem with >>>>>>> bugs.sun.com - there is no response from any reviewer after >>>>>>> several weeks and we were able to help to find and fix javadoc and >>>>>>> javac-compiler bugs early. So I hope you can help for this bug, too. >>>>>>> >>>>>>> Uwe >>>>>>> >>>>>>> ----- >>>>>>> Uwe Schindler >>>>>>> uschindler at apache.org >>>>>>> Apache Lucene PMC Member / Committer Bremen, Germany >>>>>>> http://lucene.apache.org/ >>>>>>> >>>>>>> From uschindler at apache.org Wed Mar 6 19:31:56 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 20:31:56 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> Message-ID: <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> Hi, > > >> Uwe: > > >> Thanks for bringing this up and my apologies for not replying sooner. > > >> I will have a fix fairly soon. If I'm correct about it being caused > > >> by overflowing the marking stack you can work around the issue by > > >> increasing the MarkStackSize.you could try increasing it to 2M or > > >> 4M entries (which is the current max size). > > > Is there a setting on the command line to raise this size? This > > > would be > > great to check out if one can also do the opposite (lower the size on > > 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java > > programmer I am not so familiar with building the JVM on Ubuntu > > machines (including the needed IcedTea), so it's hard to me to try > > this out - I would not even know how to start doing this or finally > > how to get something like a standard JDK directory so you could use it as > JAVA_HOME. > > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit > run. > > I will give it a quick try! 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. With that setting the tests went through as they should (in 22 secs on this server). With the default setting it stalled endless. To test the inverse (make 64 bit hang): What's the default stack size of 32 bit JVMs, so I can set it on 64 bit to make it hang? Uwe > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > -----Original Message----- > > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > > Sent: Wednesday, March 06, 2013 7:56 PM > > To: Uwe Schindler > > Cc: 'Thomas Schatzl'; hotspot-gc-dev at openjdk.java.net; 'David Holmes'; > > 'Dawid Weiss'; hotspot-dev at openjdk.java.net > > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 > bit) > > > > Hi Uwe, > > > > You must have been reading my mind. See inline.... > > > > On 3/6/2013 10:50 AM, Uwe Schindler wrote: > > > Hi John, > > > > > > Thanks for the response and the analysis, very informative! > > > > > >> Uwe: > > >> Thanks for bringing this up and my apologies for not replying sooner. > > >> I will have a fix fairly soon. If I'm correct about it being caused > > >> by overflowing the marking stack you can work around the issue by > > >> increasing the MarkStackSize.you could try increasing it to 2M or 4M > > >> entries (which is the current max size). > > > Is there a setting on the command line to raise this size? This would be > > great to check out if one can also do the opposite (lower the size on 64 bit > > JVM to make the 64 bit one also hang). Unfortunately as a Java > programmer I > > am not so familiar with building the JVM on Ubuntu machines (including the > > needed IcedTea), so it's hard to me to try this out - I would not even know > > how to start doing this or finally how to get something like a standard JDK > > directory so you could use it as JAVA_HOME. > > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit > run. > > > > > If you need a verification that your patch is working, it would be good to > get > > a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins > > server that found the bug. Otherwise we would need to wait until a new > > build appears on jdk8.java.net (including the fix + other fixes in > javadoc/javac > > tool and the class library that we reported earlier). > > > > > > I could also assist in setting up a Lucene build directory (as > > > reported on the first email), to reproduce the problem with the Lucene > > > source code (which is very easy). As said before, I have no isolated > > > test case :( > > > > > > > I just sent you email. I downloaded a zip file that contains all the jar files. I > > don't have ant on my system so ideally I'm looking for a java command line > to > > tickle the crash. Can you help? > > > > Thanks, > > > > JohnC From uschindler at apache.org Wed Mar 6 19:38:27 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 20:38:27 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51379703.5080203@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <51379703.5080203@oracle.com> Message-ID: <007901ce1aa2$2ceac2d0$86c04870$@apache.org> Hi, If you want the command line of the JVM running the tests, there is one trick: Run the ANT test (the final step in my howto). When it hangs (you should see ANT printing some "tests stalled" messages on stdout, you go to a separate console and kill the worker JVM with kill -9 (the PID is printed by ANT before starting the tests). Once you killed the JVM, the ANT build should proceed and print debugging information about the "failed" JVM (the one you killed from the other terminal), including the full cmd line with full classpath. So it should be possible to spawn this in isolation using the printed command line. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Wednesday, March 06, 2013 8:21 PM > To: Uwe Schindler > Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > Let me try with your detailed instructions below before you go to all of that > trouble. I will let you know how I get on. > > Thanks, > > JohnC > > On 3/6/2013 11:15 AM, Uwe Schindler wrote: > > Hi, > > > > That's unfortunately not so easy, because of project dependencies. To run > the test you have to compile Lucene Core then the specific module + the test > framework (which is special for Lucene) and download some JARs from > Maven central (JAR hell, as usual). > > If you give me some time, I would collect all needed JAR files from my local > checkout and provide you the correct cmd line + a ZIP file with maybe a shell > script to startup. It should be doable, but needs some work to collect all > dependencies for the classpath. > > > > If you want to do it quicker (should be quite fast to do): > > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making > it not working out of the box with Java 8): > http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I > just wonder about the fact: isn't ANT needed to build the JDK classlib by > itself? I remember that the FreeBSD OpenJDK build downloads ANT and does > a large part of the compilation using ANT... > > - put the ANT bin/ dir into your PATH > > - download the Apache Lucene source code from Jenkins: > > https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/luc > > ene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this > > will download Apache IVY, so all dependencies can be downloaded from > > Maven Central) > > - change to the module that fails: # cd analysis/uima > > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test > > - In a parallel console you might be able to attach to the process, the build > in the main console using ANT runs inside ANT and the test framework > spawns separate worker instances of the JVM to execute the tests. This > makes it hard to reproduce in standalone (the command line passed to the > child JVM is veeeeery long). > > > > I will work on putting together a precompiled ZIP file with all needed JARs + > the command line. Just tell me if you got it managed with the above howto, > then I don?t need to do this. > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > > > >> -----Original Message----- > >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > >> Sent: Wednesday, March 06, 2013 7:51 PM > >> To: Uwe Schindler > >> Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > >> dev at lucene.apache.org > >> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 > >> bit) > >> > >> Hi Uwe, > >> > >> I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from > >> https://builds.apache.org/job/Lucene-Artifacts- > >> trunk/2212/artifact/lucene/dist/ > >> > >> I don't have ant on my workstation so do you have a java command line > >> to run the test(s) that generate the error? > >> > >> Thanks, > >> > >> JohnC > >> > >> On 3/6/2013 3:16 AM, Uwe Schindler wrote: > >>> Hi, > >>> > >>>> I think this is a VM bug and the thread dumps that Uwe produced are > >>>> enough to start tracking down the root cause. > >>> I hope it is enough! If I can help with more details, tell me what I > >>> should do > >> to track this down. Unfortunately, we have no isolated test case > >> (like a small java class that triggers this bug) - you have to run > >> the test cases of this Lucene's module. It only happens there, not in > >> any other Lucene test suite. It may be caused by a lot of GC activity in this > "UIMA" module or a specific test. > >>>> On 3/6/13 8:52 AM, David Holmes wrote: > >>>>> If the VM is completely unresponsive then it suggests we are at a > >>>>> safepoint. > >>>> Yes, we are hanging during a stop-the-world GC, so we are at a > safepoint. > >>>> > >>>>> The GC threads are not "hung" in os::parK, they are parked - > >>>>> waiting to be notified of something. > >>>> It looks like the reference processing thread is stuck in a loop > >>>> where it does wait(). So, the VM is hanging even if that stack > >>>> trace also ends up in os::park(). > >>>> > >>>>> The thing is to find out why they are not being woken up. > >>>> Actually, in this case we should probably not even be calling wait... > >>>> > >>>>> Can the gdb log be posted somewhere? I don't know if the > >>>>> attachment made it to the original posting on hotspot-gc but it's > >>>>> no longer available on hotspot-dev. > >>>> I received the attachment with the original email. I've attached it > >>>> to the bug report that I created: 8009536. You can find it there if > >>>> you want to. But I think we have a fairly good idea of what change > >>>> caused the hang. > >>> If it helps: Unfortunately, we had some problems with recent JDK > >>> builds, > >> because javac and javadoc tools were not working correctly, failing > >> to build our source code. Since b78 this was fixed. Until this was > >> fixed, we used build > >> b65 (which was the last one working) and the G1GC hangs did not > >> appear on this version. So it must have happened by a change after b65 till > b78. > >>> Uwe > >>> > >>>> Bengt > >>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 6/03/2013 4:07 PM, Krystal Mok wrote: > >>>>>> Hi Uwe, > >>>>>> > >>>>>> If you can attach gdb onto it, and jstack -m and jstack -F should > >>>>>> also work; that'll get you the Java stack trace. > >>>>>> (But it probably doesn't matter in this case, because the hang is > >>>>>> probably bug in the VM). > >>>>>> > >>>>>> - Kris > >>>>>> > >>>>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > >>>> > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> since a few month we are extensively testing various preview > >>>>>>> builds of JDK 8 for compatibility with Apache Lucene and Solr, > >>>>>>> so we can find any bugs early and prevent the problems we had > >>>>>>> with the release of Java 7 two years ago. Currently we have a > >>>>>>> Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK > >>>>>>> 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, > >>>>>>> choosing a different one with different hotspot and garbage > >>>>>>> collector settings on every run of the test suite (which takes > >>>>>>> approx. 30-45 > >> minutes). > >>>>>>> JDK 8 b79 works so far very well on Linux, we found some strange > >>>>>>> behavior in early versions (maybe compiler errors), but no > >>>>>>> longer at the moment. There is one configuration that constantly > >>>>>>> and reproducibly hangs in one module that is tested: The > >>>>>>> configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC > >>>>>>> (server or client does not matter). The JVM running the tests > >>>>>>> hangs irresponsible (jstack or kill -3 have no effect/cannot > >>>>>>> connect, standard kill does not stop it, only kill -9 actually > >>>>>>> kills it). It can be reproduced in this Lucene module 100% (it hangs > always). > >>>>>>> > >>>>>>> I was able to connect with GDB to the JVM and get a stack trace > >>>>>>> on all threads (see attachment, dump.txt). As you see all > >>>>>>> threads of G1GC seem to hang in a syscall (os:park(), a > >>>>>>> conditional wait in pthread library). Unfortunately that?s all I > >>>>>>> can give you. A Java stacktrace is not possible because the JVM > >>>>>>> reacts on neither kill > >>>>>>> -3 nor jstack. With all other garbage collectors it passes the > >>>>>>> test without hangs in a few seconds, with 32 bit G1GC it can > >>>>>>> stand still for hours. The 64 bit JVM passes with G1GC, so only > >>>>>>> the 32 bit variant is affected. Client or Server VM makes no > difference. > >>>>>>> > >>>>>>> To reproduce: > >>>>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but > >>>>>>> this should not matter) > >>>>>>> - Download Lucene Source code (e.g. the snapshot version we > were > >>>>>>> testing with: > >>>>>>> https://builds.apache.org/job/Lucene-Artifacts- > >>>> trunk/2212/artifact/lucene/dist/) > >>>>>>> - change to directory lucene/analysis/uima and run: > >>>>>>> ant -Dargs="-server -XX:+UseG1GC" > >>>>>>> -Dtests.multiplier=3 > >>>>>>> -Dtests.jvms=1 test > >>>>>>> After a while the test framework prints "stalled" messages > >>>>>>> (because the child VM actually running the test no longer > >>>>>>> responds). The PID is also printed. Try to get a stack trace or > >>>>>>> kill it, no > >> response. > >>>>>>> Only kill -9 helps. Choosing another garbage collector in the > >>>>>>> above command line makes the test finish after a few seconds, e.g. > >>>>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>>>>>> > >>>>>>> I posted this bug report directly to the mailing list, because > >>>>>>> with earlier bug reports, there seem to be a problem with > >>>>>>> bugs.sun.com - there is no response from any reviewer after > >>>>>>> several weeks and we were able to help to find and fix javadoc > >>>>>>> and javac-compiler bugs early. So I hope you can help for this bug, > too. > >>>>>>> > >>>>>>> Uwe > >>>>>>> > >>>>>>> ----- > >>>>>>> Uwe Schindler > >>>>>>> uschindler at apache.org > >>>>>>> Apache Lucene PMC Member / Committer Bremen, Germany > >>>>>>> http://lucene.apache.org/ > >>>>>>> > >>>>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org For additional > commands, e-mail: dev-help at lucene.apache.org From thomas.schatzl at oracle.com Wed Mar 6 19:44:27 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 20:44:27 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> Message-ID: <1362599067.2938.13.camel@cirrus> Hi, On Wed, 2013-03-06 at 20:31 +0100, Uwe Schindler wrote: > Hi, > > > >> Uwe: > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit > > run. > > > > I will give it a quick try! > > 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. With that setting the tests went through as they should (in 22 secs on this server). With the default setting it stalled endless. > Maybe you have to set -XX:MaxMarkStackSize as well, but it does not matter now I guess. > To test the inverse (make 64 bit hang): What's the default stack size of 32 bit JVMs, so I can set it on 64 bit to make it hang? > Use -XX:+PrintFlagsFinal on the 32 bit VM to get this value. The flag prints a list of all effective flag values after option processing. Hth, Thomas From thomas.schatzl at oracle.com Wed Mar 6 19:49:17 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 06 Mar 2013 20:49:17 +0100 Subject: RFR (M): 8008918: Reference statistics events for the tracing framework In-Reply-To: <5137779A.7040806@oracle.com> References: <5130B692.6070908@oracle.com> <1362385477.2590.9.camel@cirrus> <5137779A.7040806@oracle.com> Message-ID: <1362599357.2938.16.camel@cirrus> Hi, On Wed, 2013-03-06 at 18:06 +0100, Erik Helin wrote: > Hi Thomas, >[..] > If one refactor the code so that the ReferenceProcessor decides if the > reference processing should run in parallel, then one has to ensure that > the collector specific logic in the different branches still are > correct. > > This is a cleanup that we definitely should do, but I would like to see > it done as a separate change to ease the reviewing. > Okay. > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > I.e. what the change basically did is to replace the call to > > process_discovered_reference by above sequence of three statements. > > I would say that the change made the code go from two to three lines. > Before the code looked like: > > if (rp->processig_is_mt()) { > rp->process... > } else { > rp->process... > } > gc_tracer->report_gc_reference_processing(rp->collect_statistics()); > > After the change, the code looks like: > > ReferenceProcessorStats stats; > if (rp->processig_is_mt()) { > stats = rp->process... > } else { > stats = rp->process... > } > gc_tracer->report_gc_reference_processing(stats); > > The only difference in terms of lines is the addition of the "stats" > variable. > > In my opinion, this is a motivated cost for providing a more robust way > to collect the statistics from the reference processor. What do you think? > Agree. Note that I'm not an Openjdk reviewer, so you must find an additional reviewer... Thomas From john.cuthbertson at oracle.com Wed Mar 6 20:02:36 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 12:02:36 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> Message-ID: <5137A0DC.5050209@oracle.com> Hi Uwe, The default mark stack size for 32 bit is 32K entries. So try -XX:MarkStackSize=32K. This might not overflow because the local marking task queues are larger in the 64 bit JVM so there will be less pressure on the global mark stack. Unfortunately the task queue size is a constant (actually a template constant either 16K for 32 bit and 128K for 64 bit). You might have to go lower. JohnC On 03/06/13 11:31, Uwe Schindler wrote: > Hi, > > >>>>> Uwe: >>>>> Thanks for bringing this up and my apologies for not replying sooner. >>>>> I will have a fix fairly soon. If I'm correct about it being caused >>>>> by overflowing the marking stack you can work around the issue by >>>>> increasing the MarkStackSize.you could try increasing it to 2M or >>>>> 4M entries (which is the current max size). >>>>> >>>> Is there a setting on the command line to raise this size? This >>>> would be >>>> >>> great to check out if one can also do the opposite (lower the size on >>> 64 bit JVM to make the 64 bit one also hang). Unfortunately as a Java >>> programmer I am not so familiar with building the JVM on Ubuntu >>> machines (including the needed IcedTea), so it's hard to me to try >>> this out - I would not even know how to start doing this or finally >>> how to get something like a standard JDK directory so you could use it as >>> >> JAVA_HOME. >> >>> Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit >>> >> run. >> >> I will give it a quick try! >> > > 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. With that setting the tests went through as they should (in 22 secs on this server). With the default setting it stalled endless. > > To test the inverse (make 64 bit hang): What's the default stack size of 32 bit JVMs, so I can set it on 64 bit to make it hang? > > Uwe > > >> ----- >> Uwe Schindler >> uschindler at apache.org >> Apache Lucene PMC Member / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >> >> >>> -----Original Message----- >>> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] >>> Sent: Wednesday, March 06, 2013 7:56 PM >>> To: Uwe Schindler >>> Cc: 'Thomas Schatzl'; hotspot-gc-dev at openjdk.java.net; 'David Holmes'; >>> 'Dawid Weiss'; hotspot-dev at openjdk.java.net >>> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 >>> >> bit) >> >>> Hi Uwe, >>> >>> You must have been reading my mind. See inline.... >>> >>> On 3/6/2013 10:50 AM, Uwe Schindler wrote: >>> >>>> Hi John, >>>> >>>> Thanks for the response and the analysis, very informative! >>>> >>>> >>>>> Uwe: >>>>> Thanks for bringing this up and my apologies for not replying sooner. >>>>> I will have a fix fairly soon. If I'm correct about it being caused >>>>> by overflowing the marking stack you can work around the issue by >>>>> increasing the MarkStackSize.you could try increasing it to 2M or 4M >>>>> entries (which is the current max size). >>>>> >>>> Is there a setting on the command line to raise this size? This would be >>>> >>> great to check out if one can also do the opposite (lower the size on 64 bit >>> JVM to make the 64 bit one also hang). Unfortunately as a Java >>> >> programmer I >> >>> am not so familiar with building the JVM on Ubuntu machines (including the >>> needed IcedTea), so it's hard to me to try this out - I would not even know >>> how to start doing this or finally how to get something like a standard JDK >>> directory so you could use it as JAVA_HOME. >>> >>> Use: -XX:MarkStackSize=4M to increase the marking stack size in a 32 bit >>> >> run. >> >>>> If you need a verification that your patch is working, it would be good to >>>> >> get >> >>> a i586 Linux tgz file with a binary, so I can do a quick check on the Jenkins >>> server that found the bug. Otherwise we would need to wait until a new >>> build appears on jdk8.java.net (including the fix + other fixes in >>> >> javadoc/javac >> >>> tool and the class library that we reported earlier). >>> >>>> I could also assist in setting up a Lucene build directory (as >>>> reported on the first email), to reproduce the problem with the Lucene >>>> source code (which is very easy). As said before, I have no isolated >>>> test case :( >>>> >>>> >>> I just sent you email. I downloaded a zip file that contains all the jar files. I >>> don't have ant on my system so ideally I'm looking for a java command line >>> >> to >> >>> tickle the crash. Can you help? >>> >>> Thanks, >>> >>> JohnC >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uschindler at apache.org Wed Mar 6 20:10:34 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 21:10:34 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <1362599067.2938.13.camel@cirrus> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <513731B1.1090708@oracle.com> <00ae01ce1a68$fe0cb650$fa2622f0$@apache.org> <1362577384.2599.32.camel@cirrus> <51378520.6060908@oracle.com> <006201ce1a9b$7ccb14a0$76613de0$@apache.org> <51379146.4040106@oracle.com> <006e01ce1a9f$4b4d6a50$e1e83ef0$@apache.org> <007801ce1aa1$43cedb90$cb6c92b0$@apache.org> <1362599067.2938.13.camel@cirrus> Message-ID: <007e01ce1aa6$a93fd830$fbbf8890$@apache.org> > Hi, > > On Wed, 2013-03-06 at 20:31 +0100, Uwe Schindler wrote: > > Hi, > > > > >> Uwe: > > > > Use: -XX:MarkStackSize=4M to increase the marking stack size in a > > > > 32 bit > > > run. > > > > > > I will give it a quick try! > > > > 4M was too much for a 32bit JVM (it complained about it), but 2M was fine. > With that setting the tests went through as they should (in 22 secs on this > server). With the default setting it stalled endless. > > > > Maybe you have to set -XX:MaxMarkStackSize as well, but it does not matter > now I guess. > > > To test the inverse (make 64 bit hang): What's the default stack size of 32 > bit JVMs, so I can set it on 64 bit to make it hang? > > > > Use -XX:+PrintFlagsFinal on the 32 bit VM to get this value. The flag prints a > list of all effective flag values after option processing. Thanks. Unfortunately I did not get the 64 bit JVM to hang, not even with 1K stack size. It could be because Lucene or the used UIMA library in this test uses other defaults and behaves different GC-wise, or - as John mentioned - the task queue size is different. I was able to check some values in 32bit: with the default stack size of 32K it hangs, with 64K the same, 92K also hangs. But 128K passes and works with this test. Uwe From uschindler at apache.org Wed Mar 6 20:16:56 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 6 Mar 2013 21:16:56 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <51379703.5080203@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <51379703.5080203@oracle.com> Message-ID: <008201ce1aa7$8ceb6220$a6c22660$@apache.org> Hi again, If you don't get it running, I can do the following: I may set it up in /tmp locally. Then build and test the whole Lucene library including test. I could then TAR it up (might be large approx. 100 MB) and send it to you via dropbox or any other HTTP download. The command line of the JVM uses absolute paths for all JARs and other settings, but if you unpack the whole thing to /tmp, you could reuse the cmd line. Just tell me, if you were able to set it up, otherwise I can quickly TAR you the whole compiled directory and give you the command line from debugging output. If you unpack to another directory you might need to edit the command line with its absolute paths (which are generated by ANT). Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > Sent: Wednesday, March 06, 2013 8:21 PM > To: Uwe Schindler > Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > Hi Uwe, > > Let me try with your detailed instructions below before you go to all of that > trouble. I will let you know how I get on. > > Thanks, > > JohnC > > On 3/6/2013 11:15 AM, Uwe Schindler wrote: > > Hi, > > > > That's unfortunately not so easy, because of project dependencies. To run > the test you have to compile Lucene Core then the specific module + the test > framework (which is special for Lucene) and download some JARs from > Maven central (JAR hell, as usual). > > If you give me some time, I would collect all needed JAR files from my local > checkout and provide you the correct cmd line + a ZIP file with maybe a shell > script to startup. It should be doable, but needs some work to collect all > dependencies for the classpath. > > > > If you want to do it quicker (should be quite fast to do): > > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making > it not working out of the box with Java 8): > http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I > just wonder about the fact: isn't ANT needed to build the JDK classlib by > itself? I remember that the FreeBSD OpenJDK build downloads ANT and does > a large part of the compilation using ANT... > > - put the ANT bin/ dir into your PATH > > - download the Apache Lucene source code from Jenkins: > > https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/luc > > ene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this > > will download Apache IVY, so all dependencies can be downloaded from > > Maven Central) > > - change to the module that fails: # cd analysis/uima > > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test > > - In a parallel console you might be able to attach to the process, the build > in the main console using ANT runs inside ANT and the test framework > spawns separate worker instances of the JVM to execute the tests. This > makes it hard to reproduce in standalone (the command line passed to the > child JVM is veeeeery long). > > > > I will work on putting together a precompiled ZIP file with all needed JARs + > the command line. Just tell me if you got it managed with the above howto, > then I don?t need to do this. > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > > > >> -----Original Message----- > >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > >> Sent: Wednesday, March 06, 2013 7:51 PM > >> To: Uwe Schindler > >> Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > >> dev at lucene.apache.org > >> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 > >> bit) > >> > >> Hi Uwe, > >> > >> I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from > >> https://builds.apache.org/job/Lucene-Artifacts- > >> trunk/2212/artifact/lucene/dist/ > >> > >> I don't have ant on my workstation so do you have a java command line > >> to run the test(s) that generate the error? > >> > >> Thanks, > >> > >> JohnC > >> > >> On 3/6/2013 3:16 AM, Uwe Schindler wrote: > >>> Hi, > >>> > >>>> I think this is a VM bug and the thread dumps that Uwe produced are > >>>> enough to start tracking down the root cause. > >>> I hope it is enough! If I can help with more details, tell me what I > >>> should do > >> to track this down. Unfortunately, we have no isolated test case > >> (like a small java class that triggers this bug) - you have to run > >> the test cases of this Lucene's module. It only happens there, not in > >> any other Lucene test suite. It may be caused by a lot of GC activity in this > "UIMA" module or a specific test. > >>>> On 3/6/13 8:52 AM, David Holmes wrote: > >>>>> If the VM is completely unresponsive then it suggests we are at a > >>>>> safepoint. > >>>> Yes, we are hanging during a stop-the-world GC, so we are at a > safepoint. > >>>> > >>>>> The GC threads are not "hung" in os::parK, they are parked - > >>>>> waiting to be notified of something. > >>>> It looks like the reference processing thread is stuck in a loop > >>>> where it does wait(). So, the VM is hanging even if that stack > >>>> trace also ends up in os::park(). > >>>> > >>>>> The thing is to find out why they are not being woken up. > >>>> Actually, in this case we should probably not even be calling wait... > >>>> > >>>>> Can the gdb log be posted somewhere? I don't know if the > >>>>> attachment made it to the original posting on hotspot-gc but it's > >>>>> no longer available on hotspot-dev. > >>>> I received the attachment with the original email. I've attached it > >>>> to the bug report that I created: 8009536. You can find it there if > >>>> you want to. But I think we have a fairly good idea of what change > >>>> caused the hang. > >>> If it helps: Unfortunately, we had some problems with recent JDK > >>> builds, > >> because javac and javadoc tools were not working correctly, failing > >> to build our source code. Since b78 this was fixed. Until this was > >> fixed, we used build > >> b65 (which was the last one working) and the G1GC hangs did not > >> appear on this version. So it must have happened by a change after b65 till > b78. > >>> Uwe > >>> > >>>> Bengt > >>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 6/03/2013 4:07 PM, Krystal Mok wrote: > >>>>>> Hi Uwe, > >>>>>> > >>>>>> If you can attach gdb onto it, and jstack -m and jstack -F should > >>>>>> also work; that'll get you the Java stack trace. > >>>>>> (But it probably doesn't matter in this case, because the hang is > >>>>>> probably bug in the VM). > >>>>>> > >>>>>> - Kris > >>>>>> > >>>>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > >>>> > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> since a few month we are extensively testing various preview > >>>>>>> builds of JDK 8 for compatibility with Apache Lucene and Solr, > >>>>>>> so we can find any bugs early and prevent the problems we had > >>>>>>> with the release of Java 7 two years ago. Currently we have a > >>>>>>> Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK > >>>>>>> 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, > >>>>>>> choosing a different one with different hotspot and garbage > >>>>>>> collector settings on every run of the test suite (which takes > >>>>>>> approx. 30-45 > >> minutes). > >>>>>>> JDK 8 b79 works so far very well on Linux, we found some strange > >>>>>>> behavior in early versions (maybe compiler errors), but no > >>>>>>> longer at the moment. There is one configuration that constantly > >>>>>>> and reproducibly hangs in one module that is tested: The > >>>>>>> configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC > >>>>>>> (server or client does not matter). The JVM running the tests > >>>>>>> hangs irresponsible (jstack or kill -3 have no effect/cannot > >>>>>>> connect, standard kill does not stop it, only kill -9 actually > >>>>>>> kills it). It can be reproduced in this Lucene module 100% (it hangs > always). > >>>>>>> > >>>>>>> I was able to connect with GDB to the JVM and get a stack trace > >>>>>>> on all threads (see attachment, dump.txt). As you see all > >>>>>>> threads of G1GC seem to hang in a syscall (os:park(), a > >>>>>>> conditional wait in pthread library). Unfortunately that?s all I > >>>>>>> can give you. A Java stacktrace is not possible because the JVM > >>>>>>> reacts on neither kill > >>>>>>> -3 nor jstack. With all other garbage collectors it passes the > >>>>>>> test without hangs in a few seconds, with 32 bit G1GC it can > >>>>>>> stand still for hours. The 64 bit JVM passes with G1GC, so only > >>>>>>> the 32 bit variant is affected. Client or Server VM makes no > difference. > >>>>>>> > >>>>>>> To reproduce: > >>>>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but > >>>>>>> this should not matter) > >>>>>>> - Download Lucene Source code (e.g. the snapshot version we > were > >>>>>>> testing with: > >>>>>>> https://builds.apache.org/job/Lucene-Artifacts- > >>>> trunk/2212/artifact/lucene/dist/) > >>>>>>> - change to directory lucene/analysis/uima and run: > >>>>>>> ant -Dargs="-server -XX:+UseG1GC" > >>>>>>> -Dtests.multiplier=3 > >>>>>>> -Dtests.jvms=1 test > >>>>>>> After a while the test framework prints "stalled" messages > >>>>>>> (because the child VM actually running the test no longer > >>>>>>> responds). The PID is also printed. Try to get a stack trace or > >>>>>>> kill it, no > >> response. > >>>>>>> Only kill -9 helps. Choosing another garbage collector in the > >>>>>>> above command line makes the test finish after a few seconds, e.g. > >>>>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" > >>>>>>> > >>>>>>> I posted this bug report directly to the mailing list, because > >>>>>>> with earlier bug reports, there seem to be a problem with > >>>>>>> bugs.sun.com - there is no response from any reviewer after > >>>>>>> several weeks and we were able to help to find and fix javadoc > >>>>>>> and javac-compiler bugs early. So I hope you can help for this bug, > too. > >>>>>>> > >>>>>>> Uwe > >>>>>>> > >>>>>>> ----- > >>>>>>> Uwe Schindler > >>>>>>> uschindler at apache.org > >>>>>>> Apache Lucene PMC Member / Committer Bremen, Germany > >>>>>>> http://lucene.apache.org/ > >>>>>>> > >>>>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org For additional > commands, e-mail: dev-help at lucene.apache.org From tao.mao at oracle.com Wed Mar 6 22:27:55 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 06 Mar 2013 14:27:55 -0800 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp Message-ID: <5137C2EB.9090907@oracle.com> 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp https://jbs.oracle.com/bugs/browse/JDK-7196080 webrev: http://cr.openjdk.java.net/~tamao/7196080/webrev.00/ changeset: 1. inequality doesn't transfer here. X >= align_down(X) X >= I altogether, cannot infer that align_down(X) >= I. Simple math! 2. It's reasonable to check an assertion "max_heap > = OldSize", following the comment above the insertions. From tao.mao at oracle.com Wed Mar 6 22:33:30 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 06 Mar 2013 14:33:30 -0800 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <5137C2EB.9090907@oracle.com> References: <5137C2EB.9090907@oracle.com> Message-ID: <5137C43A.2040709@oracle.com> 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp https://jbs.oracle.com/bugs/browse/JDK-7196080 webrev: http://cr.openjdk.java.net/~tamao/7196080/webrev.00/ changeset: 1. inequality doesn't transfer here. X >= align_down(X) X >= I altogether, cannot infer that align_down(X) >= I. Simple math! So, I have removed the original assertion "max_heap >= InitialHeapSize". 2. It's reasonable to check an extra assertion "max_heap > = OldSize", following the comment above the assertions. From john.cuthbertson at oracle.com Wed Mar 6 23:48:57 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 06 Mar 2013 15:48:57 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> Message-ID: <5137D5E9.7000807@oracle.com> Hi Uwe, An update: I have downloaded ant and the lucerne source. I attempted the ivy-bootstrap but it failed to download the ivy=2.3.0.jar file - even after setting: ANT_OPTS=-Dhttp.proxyHost=<...> -Dhttp.proxyPort=<...> So I manually downloaded and placed it into the ANT library and now get: > ivy-bootstrap1: > [mkdir] Skipping /home/jcuthber/.ant/lib because it already exists. > [echo] installing ivy 2.3.0 to /home/jcuthber/.ant/lib > [get] Getting: > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > [get] To: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [get] Error getting > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > to /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [available] Found: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > > ivy-bootstrap2: > Skipped because property 'ivy.bootstrap1.success' set. > > ivy-checksum: > > ivy-bootstrap: > > BUILD SUCCESSFUL > Total time: 3 minutes 46 seconds Presumably I have to build the lucerne source before executing the tests. That seemed to go OK. When I run the analysis/uima tests it seems to get hung up at the "resolve" target - even without specifying G1: > cairnapple{jcuthber}:408> cd analysis/uima/ > cairnapple{jcuthber}:409> ls -l > total 29 > -rw-r--r-- 1 jcuthber staff 1473 Dec 10 10:39 build.xml > -rw-rw-r-- 1 jcuthber staff 6895 Mar 6 15:20 hotspot.log > -rw-r--r-- 1 jcuthber staff 1316 Mar 30 2012 ivy.xml > drwxr-xr-x 2 jcuthber staff 2 Mar 5 07:42 lib/ > drwxr-xr-x 6 jcuthber staff 6 Mar 5 07:42 src/ > ivy-configure: > [ivy:configure] Loading > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivy.properties > [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: > http://ant.apache.org/ivy/ :: > [ivy:configure] jakarta commons httpclient not found: using jdk url > handling > [ivy:configure] :: loading settings :: file = > /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/ivy-settings.xml > [ivy:configure] no default ivy user dir defined: set to > /home/jcuthber/.ivy2 > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-public.xml > [ivy:configure] no default cache defined: set to > /home/jcuthber/.ivy2/cache > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-shared.xml > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-local.xml > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-main-chain.xml > [ivy:configure] settings loaded (289ms) > [ivy:configure] default cache: /home/jcuthber/.ivy2/cache > [ivy:configure] default resolver: default > [ivy:configure] -- 7 resolvers: > [ivy:configure] working-chinese-mirror [ibiblio] > [ivy:configure] main [chain] [shared, public] > [ivy:configure] local [file] > [ivy:configure] shared [file] > [ivy:configure] sonatype-releases [ibiblio] > [ivy:configure] public [ibiblio] > [ivy:configure] default [chain] [local, main, > sonatype-releases, working-chinese-mirror] > > resolve: > [ivy:retrieve] no resolved descriptor found: launching default resolve > Overriding previous definition of property "ivy.version" > [ivy:retrieve] using ivy parser to parse > file:/export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/analysis/uima/ivy.xml > [ivy:retrieve] :: resolving dependencies :: > org.apache.lucene#analyzers-uima;working at cairnapple > [ivy:retrieve] confs: [default] > [ivy:retrieve] validate = true > [ivy:retrieve] refresh = false > [ivy:retrieve] resolving dependencies for configuration 'default' > [ivy:retrieve] == resolving dependencies for > org.apache.lucene#analyzers-uima;working at cairnapple [default] > [ivy:retrieve] == resolving dependencies > org.apache.lucene#analyzers-uima;working at cairnapple->org.apache.uima#Tagger;2.3.1 > [default->*] > [ivy:retrieve] default: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] don't use cache for org.apache.uima#Tagger;2.3.1: > checkModified=true > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] local: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] main: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] shared: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] tried > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom and there it hangs - presumably trying to access http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom There must be something with our proxy settings that that won't allow this. JohnC On 03/06/13 11:15, Uwe Schindler wrote: > Hi, > > That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). > If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. > > If you want to do it quicker (should be quite fast to do): > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8): http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... > - put the ANT bin/ dir into your PATH > - download the Apache Lucene source code from Jenkins: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) > - change to the module that fails: # cd analysis/uima > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). > > I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > >> -----Original Message----- >> From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] >> Sent: Wednesday, March 06, 2013 7:51 PM >> To: Uwe Schindler >> Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; >> dev at lucene.apache.org >> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) >> >> Hi Uwe, >> >> I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from >> https://builds.apache.org/job/Lucene-Artifacts- >> trunk/2212/artifact/lucene/dist/ >> >> I don't have ant on my workstation so do you have a java command line to >> run the test(s) that generate the error? >> >> Thanks, >> >> JohnC >> >> On 3/6/2013 3:16 AM, Uwe Schindler wrote: >> >>> Hi, >>> >>> >>>> I think this is a VM bug and the thread dumps that Uwe produced are >>>> enough to start tracking down the root cause. >>>> >>> I hope it is enough! If I can help with more details, tell me what I should do >>> >> to track this down. Unfortunately, we have no isolated test case (like a small >> java class that triggers this bug) - you have to run the test cases of this >> Lucene's module. It only happens there, not in any other Lucene test suite. It >> may be caused by a lot of GC activity in this "UIMA" module or a specific test. >> >>>> On 3/6/13 8:52 AM, David Holmes wrote: >>>> >>>>> If the VM is completely unresponsive then it suggests we are at a >>>>> safepoint. >>>>> >>>> Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. >>>> >>>> >>>>> The GC threads are not "hung" in os::parK, they are parked - waiting >>>>> to be notified of something. >>>>> >>>> It looks like the reference processing thread is stuck in a loop >>>> where it does wait(). So, the VM is hanging even if that stack trace >>>> also ends up in os::park(). >>>> >>>> >>>>> The thing is to find out why they are not being woken up. >>>>> >>>> Actually, in this case we should probably not even be calling wait... >>>> >>>> >>>>> Can the gdb log be posted somewhere? I don't know if the attachment >>>>> made it to the original posting on hotspot-gc but it's no longer >>>>> available on hotspot-dev. >>>>> >>>> I received the attachment with the original email. I've attached it >>>> to the bug report that I created: 8009536. You can find it there if >>>> you want to. But I think we have a fairly good idea of what change >>>> caused the hang. >>>> >>> If it helps: Unfortunately, we had some problems with recent JDK builds, >>> >> because javac and javadoc tools were not working correctly, failing to build >> our source code. Since b78 this was fixed. Until this was fixed, we used build >> b65 (which was the last one working) and the G1GC hangs did not appear on >> this version. So it must have happened by a change after b65 till b78. >> >>> Uwe >>> >>> >>>> Bengt >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/03/2013 4:07 PM, Krystal Mok wrote: >>>>> >>>>>> Hi Uwe, >>>>>> >>>>>> If you can attach gdb onto it, and jstack -m and jstack -F should >>>>>> also work; that'll get you the Java stack trace. >>>>>> (But it probably doesn't matter in this case, because the hang is >>>>>> probably bug in the VM). >>>>>> >>>>>> - Kris >>>>>> >>>>>> On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler >>>>>> >>>> >>>> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> since a few month we are extensively testing various preview >>>>>>> builds of JDK 8 for compatibility with Apache Lucene and Solr, so >>>>>>> we can find any bugs early and prevent the problems we had with >>>>>>> the release of Java 7 two years ago. Currently we have a Linux >>>>>>> (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK >>>>>>> 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a >>>>>>> different one with different hotspot and garbage collector >>>>>>> settings on every run of the test suite (which takes approx. 30-45 >>>>>>> >> minutes). >> >>>>>>> JDK 8 b79 works so far very well on Linux, we found some strange >>>>>>> behavior in early versions (maybe compiler errors), but no longer >>>>>>> at the moment. There is one configuration that constantly and >>>>>>> reproducibly hangs in one module that is tested: The configuration >>>>>>> uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client >>>>>>> does not matter). The JVM running the tests hangs irresponsible >>>>>>> (jstack or kill -3 have no effect/cannot connect, standard kill >>>>>>> does not stop it, only kill -9 actually kills it). It can be >>>>>>> reproduced in this Lucene module 100% (it hangs always). >>>>>>> >>>>>>> I was able to connect with GDB to the JVM and get a stack trace on >>>>>>> all threads (see attachment, dump.txt). As you see all threads of >>>>>>> G1GC seem to hang in a syscall (os:park(), a conditional wait in >>>>>>> pthread library). Unfortunately that?s all I can give you. A Java >>>>>>> stacktrace is not possible because the JVM reacts on neither kill >>>>>>> -3 nor jstack. With all other garbage collectors it passes the >>>>>>> test without hangs in a few seconds, with 32 bit G1GC it can stand >>>>>>> still for hours. The 64 bit JVM passes with G1GC, so only the 32 >>>>>>> bit variant is affected. Client or Server VM makes no difference. >>>>>>> >>>>>>> To reproduce: >>>>>>> - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this >>>>>>> should not matter) >>>>>>> - Download Lucene Source code (e.g. the snapshot version we were >>>>>>> testing with: >>>>>>> https://builds.apache.org/job/Lucene-Artifacts- >>>>>>> >>>> trunk/2212/artifact/lucene/dist/) >>>> >>>>>>> - change to directory lucene/analysis/uima and run: >>>>>>> ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 >>>>>>> -Dtests.jvms=1 test >>>>>>> After a while the test framework prints "stalled" messages >>>>>>> (because the child VM actually running the test no longer >>>>>>> responds). The PID is also printed. Try to get a stack trace or kill it, no >>>>>>> >> response. >> >>>>>>> Only kill -9 helps. Choosing another garbage collector in the >>>>>>> above command line makes the test finish after a few seconds, e.g. >>>>>>> -Dargs="-server -XX:+UseConcMarkSweepGC" >>>>>>> >>>>>>> I posted this bug report directly to the mailing list, because >>>>>>> with earlier bug reports, there seem to be a problem with >>>>>>> bugs.sun.com - there is no response from any reviewer after >>>>>>> several weeks and we were able to help to find and fix javadoc and >>>>>>> javac-compiler bugs early. So I hope you can help for this bug, too. >>>>>>> >>>>>>> Uwe >>>>>>> >>>>>>> ----- >>>>>>> Uwe Schindler >>>>>>> uschindler at apache.org >>>>>>> Apache Lucene PMC Member / Committer Bremen, Germany >>>>>>> http://lucene.apache.org/ >>>>>>> >>>>>>> >>>>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uschindler at apache.org Thu Mar 7 06:44:01 2013 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 7 Mar 2013 07:44:01 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5137D5E9.7000807@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> Message-ID: <00f601ce1aff$27a76eb0$76f64c10$@apache.org> Hi John, I only have time to work on a setup this evening Germen time, because I am on a business trip today. Will come back to you. Unfortunately I failed to quickly setup an easy classpath without Ivy downloading the JARS. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] Sent: Thursday, March 07, 2013 12:49 AM To: Uwe Schindler Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; dev at lucene.apache.org Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Hi Uwe, An update: I have downloaded ant and the lucerne source. I attempted the ivy-bootstrap but it failed to download the ivy=2.3.0.jar file - even after setting: ANT_OPTS=-Dhttp.proxyHost=<...> -Dhttp.proxyPort=<...> So I manually downloaded and placed it into the ANT library and now get: ivy-bootstrap1: [mkdir] Skipping /home/jcuthber/.ant/lib because it already exists. [echo] installing ivy 2.3.0 to /home/jcuthber/.ant/lib [get] Getting: http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar [get] To: /home/jcuthber/.ant/lib/ivy-2.3.0.jar [get] Error getting http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar to /home/jcuthber/.ant/lib/ivy-2.3.0.jar [available] Found: /home/jcuthber/.ant/lib/ivy-2.3.0.jar ivy-bootstrap2: Skipped because property 'ivy.bootstrap1.success' set. ivy-checksum: ivy-bootstrap: BUILD SUCCESSFUL Total time: 3 minutes 46 seconds Presumably I have to build the lucerne source before executing the tests. That seemed to go OK. When I run the analysis/uima tests it seems to get hung up at the "resolve" target - even without specifying G1: cairnapple{jcuthber}:408> cd analysis/uima/ cairnapple{jcuthber}:409> ls -l total 29 -rw-r--r-- 1 jcuthber staff 1473 Dec 10 10:39 build.xml -rw-rw-r-- 1 jcuthber staff 6895 Mar 6 15:20 hotspot.log -rw-r--r-- 1 jcuthber staff 1316 Mar 30 2012 ivy.xml drwxr-xr-x 2 jcuthber staff 2 Mar 5 07:42 lib/ drwxr-xr-x 6 jcuthber staff 6 Mar 5 07:42 src/ ivy-configure: [ivy:configure] Loading jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivy.properties [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: http://ant.apache.org/ivy/ :: [ivy:configure] jakarta commons httpclient not found: using jdk url handling [ivy:configure] :: loading settings :: file = /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/ivy-settings.xml [ivy:configure] no default ivy user dir defined: set to /home/jcuthber/.ivy2 [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-public.xml [ivy:configure] no default cache defined: set to /home/jcuthber/.ivy2/cache [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-shared.xml [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-local.xml [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-main-chain.xml [ivy:configure] settings loaded (289ms) [ivy:configure] default cache: /home/jcuthber/.ivy2/cache [ivy:configure] default resolver: default [ivy:configure] -- 7 resolvers: [ivy:configure] working-chinese-mirror [ibiblio] [ivy:configure] main [chain] [shared, public] [ivy:configure] local [file] [ivy:configure] shared [file] [ivy:configure] sonatype-releases [ibiblio] [ivy:configure] public [ibiblio] [ivy:configure] default [chain] [local, main, sonatype-releases, working-chinese-mirror] resolve: [ivy:retrieve] no resolved descriptor found: launching default resolve Overriding previous definition of property "ivy.version" [ivy:retrieve] using ivy parser to parse file:/export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/analysis/uima/ivy.xml [ivy:retrieve] :: resolving dependencies :: org.apache.lucene#analyzers-uima;working at cairnapple [ivy:retrieve] confs: [default] [ivy:retrieve] validate = true [ivy:retrieve] refresh = false [ivy:retrieve] resolving dependencies for configuration 'default' [ivy:retrieve] == resolving dependencies for org.apache.lucene#analyzers-uima;working at cairnapple [default] [ivy:retrieve] == resolving dependencies org.apache.lucene#analyzers-uima;working at cairnapple->org.apache.uima#Tagger;2.3.1 [default->*] [ivy:retrieve] default: Checking cache for: dependency: org.apache.uima#Tagger;2.3.1 {*=[*]} [ivy:retrieve] don't use cache for org.apache.uima#Tagger;2.3.1: checkModified=true [ivy:retrieve] tried /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml [ivy:retrieve] tried /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar [ivy:retrieve] local: no ivy file nor artifact found for org.apache.uima#Tagger;2.3.1 [ivy:retrieve] main: Checking cache for: dependency: org.apache.uima#Tagger;2.3.1 {*=[*]} [ivy:retrieve] tried /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml [ivy:retrieve] tried /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar [ivy:retrieve] shared: no ivy file nor artifact found for org.apache.uima#Tagger;2.3.1 [ivy:retrieve] tried http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom and there it hangs - presumably trying to access http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom There must be something with our proxy settings that that won't allow this. JohnC On 03/06/13 11:15, Uwe Schindler wrote: Hi, That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. If you want to do it quicker (should be quite fast to do): - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8): http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... - put the ANT bin/ dir into your PATH - download the Apache Lucene source code from Jenkins: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) - change to the module that fails: # cd analysis/uima - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -----Original Message----- From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] Sent: Wednesday, March 06, 2013 7:51 PM To: Uwe Schindler Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; dev at lucene.apache.org Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Hi Uwe, I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from https://builds.apache.org/job/Lucene-Artifacts- trunk/2212/artifact/lucene/dist/ I don't have ant on my workstation so do you have a java command line to run the test(s) that generate the error? Thanks, JohnC On 3/6/2013 3:16 AM, Uwe Schindler wrote: Hi, I think this is a VM bug and the thread dumps that Uwe produced are enough to start tracking down the root cause. I hope it is enough! If I can help with more details, tell me what I should do to track this down. Unfortunately, we have no isolated test case (like a small java class that triggers this bug) - you have to run the test cases of this Lucene's module. It only happens there, not in any other Lucene test suite. It may be caused by a lot of GC activity in this "UIMA" module or a specific test. On 3/6/13 8:52 AM, David Holmes wrote: If the VM is completely unresponsive then it suggests we are at a safepoint. Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. The GC threads are not "hung" in os::parK, they are parked - waiting to be notified of something. It looks like the reference processing thread is stuck in a loop where it does wait(). So, the VM is hanging even if that stack trace also ends up in os::park(). The thing is to find out why they are not being woken up. Actually, in this case we should probably not even be calling wait... Can the gdb log be posted somewhere? I don't know if the attachment made it to the original posting on hotspot-gc but it's no longer available on hotspot-dev. I received the attachment with the original email. I've attached it to the bug report that I created: 8009536. You can find it there if you want to. But I think we have a fairly good idea of what change caused the hang. If it helps: Unfortunately, we had some problems with recent JDK builds, because javac and javadoc tools were not working correctly, failing to build our source code. Since b78 this was fixed. Until this was fixed, we used build b65 (which was the last one working) and the G1GC hangs did not appear on this version. So it must have happened by a change after b65 till b78. Uwe Bengt Thanks, David On 6/03/2013 4:07 PM, Krystal Mok wrote: Hi Uwe, If you can attach gdb onto it, and jstack -m and jstack -F should also work; that'll get you the Java stack trace. (But it probably doesn't matter in this case, because the hang is probably bug in the VM). - Kris On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler wrote: Hi, since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. To reproduce: - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts- trunk/2212/artifact/lucene/dist/) - change to directory lucene/analysis/uima and run: ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Thu Mar 7 06:56:41 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 07 Mar 2013 07:56:41 +0100 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed In-Reply-To: <513777ED.6030209@oracle.com> References: <1362571695.2599.23.camel@cirrus> <513777ED.6030209@oracle.com> Message-ID: <1362639401.2659.3.camel@cirrus> Hi, new webrev at Webrev: http://cr.openjdk.java.net/~tschatzl/8008684/webrev.1/ Passes jprt. Note that tty->stamp(bool) automatically adds the colons, so I removed them from the string. Hth, Thomas On Wed, 2013-03-06 at 09:07 -0800, Jon Masamitsu wrote: > Thomas, > > I've added a comment to the bug report to clarify what > I think should be changed. Sorry that my original description > was lacking. Please take a look and let me know if it is > still not clear. > > Jon > > On 3/6/2013 4:08 AM, Thomas Schatzl wrote: > > Hi all, > > > > this change always adds a timestamp marker for CMS concurrent phase > > messages as suggested by the CR. > > I added an extra space between timestamp and the original message for > > better readability. > > > > I.e. instead of printing > > > > [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 sys=0.00, > > real=0.09 secs] > > [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 sys=0.00, > > real=0.00 secs] > > > > the VM now prints > > > > 20.014 [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 > > sys=0.00, real=0.09 secs] > > 20.019 [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 > > sys=0.00, real=0.00 secs] > > > > if -XX:+PrintGCDetails is set with CMS. > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8008684/webrev/ > > > > Bugs > > http://bugs.sun.com/view_bug.do?bug_id=8008684 > > > > JIRA: > > https://jbs.oracle.com/bugs/browse/JDK-8008684 > > > > Testing: > > JPRT > > > > Thanks, > > Thomas > > > From ysr1729 at gmail.com Thu Mar 7 07:42:23 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 6 Mar 2013 23:42:23 -0800 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: <51352BBB.4070809@oracle.com> References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> <5134E63E.9080504@oracle.com> <51352BBB.4070809@oracle.com> Message-ID: Thanks Jon. Please proceed as appropriate wrt the high-level comment in my review. If and when CMS policy wants to be different, I suppose this could be suitably revisited. thanks! - ramki On Mon, Mar 4, 2013 at 3:18 PM, Jon Masamitsu wrote: > Ramki, > > I think that originally CMSGen and TenuredGen shared > nearly the same policy but didn't share enough code. > > The existing CMS policy is > > 1) if the incremental collection failed, expand to reserved space. > > else > > 2) use MinHeapFreeRatio to decide if generation > should be expanded and by how much > > else > > 3) don't know how to shrink so don't > > I think that the CardGeneration::compute_new_size() > (formerly the TenuredGeneration::compute_new_size()) > does the same as 2) and that for a full GC we > know how to shrink the generation and the > CardGeneration::compute_new_size() does that > when CMS does a full GC. > > So for the CMS compute_new_size(), keep 1) and > replace 2) and 3) with a call to CardGeneration::compute_new_size(). > > I'll go back and verify that the original > CMS compute_new_size() uses MinHeapFreeRatio > the same way as CardGeneration::compute_new_size() > does. If they are the same, I'll try to refactor it so > that they actually share more code. > > A user that wants more head room in the CMS generation would > have to specify a MinHeapFreeRatio and that value would > be used by CardGeneration::compute_new_size() with my > change just as it is used in the original CMS compute_new_size(). > > Jon > > > > On 03/04/13 11:02, Srinivas Ramakrishna wrote: >> >> KInd of.... What I am saying is that the sizing policy should be based >> on what CMS wants, not >> what CardGeneration might want. Besides how does card generation know >> what specific policy >> a concrete subclass would want. The policy should be determined by the >> "leaf class" (or suitably >> over-ridden as needed) -- in this case by CMS. I see that you have >> here decided that the policy >> provided by CardGeneration is sufficient for when a concurrent mode >> failure happens. I was not sure >> if that would necessarily be the case, and perhaps more thought is >> needed to come up with >> a good _policy_ specific for CMS, and use the _mechanics_ provided by >> CardGeneration to >> affect that change. CMS _should_ distinguish between whether a >> concurrent mode failure occurred >> or not to determine how its heap should be sized, but it should >> probably be a policy that is >> cognizant of the historical metrics of CMS, which may or may not be >> used by or available >> to CardGeneration, and make decisions specific to CMS, which >> CardGeneration does not know about. >> >> May be I am splitting hairs here, but this is basically where >> mechanism, if common, might be >> provided by superclasses but policy by concrete subclasses (or >> suitably overridden when >> appropriate -- may be in this case you decided that when there is a >> compacting collection, >> the policy provided by the superclass is good enough; I was not sure >> if that was a deliberate >> decision -- I have not looked closely at either policy to see if it >> makes sense. Consider, for example, >> that CMS usually has larger free space needs than contiguous space >> collectors, so it makes >> sense to me that its sizing policies would be different and keep more >> free space available based >> on the application's historical behaviour, than would contiguously >> allocating collectors.) >> >> Does my concern make sense? >> >> -- ramki >> >> On Mon, Mar 4, 2013 at 10:21 AM, Jon Masamitsu >> wrote: >>> >>> Ramki, >>> >>> Thanks for taking a look. Let's talk about the high level >>> comment before the details. >>> >>> Are you saying that the amount of desired free space in the >>> cms generation after a collection should be independent of >>> whether the collection was a concurrent collection or a >>> full STW collection? >>> >>> Jon >>> >>> >>> >>> On 03/02/13 00:42, Srinivas Ramakrishna wrote: >>>> >>>> Hi Jon -- >>>> >>>> I'll give a couple of code-level comments, but there's a high-level >>>> comment at the end, which >>>> might be worth pondering over. >>>> >>>> On Tue, Feb 26, 2013 at 3:47 PM, Jon Masamitsu >>>> wrote: >>>>> >>>>> I've updated the webrev for review comments (thanks, JohnCu) >>>>> >>>>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ >>>>> >>>> concurrent MarkSweepGeneration.cpp: >>>> >>>> 949 // compute expansion delta needed for reaching desired free >>>> percentage >>>> 950 if (free_percentage< desired_free_percentage) { >>>> 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - >>>> desired_free_percentage)); >>>> 952 assert(desired_capacity>= capacity(), "invalid expansion >>>> size"); >>>> 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), >>>> MinHeapDeltaBytes); >>>> >>>> 954 if (expand_bytes> 0) { >>>> >>>> The if test at 954 (in your changed code) will always be true because >>>> MinHeapDeltaBytes> 0 >>>> and we are taking the max at line 953. >>>> >>>> On reading your shrinking code further below at lines 989-994, it >>>> struck me that there's a small >>>> existing bug in the shrink/expand code here. It's probably more of a >>>> factor in the shrink code though >>>> because we can live with more free space than we'd ideally want, but >>>> not less than we ideally want, >>>> and we certainly do not want to chatter around the desired free >>>> percentage (hence the delta). >>>> >>>> Your shrinking arm looks like this:- >>>> >>>> 989 } else { >>>> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >>>> desired_free_percentage)); >>>> 991 assert(desired_capacity<= capacity(), "invalid expansion >>>> size"); >>>> 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, >>>> MinHeapDeltaBytes); >>>> 993 shrink_free_list_by(shrink_bytes); >>>> 994 } >>>> >>>> I'd modify it to:- >>>> >>>> 989 } else { >>>> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >>>> desired_free_percentage)); >>>> 991 assert(desired_capacity<= capacity(), "invalid expansion >>>> size"); >>>> size_t shrink_bytes = capacity() - desired_capacity; >>>> // Don't shrink unless the delta is greater than the >>>> minimum shrink we want >>>> 992 if (shrink_bytes>= MinHeapDeltaBytes) { >>>> 993 shrink_free_list_by(shrink_bytes); >>>> } >>>> 994 } >>>> >>>> Note the asymmetry between expansion and shrinking, where we expand by >>>> the min if we feel we are below the desired free, but we don't shrink >>>> even if we are above desired free unless the gap exceeds the min >>>> delta. >>>> >>>> This seems to be the correct policy. (Of course none of that is moot >>>> until shrink_free_list_by() starts doing shrinking, but probably best >>>> to fix the policy now, so that it doesn't cause chatter later. >>>> >>>> concurrentMarkSweepGeneration.hpp: >>>> >>>> 1298 virtual void compute_new_size(); >>>> 1299 void compute_new_size_free_list(); >>>> >>>> I think it would be good to add a 1-line doc comment for each of the >>>> above methods. >>>> >>>> vmStructs.cpp: >>>> >>>> I think you also have to adjust the fields _capacity_at_prologue and >>>> _used_at_prologue into the superclass. I'd also move the decls up to >>>> CardGeneration, since that's how the original code is laid out. >>>> >>>> Finally, a high level comment. While I see the reason for these >>>> mechanics, I worry a little bit >>>> about the somewhat schizophrenic expansion/shrinkage policy, as it >>>> swings between one policy >>>> used when we are presumably doing well and keeping up with the >>>> application's >>>> allocation/promotion rates and not running into concurrent mode >>>> failure, but then suddenly switching >>>> to a completely different expansion/shrinking policy when we do a >>>> compaction (presumably because >>>> we had a concurrent mode failure). I'd much rather have divorced the >>>> two, by using a more uniform >>>> policy specifically for CMS, perhaps predicated by whether this was >>>> happening after a >>>> compaction or not, but keeping it separate from the policy that might >>>> be used for stop-world >>>> kind of collectors (hence TenuredGeneraion). >>>> >>>> I'd appreciate it if you could give some thought to this final high >>>> level comment regarding the >>>> general policy approach taken here. (Also it is somewhat troubling to >>>> push policy so high up >>>> into the class hierarchy, so that every subclass must live with it; >>>> I'd much rather the policy >>>> were separated from the mechanics of what would be done when an >>>> expansion or shrinkage >>>> was needed.) >>>> >>>> -- ramki From mikael.gerdin at oracle.com Thu Mar 7 08:54:36 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 07 Mar 2013 09:54:36 +0100 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Message-ID: <513855CC.5030009@oracle.com> Hi When deciding when to reserve more metaspace memory we erroneously looked only at the "capacity" of the metaspace insted of the reserved space (which is what we ask this function when expanding). Additionally, we didn't check MaxMetaspaceSize against the sum of reserved(Class) + reserved(NonClass) which caused us to use more than MaxMetaspaceSize even when it was set. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 (not yet available at the time of writing this mail) Webrev: http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 Testing: JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code path. From dawid.weiss at cs.put.poznan.pl Thu Mar 7 09:30:26 2013 From: dawid.weiss at cs.put.poznan.pl (Dawid Weiss) Date: Thu, 7 Mar 2013 10:30:26 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <00f601ce1aff$27a76eb0$76f64c10$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> <00f601ce1aff$27a76eb0$76f64c10$@apache.org> Message-ID: I think I can help. Fetch this (sorry for putting together the whole world -- space for time tradeoff): http://ophelia.cs.put.poznan.pl/~dweiss/download/_g1gc.tar.gz and unpack to, depending on which system you want to test on: if on windows: C:\_g1gc\ if on linux (32-bit!): /tmp/_g1gc/ At the top of the archive there is a repro.sh (or repro.cmd for windows) which reproduces the issue, JDK 1.8 included. I couldn't get it to hang on a 1-cpu linux (vmware). on windows it hangs for me all the time. Dawid On Thu, Mar 7, 2013 at 7:44 AM, Uwe Schindler wrote: > Hi John,**** > > ** ** > > I only have time to work on a setup this evening Germen time, because I am > on a business trip today. Will come back to you. Unfortunately I failed to > quickly setup an easy classpath without Ivy downloading the JARS. **** > > ** ** > > Uwe**** > > ** ** > > -----**** > > Uwe Schindler**** > > uschindler at apache.org **** > > Apache Lucene PMC Member / Committer**** > > Bremen, Germany**** > > http://lucene.apache.org/**** > > ** ** > > *From:* John Cuthbertson [mailto:john.cuthbertson at oracle.com] > *Sent:* Thursday, March 07, 2013 12:49 AM > > *To:* Uwe Schindler > *Cc:* 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > *Subject:* Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 > bit)**** > > ** ** > > Hi Uwe, > > An update: > > I have downloaded ant and the lucerne source. > > I attempted the ivy-bootstrap but it failed to download the ivy=2.3.0.jar > file - even after setting: > > ANT_OPTS=-Dhttp.proxyHost=<...> -Dhttp.proxyPort=<...> > > So I manually downloaded and placed it into the ANT library and now get: > > > **** > > ivy-bootstrap1: > [mkdir] Skipping /home/jcuthber/.ant/lib because it already exists. > [echo] installing ivy 2.3.0 to /home/jcuthber/.ant/lib > [get] Getting: > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > [get] To: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [get] Error getting > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar to > /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [available] Found: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > > ivy-bootstrap2: > Skipped because property 'ivy.bootstrap1.success' set. > > ivy-checksum: > > ivy-bootstrap: > > BUILD SUCCESSFUL > Total time: 3 minutes 46 seconds**** > > Presumably I have to build the lucerne source before executing the tests. > That seemed to go OK. > > When I run the analysis/uima tests it seems to get hung up at the > "resolve" target - even without specifying G1: > > > **** > > cairnapple{jcuthber}:408> cd analysis/uima/ > cairnapple{jcuthber}:409> ls -l > total 29 > -rw-r--r-- 1 jcuthber staff 1473 Dec 10 10:39 build.xml > -rw-rw-r-- 1 jcuthber staff 6895 Mar 6 15:20 hotspot.log > -rw-r--r-- 1 jcuthber staff 1316 Mar 30 2012 ivy.xml > drwxr-xr-x 2 jcuthber staff 2 Mar 5 07:42 lib/ > drwxr-xr-x 6 jcuthber staff 6 Mar 5 07:42 src/**** > > > > **** > > ivy-configure: > [ivy:configure] Loading > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivy.properties > [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: > http://ant.apache.org/ivy/ :: > [ivy:configure] jakarta commons httpclient not found: using jdk url > handling > [ivy:configure] :: loading settings :: file = > /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/ivy-settings.xml > [ivy:configure] no default ivy user dir defined: set to > /home/jcuthber/.ivy2 > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-public.xml > [ivy:configure] no default cache defined: set to /home/jcuthber/.ivy2/cache > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-shared.xml > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-local.xml > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-main-chain.xml > [ivy:configure] settings loaded (289ms) > [ivy:configure] default cache: /home/jcuthber/.ivy2/cache > [ivy:configure] default resolver: default > [ivy:configure] -- 7 resolvers: > [ivy:configure] working-chinese-mirror [ibiblio] > [ivy:configure] main [chain] [shared, public] > [ivy:configure] local [file] > [ivy:configure] shared [file] > [ivy:configure] sonatype-releases [ibiblio] > [ivy:configure] public [ibiblio] > [ivy:configure] default [chain] [local, main, sonatype-releases, > working-chinese-mirror] > > resolve: > [ivy:retrieve] no resolved descriptor found: launching default resolve > Overriding previous definition of property "ivy.version" > [ivy:retrieve] using ivy parser to parse > file:/export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/analysis/uima/ivy.xml > [ivy:retrieve] :: resolving dependencies :: > org.apache.lucene#analyzers-uima;working at cairnapple > [ivy:retrieve] confs: [default] > [ivy:retrieve] validate = true > [ivy:retrieve] refresh = false > [ivy:retrieve] resolving dependencies for configuration 'default' > [ivy:retrieve] == resolving dependencies for > org.apache.lucene#analyzers-uima;working at cairnapple [default] > [ivy:retrieve] == resolving dependencies > org.apache.lucene#analyzers-uima;working at cairnapple->org.apache.uima#Tagger;2.3.1 > [default->*] > [ivy:retrieve] default: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] don't use cache for org.apache.uima#Tagger;2.3.1: > checkModified=true > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] local: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] main: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] shared: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] tried > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom > **** > > and there it hangs - presumably trying to access > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom > > There must be something with our proxy settings that that won't allow this. > > JohnC > > > On 03/06/13 11:15, Uwe Schindler wrote: **** > > Hi,**** > > ** ** > > That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual).**** > > If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath.**** > > ** ** > > If you want to do it quicker (should be quite fast to do):**** > > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8): http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT...**** > > - put the ANT bin/ dir into your PATH**** > > - download the Apache Lucene source code from Jenkins: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz**** > > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central)**** > > - change to the module that fails: # cd analysis/uima**** > > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test**** > > - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long).**** > > ** ** > > I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this.**** > > Uwe**** > > ** ** > > -----**** > > Uwe Schindler**** > > uschindler at apache.org **** > > Apache Lucene PMC Member / Committer**** > > Bremen, Germany**** > > http://lucene.apache.org/**** > > ** ** > > ** ** > > **** > > -----Original Message-----**** > > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com ]**** > > Sent: Wednesday, March 06, 2013 7:51 PM**** > > To: Uwe Schindler**** > > Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net;**** > > dev at lucene.apache.org**** > > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit)**** > > ** ** > > Hi Uwe,**** > > ** ** > > I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from**** > > https://builds.apache.org/job/Lucene-Artifacts-**** > > trunk/2212/artifact/lucene/dist/**** > > ** ** > > I don't have ant on my workstation so do you have a java command line to**** > > run the test(s) that generate the error?**** > > ** ** > > Thanks,**** > > ** ** > > JohnC**** > > ** ** > > On 3/6/2013 3:16 AM, Uwe Schindler wrote:**** > > **** > > Hi,**** > > ** ** > > **** > > I think this is a VM bug and the thread dumps that Uwe produced are**** > > enough to start tracking down the root cause.**** > > **** > > I hope it is enough! If I can help with more details, tell me what I should do**** > > > **** > > to track this down. Unfortunately, we have no isolated test case (like a small**** > > java class that triggers this bug) - you have to run the test cases of this**** > > Lucene's module. It only happens there, not in any other Lucene test suite. It**** > > may be caused by a lot of GC activity in this "UIMA" module or a specific test.**** > > **** > > On 3/6/13 8:52 AM, David Holmes wrote:**** > > **** > > If the VM is completely unresponsive then it suggests we are at a**** > > safepoint.**** > > **** > > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint.**** > > ** ** > > **** > > The GC threads are not "hung" in os::parK, they are parked - waiting**** > > to be notified of something.**** > > **** > > It looks like the reference processing thread is stuck in a loop**** > > where it does wait(). So, the VM is hanging even if that stack trace**** > > also ends up in os::park().**** > > ** ** > > **** > > The thing is to find out why they are not being woken up.**** > > **** > > Actually, in this case we should probably not even be calling wait...**** > > ** ** > > **** > > Can the gdb log be posted somewhere? I don't know if the attachment**** > > made it to the original posting on hotspot-gc but it's no longer**** > > available on hotspot-dev.**** > > **** > > I received the attachment with the original email. I've attached it**** > > to the bug report that I created: 8009536. You can find it there if**** > > you want to. But I think we have a fairly good idea of what change**** > > caused the hang.**** > > **** > > If it helps: Unfortunately, we had some problems with recent JDK builds,**** > > **** > > because javac and javadoc tools were not working correctly, failing to build**** > > our source code. Since b78 this was fixed. Until this was fixed, we used build**** > > b65 (which was the last one working) and the G1GC hangs did not appear on**** > > this version. So it must have happened by a change after b65 till b78.**** > > **** > > Uwe**** > > ** ** > > **** > > Bengt**** > > ** ** > > **** > > Thanks,**** > > David**** > > ** ** > > On 6/03/2013 4:07 PM, Krystal Mok wrote:**** > > **** > > Hi Uwe,**** > > ** ** > > If you can attach gdb onto it, and jstack -m and jstack -F should**** > > also work; that'll get you the Java stack trace.**** > > (But it probably doesn't matter in this case, because the hang is**** > > probably bug in the VM).**** > > ** ** > > - Kris**** > > ** ** > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler**** > > **** > > **** > > **** > > wrote:**** > > **** > > Hi,**** > > ** ** > > since a few month we are extensively testing various preview**** > > builds of JDK 8 for compatibility with Apache Lucene and Solr, so**** > > we can find any bugs early and prevent the problems we had with**** > > the release of Java 7 two years ago. Currently we have a Linux**** > > (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK**** > > 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a**** > > different one with different hotspot and garbage collector**** > > settings on every run of the test suite (which takes approx. 30-45**** > > **** > > minutes).**** > > **** > > JDK 8 b79 works so far very well on Linux, we found some strange**** > > behavior in early versions (maybe compiler errors), but no longer**** > > at the moment. There is one configuration that constantly and**** > > reproducibly hangs in one module that is tested: The configuration**** > > uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client**** > > does not matter). The JVM running the tests hangs irresponsible**** > > (jstack or kill -3 have no effect/cannot connect, standard kill**** > > does not stop it, only kill -9 actually kills it). It can be**** > > reproduced in this Lucene module 100% (it hangs always).**** > > ** ** > > I was able to connect with GDB to the JVM and get a stack trace on**** > > all threads (see attachment, dump.txt). As you see all threads of**** > > G1GC seem to hang in a syscall (os:park(), a conditional wait in**** > > pthread library). Unfortunately that?s all I can give you. A Java**** > > stacktrace is not possible because the JVM reacts on neither kill**** > > -3 nor jstack. With all other garbage collectors it passes the**** > > test without hangs in a few seconds, with 32 bit G1GC it can stand**** > > still for hours. The 64 bit JVM passes with G1GC, so only the 32**** > > bit variant is affected. Client or Server VM makes no difference.**** > > ** ** > > To reproduce:**** > > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this**** > > should not matter)**** > > - Download Lucene Source code (e.g. the snapshot version we were**** > > testing with:**** > > https://builds.apache.org/job/Lucene-Artifacts-**** > > **** > > trunk/2212/artifact/lucene/dist/)**** > > **** > > - change to directory lucene/analysis/uima and run:**** > > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3**** > > -Dtests.jvms=1 test**** > > After a while the test framework prints "stalled" messages**** > > (because the child VM actually running the test no longer**** > > > responds). The PID is also printed. Try to get a stack trace or kill it, no**** > > **** > > response.**** > > **** > > Only kill -9 helps. Choosing another garbage collector in the**** > > above command line makes the test finish after a few seconds, e.g.**** > > -Dargs="-server -XX:+UseConcMarkSweepGC"**** > > ** ** > > I posted this bug report directly to the mailing list, because**** > > with earlier bug reports, there seem to be a problem with**** > > bugs.sun.com - there is no response from any reviewer after**** > > several weeks and we were able to help to find and fix javadoc and**** > > javac-compiler bugs early. So I hope you can help for this bug, too.**** > > ** ** > > Uwe**** > > ** ** > > -----**** > > Uwe Schindler**** > > uschindler at apache.org**** > > Apache Lucene PMC Member / Committer Bremen, Germany**** > > http://lucene.apache.org/**** > > ** ** > > ** ** > > **** > > ** ** > > **** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dawid.weiss at cs.put.poznan.pl Thu Mar 7 09:37:36 2013 From: dawid.weiss at cs.put.poznan.pl (Dawid Weiss) Date: Thu, 7 Mar 2013 10:37:36 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> <00f601ce1aff$27a76eb0$76f64c10$@apache.org> Message-ID: > At the top of the archive there is a repro.sh (or repro.cmd for windows) > which reproduces the issue, JDK 1.8 included. I couldn't get it to hang on > a 1-cpu linux (vmware). on windows it hangs for me all the time. > Update: hangs for me 100% under vmware/ubuntu if I bump the number of cpus to 2. So: cd /tmp wget http://ophelia.cs.put.poznan.pl/~dweiss/download/_g1gc.tar.gz tar -zxf _g1gc.tar.gz cd _g1gc ./repro.sh Dawid -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Mar 7 09:41:42 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 07 Mar 2013 10:41:42 +0100 Subject: RFR: JDK-8008790 - Promotion failed tracing event for all GCs In-Reply-To: <5137846E.30904@oracle.com> References: <512B5EB7.4050107@oracle.com> <512CDA9C.3050607@oracle.com> <51376920.3030704@oracle.com> <5137846E.30904@oracle.com> Message-ID: <513860D6.3020404@oracle.com> Jesper, Looks good to me to. Bengt On 3/6/13 7:01 PM, Erik Helin wrote: > Hi Jesper, > > looks good. > > Thanks, > Erik > > On 03/06/2013 05:04 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> Additional feedback resulted in a new webrev: >> >> http://cr.openjdk.java.net/~jwilhelm/8008790/webrev.hsx24.3/ >> >> Thanks, >> /Jesper >> >> >> On 26/2/13 4:54 PM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> After some internal feedback a new version of the webrev is >>> available at: >>> >>> http://cr.openjdk.java.net/~jwilhelm/8008790/webrev.hsx24.2/ >>> >>> The biggest change is that the promotion failed event now is sent once >>> per >>> thread instead of merging the info into one event. >>> >>> Thanks, >>> /Jesper >>> >>> >>> On 25/2/13 1:53 PM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> I'm looking for a couple of reviews for the promotion failed tracing >>>> event, now >>>> implemented for ParNew and Serial GC. >>>> >>>> I have replaced the existing counters and booleans with a >>>> PromotionFailedInfo >>>> object and uses that throughout, so now promotion failed reporting >>>> (through the >>>> tracing framework) looks the same and reports the same data for all >>>> young >>>> collectors. >>>> >>>> I have added two new fields to the promotion failed event: firstSize >>>> as reported >>>> by ParNew logging, and smallestSize which is the smallest object size >>>> that >>>> failed to promote. >>>> >>>> Webrew: http://cr.openjdk.java.net/~jwilhelm/8008790 >>>> >>>> Testing: Passes JPRT and the existing promotion failed tests with all >>>> collectors. >>>> >>>> Thanks, >>>> /Jesper > From bengt.rutisson at oracle.com Thu Mar 7 12:24:56 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 07 Mar 2013 13:24:56 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <00f601ce1aff$27a76eb0$76f64c10$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> <00f601ce1aff$27a76eb0$76f64c10$@apache.org> Message-ID: <51388718.8080704@oracle.com> John and Uwe, I followed the original instruction sent out by Uwe to reproduce the test. I got it up and running on my Windows x64 workstation using a 32 bit binary. The test hangs every time I run it. John, I think your proxy issues are due to the fact that ant picks up its proxy setting from Java. So you need to set the system properties http.proxyHost and http.proxyPort. I did this by exporting the the _JAVA_OPTIONS environment variable as: _JAVA_OPTIONS=-Dhttp.proxyHost= -Dhttp.proxyPort= Let me know if this does not work for you. We can try to debug it offline. Since I could catch the hang in a debugger I could confirm both that the hang is indeed related to the recent change to the DrainMarkingStackClosures and that the problem is that we enter the termination protocol even when reference processing is single threaded. Looking at the comment in the constructor for G1CMDrainMarkingStackClosure: // We only allow stealing and only enter the termination protocol // in CMTask::do_marking_step() if this closure is being instantiated // for parallel reference processing. _do_stealing = _do_termination = is_par; I came up with a patch that makes the test work again. But I leave it to you, John, to figure out if this is the right way to solve the problem. diff --git a/src/share/vm/gc_implementation/g1/concurrentMark.cpp b/src/share/vm/gc_implementation/g1/concurrentMark.cpp --- a/src/share/vm/gc_implementation/g1/concurrentMark.cpp +++ b/src/share/vm/gc_implementation/g1/concurrentMark.cpp @@ -4336,7 +4336,9 @@ gclog_or_tty->print_cr("[%u] detected overflow", _worker_id); } + if (do_stealing || do_termination) { _cm->enter_first_sync_barrier(_worker_id); + } // When we exit this sync barrier we know that all tasks have // stopped doing marking work. So, it's now safe to // re-initialise our data structures. At the end of this method, @@ -4347,8 +4349,10 @@ // We clear the local state of this task... clear_region_fields(); + if (do_stealing || do_termination) { // ...and enter the second barrier. _cm->enter_second_sync_barrier(_worker_id); + } // At this point everything has bee re-initialised and we're // ready to restart. } Thanks, Bengt On 3/7/13 7:44 AM, Uwe Schindler wrote: > > Hi John, > > I only have time to work on a setup this evening Germen time, because > I am on a business trip today. Will come back to you. Unfortunately I > failed to quickly setup an easy classpath without Ivy downloading the > JARS. > > Uwe > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > *From:*John Cuthbertson [mailto:john.cuthbertson at oracle.com] > *Sent:* Thursday, March 07, 2013 12:49 AM > *To:* Uwe Schindler > *Cc:* 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > *Subject:* Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux > 32 bit) > > Hi Uwe, > > An update: > > I have downloaded ant and the lucerne source. > > I attempted the ivy-bootstrap but it failed to download the > ivy=2.3.0.jar file - even after setting: > > ANT_OPTS=-Dhttp.proxyHost=<...> -Dhttp.proxyPort=<...> > > So I manually downloaded and placed it into the ANT library and now get: > > > ivy-bootstrap1: > [mkdir] Skipping /home/jcuthber/.ant/lib because it already exists. > [echo] installing ivy 2.3.0 to /home/jcuthber/.ant/lib > [get] Getting: > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > [get] To: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [get] Error getting > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > to /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [available] Found: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > > ivy-bootstrap2: > Skipped because property 'ivy.bootstrap1.success' set. > > ivy-checksum: > > ivy-bootstrap: > > BUILD SUCCESSFUL > Total time: 3 minutes 46 seconds > > Presumably I have to build the lucerne source before executing the > tests. That seemed to go OK. > > When I run the analysis/uima tests it seems to get hung up at the > "resolve" target - even without specifying G1: > > > cairnapple{jcuthber}:408> cd analysis/uima/ > cairnapple{jcuthber}:409> ls -l > total 29 > -rw-r--r-- 1 jcuthber staff 1473 Dec 10 10:39 build.xml > -rw-rw-r-- 1 jcuthber staff 6895 Mar 6 15:20 hotspot.log > -rw-r--r-- 1 jcuthber staff 1316 Mar 30 2012 ivy.xml > drwxr-xr-x 2 jcuthber staff 2 Mar 5 07:42 lib/ > drwxr-xr-x 6 jcuthber staff 6 Mar 5 07:42 src/ > > > > ivy-configure: > [ivy:configure] Loading > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivy.properties > > [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: > http://ant.apache.org/ivy/ :: > [ivy:configure] jakarta commons httpclient not found: using jdk url > handling > [ivy:configure] :: loading settings :: file = > /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/ivy-settings.xml > [ivy:configure] no default ivy user dir defined: set to > /home/jcuthber/.ivy2 > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-public.xml > > [ivy:configure] no default cache defined: set to > /home/jcuthber/.ivy2/cache > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-shared.xml > > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-local.xml > > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-main-chain.xml > > [ivy:configure] settings loaded (289ms) > [ivy:configure] default cache: /home/jcuthber/.ivy2/cache > [ivy:configure] default resolver: default > [ivy:configure] -- 7 resolvers: > [ivy:configure] working-chinese-mirror [ibiblio] > [ivy:configure] main [chain] [shared, public] > [ivy:configure] local [file] > [ivy:configure] shared [file] > [ivy:configure] sonatype-releases [ibiblio] > [ivy:configure] public [ibiblio] > [ivy:configure] default [chain] [local, main, > sonatype-releases, working-chinese-mirror] > > resolve: > [ivy:retrieve] no resolved descriptor found: launching default resolve > Overriding previous definition of property "ivy.version" > [ivy:retrieve] using ivy parser to parse > file:/export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/analysis/uima/ivy.xml > > [ivy:retrieve] :: resolving dependencies :: > org.apache.lucene#analyzers-uima;working at cairnapple > [ivy:retrieve] confs: [default] > [ivy:retrieve] validate = true > [ivy:retrieve] refresh = false > [ivy:retrieve] resolving dependencies for configuration 'default' > [ivy:retrieve] == resolving dependencies for > org.apache.lucene#analyzers-uima;working at cairnapple [default] > [ivy:retrieve] == resolving dependencies > org.apache.lucene#analyzers-uima;working at cairnapple->org.apache.uima#Tagger;2.3.1 > [default->*] > [ivy:retrieve] default: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] don't use cache for org.apache.uima#Tagger;2.3.1: > checkModified=true > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] local: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] main: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] shared: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] tried > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom > > and there it hangs - presumably trying to access > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom > > There must be something with our proxy settings that that won't allow > this. > > JohnC > > > On 03/06/13 11:15, Uwe Schindler wrote: > > Hi, > > That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). > If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. > > If you want to do it quicker (should be quite fast to do): > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8):http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... > - put the ANT bin/ dir into your PATH > - download the Apache Lucene source code from Jenkins:https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) > - change to the module that fails: # cd analysis/uima > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). > > I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > > -----Original Message----- > > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > > Sent: Wednesday, March 06, 2013 7:51 PM > > To: Uwe Schindler > > Cc: 'Bengt Rutisson';hotspot-gc-dev at openjdk.java.net ; > > dev at lucene.apache.org > > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > > > Hi Uwe, > > > > I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from > > https://builds.apache.org/job/Lucene-Artifacts- > > trunk/2212/artifact/lucene/dist/ > > > > I don't have ant on my workstation so do you have a java command line to > > run the test(s) that generate the error? > > > > Thanks, > > > > JohnC > > > > On 3/6/2013 3:16 AM, Uwe Schindler wrote: > > > > Hi, > > > > > > I think this is a VM bug and the thread dumps that Uwe produced are > > enough to start tracking down the root cause. > > > > I hope it is enough! If I can help with more details, tell me what I should do > > > > to track this down. Unfortunately, we have no isolated test case (like a small > > java class that triggers this bug) - you have to run the test cases of this > > Lucene's module. It only happens there, not in any other Lucene test suite. It > > may be caused by a lot of GC activity in this "UIMA" module or a specific test. > > > > On 3/6/13 8:52 AM, David Holmes wrote: > > > > If the VM is completely unresponsive then it suggests we are at a > > safepoint. > > > > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > > > > > > The GC threads are not "hung" in os::parK, they are parked - waiting > > to be notified of something. > > > > It looks like the reference processing thread is stuck in a loop > > where it does wait(). So, the VM is hanging even if that stack trace > > also ends up in os::park(). > > > > > > The thing is to find out why they are not being woken up. > > > > Actually, in this case we should probably not even be calling wait... > > > > > > Can the gdb log be posted somewhere? I don't know if the attachment > > made it to the original posting on hotspot-gc but it's no longer > > available on hotspot-dev. > > > > I received the attachment with the original email. I've attached it > > to the bug report that I created: 8009536. You can find it there if > > you want to. But I think we have a fairly good idea of what change > > caused the hang. > > > > If it helps: Unfortunately, we had some problems with recent JDK builds, > > > > because javac and javadoc tools were not working correctly, failing to build > > our source code. Since b78 this was fixed. Until this was fixed, we used build > > b65 (which was the last one working) and the G1GC hangs did not appear on > > this version. So it must have happened by a change after b65 till b78. > > > > Uwe > > > > > > Bengt > > > > > > Thanks, > > David > > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > > > > Hi Uwe, > > > > If you can attach gdb onto it, and jstack -m and jstack -F should > > also work; that'll get you the Java stack trace. > > (But it probably doesn't matter in this case, because the hang is > > probably bug in the VM). > > > > - Kris > > > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > > > > > > > > wrote: > > > > Hi, > > > > since a few month we are extensively testing various preview > > builds of JDK 8 for compatibility with Apache Lucene and Solr, so > > we can find any bugs early and prevent the problems we had with > > the release of Java 7 two years ago. Currently we have a Linux > > (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK > > 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a > > different one with different hotspot and garbage collector > > settings on every run of the test suite (which takes approx. 30-45 > > > > minutes). > > > > JDK 8 b79 works so far very well on Linux, we found some strange > > behavior in early versions (maybe compiler errors), but no longer > > at the moment. There is one configuration that constantly and > > reproducibly hangs in one module that is tested: The configuration > > uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client > > does not matter). The JVM running the tests hangs irresponsible > > (jstack or kill -3 have no effect/cannot connect, standard kill > > does not stop it, only kill -9 actually kills it). It can be > > reproduced in this Lucene module 100% (it hangs always). > > > > I was able to connect with GDB to the JVM and get a stack trace on > > all threads (see attachment, dump.txt). As you see all threads of > > G1GC seem to hang in a syscall (os:park(), a conditional wait in > > pthread library). Unfortunately that?s all I can give you. A Java > > stacktrace is not possible because the JVM reacts on neither kill > > -3 nor jstack. With all other garbage collectors it passes the > > test without hangs in a few seconds, with 32 bit G1GC it can stand > > still for hours. The 64 bit JVM passes with G1GC, so only the 32 > > bit variant is affected. Client or Server VM makes no difference. > > > > To reproduce: > > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > > should not matter) > > - Download Lucene Source code (e.g. the snapshot version we were > > testing with: > > https://builds.apache.org/job/Lucene-Artifacts- > > > > trunk/2212/artifact/lucene/dist/) > > > > - change to directory lucene/analysis/uima and run: > > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test > > After a while the test framework prints "stalled" messages > > (because the child VM actually running the test no longer > > responds). The PID is also printed. Try to get a stack trace or kill it, no > > > > response. > > > > Only kill -9 helps. Choosing another garbage collector in the > > above command line makes the test finish after a few seconds, e.g. > > -Dargs="-server -XX:+UseConcMarkSweepGC" > > > > I posted this bug report directly to the mailing list, because > > with earlier bug reports, there seem to be a problem with > > bugs.sun.com - there is no response from any reviewer after > > several weeks and we were able to help to find and fix javadoc and > > javac-compiler bugs early. So I hope you can help for this bug, too. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer Bremen, Germany > > http://lucene.apache.org/ > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Mar 7 13:32:13 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 07 Mar 2013 14:32:13 +0100 Subject: RFR (M): 8008918: Reference statistics events for the tracing framework In-Reply-To: <5137779A.7040806@oracle.com> References: <5130B692.6070908@oracle.com> <1362385477.2590.9.camel@cirrus> <5137779A.7040806@oracle.com> Message-ID: <513896DD.9000004@oracle.com> Hi Erik, Looks good! Bengt On 3/6/13 6:06 PM, Erik Helin wrote: > Hi Thomas, > > thanks for reviewing! > > Please see comments inline and an updated webrev located at: > http://cr.openjdk.java.net/~ehelin/8008918/webrev.01/ > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > Hi, > > > > On Fri, 2013-03-01 at 15:09 +0100, Erik Helin wrote: > >> Hi all, > >> > >> this change adds the vm/gc/reference/statistics event to all > collectors. > >> > >> Please note that this change depends on "8009232: Improve stats > >> gathering code for reference processor" which is also out for > review on > >> hotspot-gc-dev at openjdk.java.net. > >> > >> Webrev: > >> http://cr.openjdk.java.net/~ehelin/8008918/webrev.00/ > >> > >> Bug: > >> https://jbs.oracle.com/bugs/browse/JDK-8008918 > > > > Minor: Maybe, in concurrentMarkSweepGeneration.cpp the declaration of > > the stats record could be put inside the block. > > Agree, updated. > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > Do you think if there is an easy way to put the sequence of allocating > > the stats record, calling rp->process_discovered_reference and the > > report_gc_reference_processing into a single method that is called > > everywhere? > > I don't think there is an easy way to do it :) > > Ideally I would like the ReferenceProcessor to take care of whether > the reference processing should be run in parallel or not. If this was > the case, then the code could have looked like the following everywhere: > > const ReferenceProcessorStats& stats = > rp->process_discovered_references(...); > gc_tracer->report_gc_reference_stats(stats); > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > This code sequence, is the same in all collectors, and seems to be a > > good target for refactoring. > > Unfortunately, is is not exactly the same. Some collectors, for example > ParNew, takes advantage of the fact that the caller checks whether the > reference processing should be done in parallel or not: > > if (rp->processing_is_mt()) { > ParNewRefProcTaskExecutor task_executor(*this, thread_state_set); > rp->process_discovered_references(&is_alive, &keep_alive, > &evacuate_followers, > &task_executor); > } else { > thread_state_set.flush(); > gch->set_par_threads(0); // 0 ==> non-parallel. > gch->save_marks(); > rp->process_discovered_references(&is_alive, &keep_alive, > &evacuate_followers, NULL); > } > > If one refactor the code so that the ReferenceProcessor decides if the > reference processing should run in parallel, then one has to ensure that > the collector specific logic in the different branches still are > correct. > > This is a cleanup that we definitely should do, but I would like to see > it done as a separate change to ease the reviewing. > > On 03/04/2013 09:24 AM, Thomas Schatzl wrote: > > I.e. what the change basically did is to replace the call to > > process_discovered_reference by above sequence of three statements. > > I would say that the change made the code go from two to three lines. > Before the code looked like: > > if (rp->processig_is_mt()) { > rp->process... > } else { > rp->process... > } > gc_tracer->report_gc_reference_processing(rp->collect_statistics()); > > After the change, the code looks like: > > ReferenceProcessorStats stats; > if (rp->processig_is_mt()) { > stats = rp->process... > } else { > stats = rp->process... > } > gc_tracer->report_gc_reference_processing(stats); > > The only difference in terms of lines is the addition of the "stats" > variable. > > In my opinion, this is a motivated cost for providing a more robust > way to collect the statistics from the reference processor. What do > you think? > > Thanks, > Erik > > > Hth, > > Thomas > > > > > From bengt.rutisson at oracle.com Thu Mar 7 13:35:19 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 07 Mar 2013 14:35:19 +0100 Subject: RFR (S): 8009232: Improve stats gathering code for reference processor In-Reply-To: <51377BDB.3060808@oracle.com> References: <51309249.3030006@oracle.com> <5135BC88.6080002@oracle.com> <51377BDB.3060808@oracle.com> Message-ID: <51389797.3080507@oracle.com> Looks good to me too. Bengt On 3/6/13 6:24 PM, Jesper Wilhelmsson wrote: > Looks good! > > Minor nit: > EventGCReferenceProcessing probably should be called > EventGCReferenceStatistics > > Fix it'n'ship it! :-) > /Jesper > > > On 5/3/13 10:36 AM, Erik Helin wrote: >> All, >> >> based on internal feedback, I've updated the change. >> >> The ReferenceProcessorStats class is now no longer a C++ "friend" >> with the >> ReferenceProcessor class. Furthermore, the method >> ReferenceProcessor::process_discovered_reflist now returns the number of >> discovered references. >> >> I have also renamed GCTrace::report_gc_reference_processing to >> GCTrace::report_gc_reference_stats and >> GCTrace::send_gc_reference_processing_event to >> GCTrace::send_gc_reference_stats_event. This was done because the name >> of the event was previously changed from vm/gc/reference/processing to >> vm/gc/reference/statistics. >> >> New webrev: >> http://cr.openjdk.java.net/~ehelin/8009232/webrev.01/ >> >> Thanks, >> Erik >> >> On 03/01/2013 12:34 PM, Erik Helin wrote: >>> Hi all, >>> >>> this change refactors the way the reference processing statistics are >>> being collected from the reference processor. >>> >>> Summary: >>> Before, the statistics were collected by calling >>> ReferenceProcessor::collect_statistics immediately after a call to >>> ReferenceProcessor::process_discovered_references. With this change, >>> the >>> method process_discovered_references instead returns >>> the statistics. >>> >>> The benefit is that there is now no need to keep track of an internal >>> state in ReferenceProcessor since the ReferenceProcessorStats can be >>> put >>> on the stack in process_discovered_references. Furthermore, the code is >>> more maintainable, since the old code required the calls to >>> process_discovered_references and collect_statistics to go "hand in >>> hand". Now, one only has to care about the call to >>> process_discovered_references. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8009232/webrev.00/ >>> >>> Bug: >>> https://jbs.oracle.com/bugs/browse/JDK-8009232 >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik >> From jon.masamitsu at oracle.com Thu Mar 7 16:13:17 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 07 Mar 2013 08:13:17 -0800 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <5137C43A.2040709@oracle.com> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> Message-ID: <5138BC9D.1010702@oracle.com> Tao, The original assertion seems a worthwhile one (i.e., the maximum heap size is >= to the initial heap size) to enforce. The CR says the problem that not everything has been page aligned. Is the latter not true? Jon On 03/06/13 14:33, Tao Mao wrote: > 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp > https://jbs.oracle.com/bugs/browse/JDK-7196080 > > webrev: > http://cr.openjdk.java.net/~tamao/7196080/webrev.00/ > > changeset: > 1. inequality doesn't transfer here. > X >= align_down(X) > X >= I > altogether, cannot infer that align_down(X) >= I. Simple math! > So, I have removed the original assertion "max_heap >= InitialHeapSize". > 2. It's reasonable to check an extra assertion "max_heap > = OldSize", > following the comment above the assertions. From kevin.walls at oracle.com Thu Mar 7 16:52:00 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 07 Mar 2013 16:52:00 +0000 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <5137889D.2080200@oracle.com> References: <5130E68A.4040806@oracle.com> <5137889D.2080200@oracle.com> Message-ID: <5138C5B0.3040609@oracle.com> Hi Erik - Yes, now you mention it I can see the route to printing the old warning or logging the event twice... I don't think it's reported as a problem, or maybe it's very rare and nobody has spotted it. But assuming it's not a "user-requested" collection, to get that false "should_compact" in acquire_control_and_collect, we need to call decide_foreground_collection_type(), and when it calls incremental_collection_will_fail(), that returns false. Possibly that is why we don't see the event reported twice in practice***: if we've got to this point, and state>Idling, we are usually here because that inc. collection would fail/is failing... Thanks Kevin *** if anybody really does hit this, or think it's likely, we can look again... On 06/03/13 18:19, Erik Helin wrote: > Hi Kevin, > > I think that there _might_ be a bug in CMS which was present even > before you added the event tracing. > > If you look in aquire_control_and_collect, you will see that > "should_compact" can be set to false by > decide_foreground_collection_type. If this is the case, then we will > end up in do_mark_sweep_work. > > The problem is that you have already reported, and CMS has already > printed, that a concurrent mode failure has occurred in > acquire_control_and_collect. Then, when you enter do_mark_sweep_work, > you will once again report, and CMS will again print, that concurrent > mode failure has happened. > > I am not 100% sure that I am right, by I believe that this can happen. > > What do you think? > > Thanks, > Erik > > On 03/01/2013 06:34 PM, Kevin Walls wrote: >> Hi, >> >> I'd like some reviews on this CMS Concurrent Mode Failure event: >> >> http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ >> >> The event doesn't actually carry any new information, but it is a >> warning we need to capture. >> >> This is against hsx24, I'll prepare the same, or reviewed, changes >> against very latest hotspot also. >> >> Thanks >> Kevin >> > From john.cuthbertson at oracle.com Thu Mar 7 17:20:36 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 07 Mar 2013 09:20:36 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <00f601ce1aff$27a76eb0$76f64c10$@apache.org> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> <00f601ce1aff$27a76eb0$76f64c10$@apache.org> Message-ID: <5138CC64.4090404@oracle.com> Hi Uwe, Thanks. In the meantime I'm going to ask within oracle if anyone has the magic formula for the proxy settings. There might able be another test case I can try. IIR we had another application that overflowed during reference processing (if I specified a mark stack size of 16K). I'm going to try that. I'm fairly certain I have the fix - just want to verify it. I klnow you offered but I don't think we can send out under the table binaries though we can provide patches. JohnC On 3/6/2013 10:44 PM, Uwe Schindler wrote: > > Hi John, > > I only have time to work on a setup this evening Germen time, because > I am on a business trip today. Will come back to you. Unfortunately I > failed to quickly setup an easy classpath without Ivy downloading the > JARS. > > Uwe > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > *From:*John Cuthbertson [mailto:john.cuthbertson at oracle.com] > *Sent:* Thursday, March 07, 2013 12:49 AM > *To:* Uwe Schindler > *Cc:* 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; > dev at lucene.apache.org > *Subject:* Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux > 32 bit) > > Hi Uwe, > > An update: > > I have downloaded ant and the lucerne source. > > I attempted the ivy-bootstrap but it failed to download the > ivy=2.3.0.jar file - even after setting: > > ANT_OPTS=-Dhttp.proxyHost=<...> -Dhttp.proxyPort=<...> > > So I manually downloaded and placed it into the ANT library and now get: > > > ivy-bootstrap1: > [mkdir] Skipping /home/jcuthber/.ant/lib because it already exists. > [echo] installing ivy 2.3.0 to /home/jcuthber/.ant/lib > [get] Getting: > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > [get] To: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [get] Error getting > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar > to /home/jcuthber/.ant/lib/ivy-2.3.0.jar > [available] Found: /home/jcuthber/.ant/lib/ivy-2.3.0.jar > > ivy-bootstrap2: > Skipped because property 'ivy.bootstrap1.success' set. > > ivy-checksum: > > ivy-bootstrap: > > BUILD SUCCESSFUL > Total time: 3 minutes 46 seconds > > Presumably I have to build the lucerne source before executing the > tests. That seemed to go OK. > > When I run the analysis/uima tests it seems to get hung up at the > "resolve" target - even without specifying G1: > > > cairnapple{jcuthber}:408> cd analysis/uima/ > cairnapple{jcuthber}:409> ls -l > total 29 > -rw-r--r-- 1 jcuthber staff 1473 Dec 10 10:39 build.xml > -rw-rw-r-- 1 jcuthber staff 6895 Mar 6 15:20 hotspot.log > -rw-r--r-- 1 jcuthber staff 1316 Mar 30 2012 ivy.xml > drwxr-xr-x 2 jcuthber staff 2 Mar 5 07:42 lib/ > drwxr-xr-x 6 jcuthber staff 6 Mar 5 07:42 src/ > > > > ivy-configure: > [ivy:configure] Loading > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivy.properties > > [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: > http://ant.apache.org/ivy/ :: > [ivy:configure] jakarta commons httpclient not found: using jdk url > handling > [ivy:configure] :: loading settings :: file = > /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/ivy-settings.xml > [ivy:configure] no default ivy user dir defined: set to > /home/jcuthber/.ivy2 > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-public.xml > > [ivy:configure] no default cache defined: set to > /home/jcuthber/.ivy2/cache > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-shared.xml > > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-local.xml > > [ivy:configure] including url: > jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-main-chain.xml > > [ivy:configure] settings loaded (289ms) > [ivy:configure] default cache: /home/jcuthber/.ivy2/cache > [ivy:configure] default resolver: default > [ivy:configure] -- 7 resolvers: > [ivy:configure] working-chinese-mirror [ibiblio] > [ivy:configure] main [chain] [shared, public] > [ivy:configure] local [file] > [ivy:configure] shared [file] > [ivy:configure] sonatype-releases [ibiblio] > [ivy:configure] public [ibiblio] > [ivy:configure] default [chain] [local, main, > sonatype-releases, working-chinese-mirror] > > resolve: > [ivy:retrieve] no resolved descriptor found: launching default resolve > Overriding previous definition of property "ivy.version" > [ivy:retrieve] using ivy parser to parse > file:/export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/analysis/uima/ivy.xml > > [ivy:retrieve] :: resolving dependencies :: > org.apache.lucene#analyzers-uima;working at cairnapple > [ivy:retrieve] confs: [default] > [ivy:retrieve] validate = true > [ivy:retrieve] refresh = false > [ivy:retrieve] resolving dependencies for configuration 'default' > [ivy:retrieve] == resolving dependencies for > org.apache.lucene#analyzers-uima;working at cairnapple [default] > [ivy:retrieve] == resolving dependencies > org.apache.lucene#analyzers-uima;working at cairnapple->org.apache.uima#Tagger;2.3.1 > [default->*] > [ivy:retrieve] default: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] don't use cache for org.apache.uima#Tagger;2.3.1: > checkModified=true > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] local: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] main: Checking cache for: dependency: > org.apache.uima#Tagger;2.3.1 {*=[*]} > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml > [ivy:retrieve] tried > /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar > [ivy:retrieve] shared: no ivy file nor artifact found for > org.apache.uima#Tagger;2.3.1 > [ivy:retrieve] tried > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom > > and there it hangs - presumably trying to access > http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom > > There must be something with our proxy settings that that won't allow > this. > > JohnC > > > On 03/06/13 11:15, Uwe Schindler wrote: > > Hi, > > That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). > If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. > > If you want to do it quicker (should be quite fast to do): > - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8):http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... > - put the ANT bin/ dir into your PATH > - download the Apache Lucene source code from Jenkins:https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz > - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) > - change to the module that fails: # cd analysis/uima > - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test > - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). > > I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > Apache Lucene PMC Member / Committer > Bremen, Germany > http://lucene.apache.org/ > > > > > -----Original Message----- > > From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] > > Sent: Wednesday, March 06, 2013 7:51 PM > > To: Uwe Schindler > > Cc: 'Bengt Rutisson';hotspot-gc-dev at openjdk.java.net ; > > dev at lucene.apache.org > > Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) > > > > Hi Uwe, > > > > I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from > > https://builds.apache.org/job/Lucene-Artifacts- > > trunk/2212/artifact/lucene/dist/ > > > > I don't have ant on my workstation so do you have a java command line to > > run the test(s) that generate the error? > > > > Thanks, > > > > JohnC > > > > On 3/6/2013 3:16 AM, Uwe Schindler wrote: > > > > Hi, > > > > > > I think this is a VM bug and the thread dumps that Uwe produced are > > enough to start tracking down the root cause. > > > > I hope it is enough! If I can help with more details, tell me what I should do > > > > to track this down. Unfortunately, we have no isolated test case (like a small > > java class that triggers this bug) - you have to run the test cases of this > > Lucene's module. It only happens there, not in any other Lucene test suite. It > > may be caused by a lot of GC activity in this "UIMA" module or a specific test. > > > > On 3/6/13 8:52 AM, David Holmes wrote: > > > > If the VM is completely unresponsive then it suggests we are at a > > safepoint. > > > > Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. > > > > > > The GC threads are not "hung" in os::parK, they are parked - waiting > > to be notified of something. > > > > It looks like the reference processing thread is stuck in a loop > > where it does wait(). So, the VM is hanging even if that stack trace > > also ends up in os::park(). > > > > > > The thing is to find out why they are not being woken up. > > > > Actually, in this case we should probably not even be calling wait... > > > > > > Can the gdb log be posted somewhere? I don't know if the attachment > > made it to the original posting on hotspot-gc but it's no longer > > available on hotspot-dev. > > > > I received the attachment with the original email. I've attached it > > to the bug report that I created: 8009536. You can find it there if > > you want to. But I think we have a fairly good idea of what change > > caused the hang. > > > > If it helps: Unfortunately, we had some problems with recent JDK builds, > > > > because javac and javadoc tools were not working correctly, failing to build > > our source code. Since b78 this was fixed. Until this was fixed, we used build > > b65 (which was the last one working) and the G1GC hangs did not appear on > > this version. So it must have happened by a change after b65 till b78. > > > > Uwe > > > > > > Bengt > > > > > > Thanks, > > David > > > > On 6/03/2013 4:07 PM, Krystal Mok wrote: > > > > Hi Uwe, > > > > If you can attach gdb onto it, and jstack -m and jstack -F should > > also work; that'll get you the Java stack trace. > > (But it probably doesn't matter in this case, because the hang is > > probably bug in the VM). > > > > - Kris > > > > On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler > > > > > > > > wrote: > > > > Hi, > > > > since a few month we are extensively testing various preview > > builds of JDK 8 for compatibility with Apache Lucene and Solr, so > > we can find any bugs early and prevent the problems we had with > > the release of Java 7 two years ago. Currently we have a Linux > > (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK > > 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a > > different one with different hotspot and garbage collector > > settings on every run of the test suite (which takes approx. 30-45 > > > > minutes). > > > > JDK 8 b79 works so far very well on Linux, we found some strange > > behavior in early versions (maybe compiler errors), but no longer > > at the moment. There is one configuration that constantly and > > reproducibly hangs in one module that is tested: The configuration > > uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client > > does not matter). The JVM running the tests hangs irresponsible > > (jstack or kill -3 have no effect/cannot connect, standard kill > > does not stop it, only kill -9 actually kills it). It can be > > reproduced in this Lucene module 100% (it hangs always). > > > > I was able to connect with GDB to the JVM and get a stack trace on > > all threads (see attachment, dump.txt). As you see all threads of > > G1GC seem to hang in a syscall (os:park(), a conditional wait in > > pthread library). Unfortunately that?s all I can give you. A Java > > stacktrace is not possible because the JVM reacts on neither kill > > -3 nor jstack. With all other garbage collectors it passes the > > test without hangs in a few seconds, with 32 bit G1GC it can stand > > still for hours. The 64 bit JVM passes with G1GC, so only the 32 > > bit variant is affected. Client or Server VM makes no difference. > > > > To reproduce: > > - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this > > should not matter) > > - Download Lucene Source code (e.g. the snapshot version we were > > testing with: > > https://builds.apache.org/job/Lucene-Artifacts- > > > > trunk/2212/artifact/lucene/dist/) > > > > - change to directory lucene/analysis/uima and run: > > ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 > > -Dtests.jvms=1 test > > After a while the test framework prints "stalled" messages > > (because the child VM actually running the test no longer > > responds). The PID is also printed. Try to get a stack trace or kill it, no > > > > response. > > > > Only kill -9 helps. Choosing another garbage collector in the > > above command line makes the test finish after a few seconds, e.g. > > -Dargs="-server -XX:+UseConcMarkSweepGC" > > > > I posted this bug report directly to the mailing list, because > > with earlier bug reports, there seem to be a problem with > > bugs.sun.com - there is no response from any reviewer after > > several weeks and we were able to help to find and fix javadoc and > > javac-compiler bugs early. So I hope you can help for this bug, too. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > Apache Lucene PMC Member / Committer Bremen, Germany > > http://lucene.apache.org/ > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Thu Mar 7 17:26:17 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 07 Mar 2013 09:26:17 -0800 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> <00f601ce1aff$27a76eb0$76f64c10$@apache.org> Message-ID: <5138CDB9.2080301@oracle.com> Hi Dawid, Thanks, I'll give it a try. As I said I'm fairly certain I have the fix but want to verify it before sending out for review. JohnC On 3/7/2013 1:37 AM, Dawid Weiss wrote: > > At the top of the archive there is a repro.sh (or repro.cmd for > windows) which reproduces the issue, JDK 1.8 included. I couldn't > get it to hang on a 1-cpu linux (vmware). on windows it hangs for > me all the time. > > > Update: hangs for me 100% under vmware/ubuntu if I bump the number of > cpus to 2. So: > > cd /tmp > wget http://ophelia.cs.put.poznan.pl/~dweiss/download/_g1gc.tar.gz > > tar -zxf _g1gc.tar.gz > cd _g1gc > ./repro.sh > > Dawid -------------- next part -------------- An HTML attachment was scrubbed... URL: From uschindler at apache.org Thu Mar 7 17:29:42 2013 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 7 Mar 2013 18:29:42 +0100 Subject: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) In-Reply-To: <5138CC64.4090404@oracle.com> References: <01d201ce19eb$332d5160$9987f420$@apache.org> <5136F5BA.7010409@oracle.com> <5136F888.6010501@oracle.com> <009001ce1a5c$1bcee3a0$536caae0$@apache.org> <51379029.8090904@oracle.com> <006d01ce1a9e$f47c60f0$dd7522d0$@apache.org> <5137D5E9.7000807@oracle.com> <00f601ce1aff$27a76eb0$76f64c10$@apache.org> <5138CC64.4090404@oracle.com> Message-ID: <010c01ce1b59$5ade7210$109b5630$@apache.org> Hi John, I am back from the trip since a few minutes (Cebit fair in Hannover). David Weiss already sent a solution, I hope that helps. My idea was to send you my own ~/ivy/ cache folder (that contains all downloaded Maven Central artifacts), so ANT/IVY does not need to download them. But I think you can first try Dawid Weiss? solution (who packed his complete Lucene folder). Also Bengt gave some proxy settings to make it work with Oracle?s proxies, he was able to reproduce on Windows. So I don?t think I need to send another variant for reproducing. You can send the binary/patch to Bengt, who may be able to try it out! Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] Sent: Thursday, March 07, 2013 6:21 PM To: Uwe Schindler Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; dev at lucene.apache.org Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Hi Uwe, Thanks. In the meantime I'm going to ask within oracle if anyone has the magic formula for the proxy settings. There might able be another test case I can try. IIR we had another application that overflowed during reference processing (if I specified a mark stack size of 16K). I'm going to try that. I'm fairly certain I have the fix - just want to verify it. I klnow you offered but I don't think we can send out under the table binaries though we can provide patches. JohnC On 3/6/2013 10:44 PM, Uwe Schindler wrote: Hi John, I only have time to work on a setup this evening Germen time, because I am on a business trip today. Will come back to you. Unfortunately I failed to quickly setup an easy classpath without Ivy downloading the JARS. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] Sent: Thursday, March 07, 2013 12:49 AM To: Uwe Schindler Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; dev at lucene.apache.org Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Hi Uwe, An update: I have downloaded ant and the lucerne source. I attempted the ivy-bootstrap but it failed to download the ivy=2.3.0.jar file - even after setting: ANT_OPTS=-Dhttp.proxyHost=<...> -Dhttp.proxyPort=<...> So I manually downloaded and placed it into the ANT library and now get: ivy-bootstrap1: [mkdir] Skipping /home/jcuthber/.ant/lib because it already exists. [echo] installing ivy 2.3.0 to /home/jcuthber/.ant/lib [get] Getting: http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar [get] To: /home/jcuthber/.ant/lib/ivy-2.3.0.jar [get] Error getting http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.3.0/ivy-2.3.0.jar to /home/jcuthber/.ant/lib/ivy-2.3.0.jar [available] Found: /home/jcuthber/.ant/lib/ivy-2.3.0.jar ivy-bootstrap2: Skipped because property 'ivy.bootstrap1.success' set. ivy-checksum: ivy-bootstrap: BUILD SUCCESSFUL Total time: 3 minutes 46 seconds Presumably I have to build the lucerne source before executing the tests. That seemed to go OK. When I run the analysis/uima tests it seems to get hung up at the "resolve" target - even without specifying G1: cairnapple{jcuthber}:408> cd analysis/uima/ cairnapple{jcuthber}:409> ls -l total 29 -rw-r--r-- 1 jcuthber staff 1473 Dec 10 10:39 build.xml -rw-rw-r-- 1 jcuthber staff 6895 Mar 6 15:20 hotspot.log -rw-r--r-- 1 jcuthber staff 1316 Mar 30 2012 ivy.xml drwxr-xr-x 2 jcuthber staff 2 Mar 5 07:42 lib/ drwxr-xr-x 6 jcuthber staff 6 Mar 5 07:42 src/ ivy-configure: [ivy:configure] Loading jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivy.properties [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: http://ant.apache.org/ivy/ :: [ivy:configure] jakarta commons httpclient not found: using jdk url handling [ivy:configure] :: loading settings :: file = /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/ivy-settings.xml [ivy:configure] no default ivy user dir defined: set to /home/jcuthber/.ivy2 [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-public.xml [ivy:configure] no default cache defined: set to /home/jcuthber/.ivy2/cache [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-shared.xml [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-local.xml [ivy:configure] including url: jar:file:/home/jcuthber/.ant/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings-main-chain.xml [ivy:configure] settings loaded (289ms) [ivy:configure] default cache: /home/jcuthber/.ivy2/cache [ivy:configure] default resolver: default [ivy:configure] -- 7 resolvers: [ivy:configure] working-chinese-mirror [ibiblio] [ivy:configure] main [chain] [shared, public] [ivy:configure] local [file] [ivy:configure] shared [file] [ivy:configure] sonatype-releases [ibiblio] [ivy:configure] public [ibiblio] [ivy:configure] default [chain] [local, main, sonatype-releases, working-chinese-mirror] resolve: [ivy:retrieve] no resolved descriptor found: launching default resolve Overriding previous definition of property "ivy.version" [ivy:retrieve] using ivy parser to parse file:/export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/analysis/uima/ivy.xml [ivy:retrieve] :: resolving dependencies :: org.apache.lucene#analyzers-uima;working at cairnapple [ivy:retrieve] confs: [default] [ivy:retrieve] validate = true [ivy:retrieve] refresh = false [ivy:retrieve] resolving dependencies for configuration 'default' [ivy:retrieve] == resolving dependencies for org.apache.lucene#analyzers-uima;working at cairnapple [default] [ivy:retrieve] == resolving dependencies org.apache.lucene#analyzers-uima;working at cairnapple->org.apache.uima#Tagger;2.3.1 [default->*] [ivy:retrieve] default: Checking cache for: dependency: org.apache.uima#Tagger;2.3.1 {*=[*]} [ivy:retrieve] don't use cache for org.apache.uima#Tagger;2.3.1: checkModified=true [ivy:retrieve] tried /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml [ivy:retrieve] tried /home/jcuthber/.ivy2/local/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar [ivy:retrieve] local: no ivy file nor artifact found for org.apache.uima#Tagger;2.3.1 [ivy:retrieve] main: Checking cache for: dependency: org.apache.uima#Tagger;2.3.1 {*=[*]} [ivy:retrieve] tried /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/ivys/ivy.xml [ivy:retrieve] tried /home/jcuthber/.ivy2/shared/org.apache.uima/Tagger/2.3.1/jars/Tagger.jar [ivy:retrieve] shared: no ivy file nor artifact found for org.apache.uima#Tagger;2.3.1 [ivy:retrieve] tried http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom and there it hangs - presumably trying to access http://repo1.maven.org/maven2/org/apache/uima/Tagger/2.3.1/Tagger-2.3.1.pom There must be something with our proxy settings that that won't allow this. JohnC On 03/06/13 11:15, Uwe Schindler wrote: Hi, That's unfortunately not so easy, because of project dependencies. To run the test you have to compile Lucene Core then the specific module + the test framework (which is special for Lucene) and download some JARs from Maven central (JAR hell, as usual). If you give me some time, I would collect all needed JAR files from my local checkout and provide you the correct cmd line + a ZIP file with maybe a shell script to startup. It should be doable, but needs some work to collect all dependencies for the classpath. If you want to do it quicker (should be quite fast to do): - Download ANT 1.8.2 binary zip (unfortunately ANT 1.8.4 has a bug making it not working out of the box with Java 8): http://archive.apache.org/dist/ant/binaries/apache-ant-1.8.2-bin.tar.gz - I just wonder about the fact: isn't ANT needed to build the JDK classlib by itself? I remember that the FreeBSD OpenJDK build downloads ANT and does a large part of the compilation using ANT... - put the ANT bin/ dir into your PATH - download the Apache Lucene source code from Jenkins: https://builds.apache.org/job/Lucene-Artifacts-trunk/2212/artifact/lucene/dist/lucene-5.0-2013-03-05_15-37-06-src.tgz - go to extracted lucene source dir, call "ant ivy-bootstrap" (this will download Apache IVY, so all dependencies can be downloaded from Maven Central) - change to the module that fails: # cd analysis/uima - execute: # ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test - In a parallel console you might be able to attach to the process, the build in the main console using ANT runs inside ANT and the test framework spawns separate worker instances of the JVM to execute the tests. This makes it hard to reproduce in standalone (the command line passed to the child JVM is veeeeery long). I will work on putting together a precompiled ZIP file with all needed JARs + the command line. Just tell me if you got it managed with the above howto, then I don?t need to do this. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -----Original Message----- From: John Cuthbertson [mailto:john.cuthbertson at oracle.com] Sent: Wednesday, March 06, 2013 7:51 PM To: Uwe Schindler Cc: 'Bengt Rutisson'; hotspot-gc-dev at openjdk.java.net; dev at lucene.apache.org Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit) Hi Uwe, I've downloaded lucene-5.0-2013-03-05_15-37-06.zip from https://builds.apache.org/job/Lucene-Artifacts- trunk/2212/artifact/lucene/dist/ I don't have ant on my workstation so do you have a java command line to run the test(s) that generate the error? Thanks, JohnC On 3/6/2013 3:16 AM, Uwe Schindler wrote: Hi, I think this is a VM bug and the thread dumps that Uwe produced are enough to start tracking down the root cause. I hope it is enough! If I can help with more details, tell me what I should do to track this down. Unfortunately, we have no isolated test case (like a small java class that triggers this bug) - you have to run the test cases of this Lucene's module. It only happens there, not in any other Lucene test suite. It may be caused by a lot of GC activity in this "UIMA" module or a specific test. On 3/6/13 8:52 AM, David Holmes wrote: If the VM is completely unresponsive then it suggests we are at a safepoint. Yes, we are hanging during a stop-the-world GC, so we are at a safepoint. The GC threads are not "hung" in os::parK, they are parked - waiting to be notified of something. It looks like the reference processing thread is stuck in a loop where it does wait(). So, the VM is hanging even if that stack trace also ends up in os::park(). The thing is to find out why they are not being woken up. Actually, in this case we should probably not even be calling wait... Can the gdb log be posted somewhere? I don't know if the attachment made it to the original posting on hotspot-gc but it's no longer available on hotspot-dev. I received the attachment with the original email. I've attached it to the bug report that I created: 8009536. You can find it there if you want to. But I think we have a fairly good idea of what change caused the hang. If it helps: Unfortunately, we had some problems with recent JDK builds, because javac and javadoc tools were not working correctly, failing to build our source code. Since b78 this was fixed. Until this was fixed, we used build b65 (which was the last one working) and the G1GC hangs did not appear on this version. So it must have happened by a change after b65 till b78. Uwe Bengt Thanks, David On 6/03/2013 4:07 PM, Krystal Mok wrote: Hi Uwe, If you can attach gdb onto it, and jstack -m and jstack -F should also work; that'll get you the Java stack trace. (But it probably doesn't matter in this case, because the hang is probably bug in the VM). - Kris On Wed, Mar 6, 2013 at 5:48 AM, Uwe Schindler wrote: Hi, since a few month we are extensively testing various preview builds of JDK 8 for compatibility with Apache Lucene and Solr, so we can find any bugs early and prevent the problems we had with the release of Java 7 two years ago. Currently we have a Linux (Ubuntu 64bit) Jenkins machine that has various JDKs (JDK 6, JDK 7, JDK 8 snapshot, IBM J9, older JRockit) installed, choosing a different one with different hotspot and garbage collector settings on every run of the test suite (which takes approx. 30-45 minutes). JDK 8 b79 works so far very well on Linux, we found some strange behavior in early versions (maybe compiler errors), but no longer at the moment. There is one configuration that constantly and reproducibly hangs in one module that is tested: The configuration uses JDK 8 b79 (same for b78), 32 bit, and G1GC (server or client does not matter). The JVM running the tests hangs irresponsible (jstack or kill -3 have no effect/cannot connect, standard kill does not stop it, only kill -9 actually kills it). It can be reproduced in this Lucene module 100% (it hangs always). I was able to connect with GDB to the JVM and get a stack trace on all threads (see attachment, dump.txt). As you see all threads of G1GC seem to hang in a syscall (os:park(), a conditional wait in pthread library). Unfortunately that?s all I can give you. A Java stacktrace is not possible because the JVM reacts on neither kill -3 nor jstack. With all other garbage collectors it passes the test without hangs in a few seconds, with 32 bit G1GC it can stand still for hours. The 64 bit JVM passes with G1GC, so only the 32 bit variant is affected. Client or Server VM makes no difference. To reproduce: - Use a 32 bit JDK 8 b78 or b79 (tested on Linux 64 bit, but this should not matter) - Download Lucene Source code (e.g. the snapshot version we were testing with: https://builds.apache.org/job/Lucene-Artifacts- trunk/2212/artifact/lucene/dist/) - change to directory lucene/analysis/uima and run: ant -Dargs="-server -XX:+UseG1GC" -Dtests.multiplier=3 -Dtests.jvms=1 test After a while the test framework prints "stalled" messages (because the child VM actually running the test no longer responds). The PID is also printed. Try to get a stack trace or kill it, no response. Only kill -9 helps. Choosing another garbage collector in the above command line makes the test finish after a few seconds, e.g. -Dargs="-server -XX:+UseConcMarkSweepGC" I posted this bug report directly to the mailing list, because with earlier bug reports, there seem to be a problem with bugs.sun.com - there is no response from any reviewer after several weeks and we were able to help to find and fix javadoc and javac-compiler bugs early. So I hope you can help for this bug, too. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Thu Mar 7 18:37:00 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 07 Mar 2013 10:37:00 -0800 Subject: Request for review: 8008368: Deprecate MaxGCMinorPauseMillis In-Reply-To: <51366A10.3090707@oracle.com> References: <512FAD5C.50103@oracle.com> <51359CA2.9070600@oracle.com> <51365D62.5040604@oracle.com> <51366A10.3090707@oracle.com> Message-ID: <5138DE4C.9030704@oracle.com> Thank you for review, John. I'll create a new CR for it. Tao On 3/5/13 1:56 PM, John Cuthbertson wrote: > Hi Tao, > > Looks OK to me. > > Examples would be: > > -XX:CMSParPromoteBlocksToClaim= > -XX:ParallelGCOldGenAllocBufferSize= > > Basically there are a few GC flags that we accept in > Arguments::parse_each_vm_init_arg() just so that we can emit a warning > message. These would be reasonable candidates. You don't need to list > them all in the new CR - just list the kind of flag that is a good > candidate for adding into check_deprecated_gc_flags(), namely it's > accepted in Arguments::parse_each_vm_init_arg() just so as to emit a > warning. > > Thanks, > > JohnC > > On 3/5/2013 1:02 PM, Tao Mao wrote: >> A new webrev is updated according to your feedback. >> http://cr.openjdk.java.net/~tamao/8008368/webrev.01/ >> >> Plus, what are the other deprecated GC flags you mentioned? >> >> Thanks. >> Tao >> >> On 3/4/13 11:20 PM, John Cuthbertson wrote: >>> Hi Tao, >>> >>> I would change the name of the new routine to >>> check_deprecated_gc_flags() and I would move the call to after the >>> check_deprecated_gcs(). >>> >>> Other than the above it looks good. >>> >>> You may want to file an enhancement to move some the other >>> deprecated GC flags, for which we emit warnings, into the new routine. >>> >>> JohnC >>> >>> On 2/28/2013 11:17 AM, Tao Mao wrote: >>>> 8008368: Deprecate MaxGCMinorPauseMillis >>>> https://jbs.oracle.com/bugs/browse/JDK-8008368 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~tamao/8008368/webrev.00/ >>>> >>>> changeset: >>>> We don't need the distinction between MaxGCMinorPauseMillis and >>>> MaxGCPauseMillis. The MaxGCMinorPauseMillis flag was introduced as >>>> a backup measure in case one pause target for all types collections >>>> was not enough. As it has turned out it seems one pause target is >>>> enough. Thus, we should deprecate MaxGCMinorPauseMillis and give a >>>> warning when set. >>>> >>>> testing: >>>> passed JPRT test(sanity) >>>> >>> > From tao.mao at oracle.com Thu Mar 7 18:37:15 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 07 Mar 2013 10:37:15 -0800 Subject: Request for review: 8008368: Deprecate MaxGCMinorPauseMillis In-Reply-To: <5136E9C4.9060307@oracle.com> References: <512FAD5C.50103@oracle.com> <51359CA2.9070600@oracle.com> <51365D62.5040604@oracle.com> <5136E9C4.9060307@oracle.com> Message-ID: <5138DE5B.9080306@oracle.com> Thank you for review, Bengt. I'll create a new CR for it. Tao On 3/5/13 11:01 PM, Bengt Rutisson wrote: > > Hi Tao, > > Looks good to me. Thanks for fixing this! > > As for other GC flags that are deprecated we could potentially move > the check for CMSIncrementalMode from check_deprecated_gcs() into your > new check_deprecated_gc_flags(). > > 1821 if (CMSIncrementalMode) { > 1822 warning("Using incremental CMS is deprecated and will likely > be removed in a future release"); > 1823 } > > But I don't think you have to do that now. > > Thanks, > Bengt > > On 3/5/13 10:02 PM, Tao Mao wrote: >> A new webrev is updated according to your feedback. >> http://cr.openjdk.java.net/~tamao/8008368/webrev.01/ >> >> Plus, what are the other deprecated GC flags you mentioned? >> >> Thanks. >> Tao >> >> On 3/4/13 11:20 PM, John Cuthbertson wrote: >>> Hi Tao, >>> >>> I would change the name of the new routine to >>> check_deprecated_gc_flags() and I would move the call to after the >>> check_deprecated_gcs(). >>> >>> Other than the above it looks good. >>> >>> You may want to file an enhancement to move some the other >>> deprecated GC flags, for which we emit warnings, into the new routine. >>> >>> JohnC >>> >>> On 2/28/2013 11:17 AM, Tao Mao wrote: >>>> 8008368: Deprecate MaxGCMinorPauseMillis >>>> https://jbs.oracle.com/bugs/browse/JDK-8008368 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~tamao/8008368/webrev.00/ >>>> >>>> changeset: >>>> We don't need the distinction between MaxGCMinorPauseMillis and >>>> MaxGCPauseMillis. The MaxGCMinorPauseMillis flag was introduced as >>>> a backup measure in case one pause target for all types collections >>>> was not enough. As it has turned out it seems one pause target is >>>> enough. Thus, we should deprecate MaxGCMinorPauseMillis and give a >>>> warning when set. >>>> >>>> testing: >>>> passed JPRT test(sanity) >>>> >>> > From jon.masamitsu at oracle.com Thu Mar 7 20:20:34 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 07 Mar 2013 12:20:34 -0800 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed In-Reply-To: <1362639401.2659.3.camel@cirrus> References: <1362571695.2599.23.camel@cirrus> <513777ED.6030209@oracle.com> <1362639401.2659.3.camel@cirrus> Message-ID: <5138F692.7090300@oracle.com> Looks good. Thanks. On 03/06/13 22:56, Thomas Schatzl wrote: > Hi, > > new webrev at > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8008684/webrev.1/ > > Passes jprt. > > Note that tty->stamp(bool) automatically adds the colons, so I removed > them from the string. > > Hth, > Thomas > > On Wed, 2013-03-06 at 09:07 -0800, Jon Masamitsu wrote: >> Thomas, >> >> I've added a comment to the bug report to clarify what >> I think should be changed. Sorry that my original description >> was lacking. Please take a look and let me know if it is >> still not clear. >> >> Jon >> >> On 3/6/2013 4:08 AM, Thomas Schatzl wrote: >>> Hi all, >>> >>> this change always adds a timestamp marker for CMS concurrent phase >>> messages as suggested by the CR. >>> I added an extra space between timestamp and the original message for >>> better readability. >>> >>> I.e. instead of printing >>> >>> [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 sys=0.00, >>> real=0.09 secs] >>> [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 sys=0.00, >>> real=0.00 secs] >>> >>> the VM now prints >>> >>> 20.014 [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 >>> sys=0.00, real=0.09 secs] >>> 20.019 [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 >>> sys=0.00, real=0.00 secs] >>> >>> if -XX:+PrintGCDetails is set with CMS. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8008684/webrev/ >>> >>> Bugs >>> http://bugs.sun.com/view_bug.do?bug_id=8008684 >>> >>> JIRA: >>> https://jbs.oracle.com/bugs/browse/JDK-8008684 >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Thomas >>> > From jon.masamitsu at oracle.com Thu Mar 7 20:57:30 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 07 Mar 2013 12:57:30 -0800 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <513855CC.5030009@oracle.com> References: <513855CC.5030009@oracle.com> Message-ID: <5138FF3A.6070902@oracle.com> On 03/07/13 00:54, Mikael Gerdin wrote: > Hi > > > When deciding when to reserve more metaspace memory we erroneously > looked only at the "capacity" of the metaspace insted of the reserved > space (which is what we ask this function when expanding). Using MetaspaceAux::reserved_in_bytes() means that we could return false here 1105 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)&& 1106 MetaspaceAux::reserved_in_bytes()>= MaxMetaspaceSize) { 1107 return false; 1108 } when most of the space reserved in one or two VirtualSpace's is unused. With the current value of parameters, that could almost be 512kb. Jon > > Additionally, we didn't check MaxMetaspaceSize against the sum of > reserved(Class) + reserved(NonClass) which caused us to use more than > MaxMetaspaceSize even when it was set. > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 > (not yet available at the time of writing this mail) > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 > > Testing: > JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code > path. From jon.masamitsu at oracle.com Thu Mar 7 21:10:03 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 07 Mar 2013 13:10:03 -0800 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <5138BC9D.1010702@oracle.com> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> Message-ID: <5139022B.4070209@oracle.com> Tao, As per our discussion feel free to delete both assertions. Jon On 03/07/13 08:13, Jon Masamitsu wrote: > Tao, > > The original assertion seems a worthwhile one > (i.e., the maximum heap size is >= to the > initial heap size) to enforce. The CR says the problem > that not everything has been page aligned. Is > the latter not true? > > Jon > > On 03/06/13 14:33, Tao Mao wrote: >> 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp >> https://jbs.oracle.com/bugs/browse/JDK-7196080 >> >> webrev: >> http://cr.openjdk.java.net/~tamao/7196080/webrev.00/ >> >> changeset: >> 1. inequality doesn't transfer here. >> X >= align_down(X) >> X >= I >> altogether, cannot infer that align_down(X) >= I. Simple math! >> So, I have removed the original assertion "max_heap >= InitialHeapSize". >> 2. It's reasonable to check an extra assertion "max_heap > = >> OldSize", following the comment above the assertions. From poonam.bajaj at oracle.com Fri Mar 8 00:03:04 2013 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Fri, 08 Mar 2013 05:33:04 +0530 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <5130E68A.4040806@oracle.com> References: <5130E68A.4040806@oracle.com> Message-ID: <51392AB8.7010503@oracle.com> Hi Kevin, Changes look good to me. Thanks, Poonam On 3/1/2013 11:04 PM, Kevin Walls wrote: > Hi, > > I'd like some reviews on this CMS Concurrent Mode Failure event: > > http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ > > The event doesn't actually carry any new information, but it is a > warning we need to capture. > > This is against hsx24, I'll prepare the same, or reviewed, changes > against very latest hotspot also. > > Thanks > Kevin > From john.coomes at oracle.com Fri Mar 8 09:32:33 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 09:32:33 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b80 for changeset 5f3d4a6bdd02 Message-ID: <20130308093235.E311147EFE@hg.openjdk.java.net> Changeset: 2a00aeeb466b Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/2a00aeeb466b Added tag jdk8-b80 for changeset 5f3d4a6bdd02 ! .hgtags From john.coomes at oracle.com Fri Mar 8 09:32:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 09:32:41 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b80 for changeset 4873a0499bc3 Message-ID: <20130308093249.1FA2747F01@hg.openjdk.java.net> Changeset: ef3495555a4c Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/ef3495555a4c Added tag jdk8-b80 for changeset 4873a0499bc3 ! .hgtags From john.coomes at oracle.com Fri Mar 8 09:32:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 09:32:28 +0000 Subject: hg: hsx/hotspot-gc: 6 new changesets Message-ID: <20130308093229.4883947EFB@hg.openjdk.java.net> Changeset: ab82853d3365 Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/ab82853d3365 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: d3e3d5b06f45 Author: ohair Date: 2013-02-23 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/d3e3d5b06f45 8004712: build-infra: Move user guide from web pages to repository Summary: Just the initial work, will need more changes. Reviewed-by: tbell ! README ! README-builds.html Changeset: 2778e6576e21 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2778e6576e21 Merge Changeset: 0adf9c626bb1 Author: katleman Date: 2013-02-28 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0adf9c626bb1 Merge Changeset: 907a926d3c96 Author: erikj Date: 2013-03-04 16:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/907a926d3c96 8004352: build-infra: Limit JOBS on large machines Reviewed-by: mduigou ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk Changeset: cd7f2c7e2a0e Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/cd7f2c7e2a0e Added tag jdk8-b80 for changeset 907a926d3c96 ! .hgtags From john.coomes at oracle.com Fri Mar 8 09:32:53 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 09:32:53 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b80 for changeset b0224010e2f0 Message-ID: <20130308093258.C079347F04@hg.openjdk.java.net> Changeset: c88bb21560cc Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/c88bb21560cc Added tag jdk8-b80 for changeset b0224010e2f0 ! .hgtags From john.coomes at oracle.com Fri Mar 8 09:33:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 09:33:14 +0000 Subject: hg: hsx/hotspot-gc/jdk: 8 new changesets Message-ID: <20130308093613.6AE1C47F07@hg.openjdk.java.net> Changeset: 5a1ea5bbe10a Author: erikj Date: 2013-02-21 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5a1ea5bbe10a 8007387: "sed: RE error: illegal byte sequence" when building images on Mac Reviewed-by: tbell ! makefiles/Images.gmk Changeset: a287f6a0d46d Author: erikj Date: 2013-02-21 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a287f6a0d46d 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: ohair, ddehaven ! make/common/Defs-macosx.gmk Changeset: 5d27f8702118 Author: erikj Date: 2013-02-21 14:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5d27f8702118 8007903: 8005583's changes to make/install-rules.gmk need to made to jdk/make/closed/InstallWrapper.gmk Reviewed-by: tbell, ohair ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk Changeset: f0b5b57014b3 Author: katleman Date: 2013-02-26 13:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f0b5b57014b3 Merge Changeset: 8d3dbb724859 Author: katleman Date: 2013-02-27 13:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8d3dbb724859 Merge Changeset: b760d5d4b8d3 Author: katleman Date: 2013-02-28 19:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b760d5d4b8d3 8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk Changeset: dfb40f066c6c Author: katleman Date: 2013-02-28 20:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dfb40f066c6c Merge Changeset: d60a95b95f01 Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d60a95b95f01 Added tag jdk8-b80 for changeset dfb40f066c6c ! .hgtags From john.coomes at oracle.com Fri Mar 8 09:38:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Mar 2013 09:38:21 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b80 for changeset a8227c617684 Message-ID: <20130308093831.5633447F08@hg.openjdk.java.net> Changeset: ed69d087fdfd Author: katleman Date: 2013-03-07 11:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ed69d087fdfd Added tag jdk8-b80 for changeset a8227c617684 ! .hgtags From erik.helin at oracle.com Fri Mar 8 09:50:48 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 08 Mar 2013 10:50:48 +0100 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <5138C5B0.3040609@oracle.com> References: <5130E68A.4040806@oracle.com> <5137889D.2080200@oracle.com> <5138C5B0.3040609@oracle.com> Message-ID: <5139B478.8080605@oracle.com> Kevin, On 03/07/2013 05:52 PM, Kevin Walls wrote: > Hi Erik - > > Yes, now you mention it I can see the route to printing the old warning > or logging the event twice... > > I don't think it's reported as a problem, or maybe it's very rare and > nobody has spotted it. It is possible to reproduce the problem with a Java program that simply allocates until OOM: import java.util.ArrayList; public class Reproducer { public static ArrayList garbage = new ArrayList(); public static void main(String[] args) { while (true) { garbage.add(new byte[1024]); } } } Compile the above Java program and then run: java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:-UseCMSCompactAtFullCollection -Xmx100m Reproducer Depending on how fast machine you have, the Java program will run for about 2 seconds and the GC logs will show (near the start of the output): [GC (Allocation Failure) [ParNew: 30720K->30720K(30720K), 0.0001940 secs][CMS[CMS-concurrent-mark: 0.035/0.036 secs] [Times: user=0.03 sys=0.00, real=0.04 secs] (concurrent mode failure) (concurrent mode failure)[YG occupancy: 30720 K (30720 K)][checkpointRootsFinalWork[Rescan (parallel) , 0.0314620 secs][refProcessingWork[weak refs processing, 0.0000320 secs][class unloading, 0.0006770 secs][scrub symbol table, 0.0009850 secs][scrub string table, 0.0000690 secs], 0.0021430 secs], 0.0339750 secs]: 50655K->50654K(68288K), 0.0972030 secs] 81375K->81374K(99008K), [Metaspace: 2662K->2662K(4486K/110592K)], 0.0980400 secs] [Times: user=0.11 sys=0.00, real=0.10 secs] Please notice the two "(concurrent mode failure)" above which are printed for the reason I explained in my previous email. On 03/07/2013 05:52 PM, Kevin Walls wrote: > But assuming it's not a "user-requested" collection, to get that false > "should_compact" in acquire_control_and_collect, we need to call > decide_foreground_collection_type(), and when it calls > incremental_collection_will_fail(), that returns false. This is assuming that the flag UseCMSCompactAtFullCollection is true. On 03/07/2013 05:52 PM, Kevin Walls wrote: > Possibly that is why we don't see the event reported twice in > practice***: if we've got to this point, and state>Idling, we are > usually here because that inc. collection would fail/is failing... This is most likely the reason, since UseCMSCompactAtFullCollection is true by default and if users aren't changing it, then your reasoning is correct. I suggest that we file a separate bug for CMS printing out "(concurrent mode failure)" twice, fix that and then we base your trace code on that. What do you think? Thanks, Erik > Thanks > Kevin > > *** if anybody really does hit this, or think it's likely, we can look > again... > > > > On 06/03/13 18:19, Erik Helin wrote: >> Hi Kevin, >> >> I think that there _might_ be a bug in CMS which was present even >> before you added the event tracing. >> >> If you look in aquire_control_and_collect, you will see that >> "should_compact" can be set to false by >> decide_foreground_collection_type. If this is the case, then we will >> end up in do_mark_sweep_work. >> >> The problem is that you have already reported, and CMS has already >> printed, that a concurrent mode failure has occurred in >> acquire_control_and_collect. Then, when you enter do_mark_sweep_work, >> you will once again report, and CMS will again print, that concurrent >> mode failure has happened. >> >> I am not 100% sure that I am right, by I believe that this can happen. >> >> What do you think? >> >> Thanks, >> Erik >> >> On 03/01/2013 06:34 PM, Kevin Walls wrote: >>> Hi, >>> >>> I'd like some reviews on this CMS Concurrent Mode Failure event: >>> >>> http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ >>> >>> The event doesn't actually carry any new information, but it is a >>> warning we need to capture. >>> >>> This is against hsx24, I'll prepare the same, or reviewed, changes >>> against very latest hotspot also. >>> >>> Thanks >>> Kevin >>> >> > From kevin.walls at oracle.com Fri Mar 8 10:08:26 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 08 Mar 2013 10:08:26 +0000 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <5139B478.8080605@oracle.com> References: <5130E68A.4040806@oracle.com> <5137889D.2080200@oracle.com> <5138C5B0.3040609@oracle.com> <5139B478.8080605@oracle.com> Message-ID: <5139B89A.8000304@oracle.com> Hi Erik - aha yes, so not that rare then for the right kind of program! I'll talk to you about when/how to do this and the new event. Thanks Kevin On 08/03/13 09:50, Erik Helin wrote: > Kevin, > > On 03/07/2013 05:52 PM, Kevin Walls wrote: >> Hi Erik - >> >> Yes, now you mention it I can see the route to printing the old warning >> or logging the event twice... >> >> I don't think it's reported as a problem, or maybe it's very rare and >> nobody has spotted it. > > It is possible to reproduce the problem with a Java program that > simply allocates until OOM: > > import java.util.ArrayList; > > public class Reproducer { > public static ArrayList garbage = new ArrayList(); > public static void main(String[] args) { > while (true) { > garbage.add(new byte[1024]); > } > } > } > > Compile the above Java program and then run: > > java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails > -XX:-UseCMSCompactAtFullCollection -Xmx100m Reproducer > > Depending on how fast machine you have, the Java program will run for > about 2 seconds and the GC logs will show (near the start of the output): > > [GC (Allocation Failure) [ParNew: 30720K->30720K(30720K), 0.0001940 > secs][CMS[CMS-concurrent-mark: 0.035/0.036 secs] [Times: user=0.03 > sys=0.00, real=0.04 secs] > (concurrent mode failure) (concurrent mode failure)[YG occupancy: > 30720 K (30720 K)][checkpointRootsFinalWork[Rescan (parallel) , > 0.0314620 secs][refProcessingWork[weak refs processing, 0.0000320 > secs][class unloading, 0.0006770 secs][scrub symbol table, 0.0009850 > secs][scrub string table, 0.0000690 secs], 0.0021430 secs], 0.0339750 > secs]: 50655K->50654K(68288K), 0.0972030 secs] 81375K->81374K(99008K), > [Metaspace: 2662K->2662K(4486K/110592K)], 0.0980400 secs] [Times: > user=0.11 sys=0.00, real=0.10 secs] > > Please notice the two "(concurrent mode failure)" above which are > printed for the reason I explained in my previous email. > > On 03/07/2013 05:52 PM, Kevin Walls wrote: >> But assuming it's not a "user-requested" collection, to get that false >> "should_compact" in acquire_control_and_collect, we need to call >> decide_foreground_collection_type(), and when it calls >> incremental_collection_will_fail(), that returns false. > > This is assuming that the flag UseCMSCompactAtFullCollection is true. > > On 03/07/2013 05:52 PM, Kevin Walls wrote: >> Possibly that is why we don't see the event reported twice in >> practice***: if we've got to this point, and state>Idling, we are >> usually here because that inc. collection would fail/is failing... > > This is most likely the reason, since UseCMSCompactAtFullCollection is > true by default and if users aren't changing it, then your reasoning > is correct. > > I suggest that we file a separate bug for CMS printing out > "(concurrent mode failure)" twice, fix that and then we base your > trace code on that. > > What do you think? > > Thanks, > Erik > >> Thanks >> Kevin >> >> *** if anybody really does hit this, or think it's likely, we can look >> again... >> >> >> >> On 06/03/13 18:19, Erik Helin wrote: >>> Hi Kevin, >>> >>> I think that there _might_ be a bug in CMS which was present even >>> before you added the event tracing. >>> >>> If you look in aquire_control_and_collect, you will see that >>> "should_compact" can be set to false by >>> decide_foreground_collection_type. If this is the case, then we will >>> end up in do_mark_sweep_work. >>> >>> The problem is that you have already reported, and CMS has already >>> printed, that a concurrent mode failure has occurred in >>> acquire_control_and_collect. Then, when you enter do_mark_sweep_work, >>> you will once again report, and CMS will again print, that concurrent >>> mode failure has happened. >>> >>> I am not 100% sure that I am right, by I believe that this can happen. >>> >>> What do you think? >>> >>> Thanks, >>> Erik >>> >>> On 03/01/2013 06:34 PM, Kevin Walls wrote: >>>> Hi, >>>> >>>> I'd like some reviews on this CMS Concurrent Mode Failure event: >>>> >>>> http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ >>>> >>>> The event doesn't actually carry any new information, but it is a >>>> warning we need to capture. >>>> >>>> This is against hsx24, I'll prepare the same, or reviewed, changes >>>> against very latest hotspot also. >>>> >>>> Thanks >>>> Kevin >>>> >>> >> > From jon.masamitsu at oracle.com Fri Mar 8 11:01:42 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 08 Mar 2013 11:01:42 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8008368: Deprecate MaxGCMinorPauseMillis Message-ID: <20130308110149.1DF4C48004@hg.openjdk.java.net> Changeset: 209f8ba5020b Author: tamao Date: 2013-03-07 10:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/209f8ba5020b 8008368: Deprecate MaxGCMinorPauseMillis Summary: Deprecate MaxGCMinorPauseMillis and emit a warning if set by users Reviewed-by: brutisso, johnc Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp From erik.helin at oracle.com Fri Mar 8 12:36:35 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 08 Mar 2013 13:36:35 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <513706E1.2070605@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> Message-ID: <5139DB53.3030001@oracle.com> Bengt and Staffan, thanks for he feedback! I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ Thanks, Erik On 03/06/2013 10:05 AM, Bengt Rutisson wrote: > > Erik and Staffan, > > The ProcessTools class has the method getPlatformSpecificVMArgs() that > returns "-d64" if necessary. You can't use this as is since you need to > get "J-d64" but I think we should do something to make your solution > more general. > > Either adding a possible prefix to the getPlatformSpecificVMArgs() or > adding a separate method that returns "JDK-tools formatted" args. It > seems a bit too limited to fix this only for your particular test. Would > be nice to get it in to the testlibrary somehow. > > Bengt > > > On 3/5/13 5:55 PM, Staffan Larsen wrote: >> Looks good. I wish we could abstract this away so that not every test >> needs to do this work. >> >> /Staffan (mobile) >> >> On 5 mar 2013, at 17:39, Erik Helin wrote: >> >>> Hi all, >>> >>> this change adds the option "-J-d64" or "-J-d32" (depending on arch) >>> when running jmap in the test >>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>> >>> Thanks, >>> Erik > From bengt.rutisson at oracle.com Fri Mar 8 13:20:04 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 08 Mar 2013 14:20:04 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Message-ID: <5139E584.1050205@oracle.com> Hi all, Could I have a couple of reviews for this change please? http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ I'm sending this to both the GC and the runtime teams since I think compressed oops is mixed responsibility for both teams. Background (mostly from the bug report): Hotspot crashes if it is run with a large initial size: >./java -Xms70g -version # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, tid=140305232803584 The reason is that we enable UseCompressedOops but we use the default value for ObjectAlignmentInBytes. With a large heap size we would have needed to adjust the object alignment to be able to use compressed oops. However, after reviewing the code it looks like the fix is not to try to adjust the object alignment but rather to not enable compressed oops for large heaps. If someone wants to use compressed oops on a very large heap they need to explicitly set both UseCompressedOops and ObjectAlignmentInBytes on the command line. As far as I can tell this is how it is intended to work. Here is the reason for the crash and the rational behind the fix: In Arguments::set_ergonomics_flags() we check that the max heap size is small enough before we enable compressed oops: if (MaxHeapSize <= max_heap_for_compressed_oops()) { #if !defined(COMPILER1) || defined(TIERED) if (FLAG_IS_DEFAULT(UseCompressedOops)) { FLAG_SET_ERGO(bool, UseCompressedOops, true); } #endif And after that we print a warning message if the heap is too large: if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { warning("Max heap size too large for Compressed Oops"); FLAG_SET_DEFAULT(UseCompressedOops, false); FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); } Now the problem is that when we don't set the max heap size on the command line it will be adjusted based on the initial size (-Xms) and this happens in Arguments::set_heap_size(), which is called *after* Arguments::set_ergonomics_flags() has been called. So, when we do the check against the max size in Arguments::set_ergonomics_flags(), we check against the default value for the max size. This value fits well with a compressed heap, so we enable compressed oops and crash later on when we can't address the upper part of the heap. The fix is to move the call to set_heap_size() to *before* the call to set_ergonomics_flags(). This way the check is done against the correct value. This has two effects: 1) We don't enable UseCompressedOops on heap sizes that are too large 2) If someone sets -XX:+UseCompressedOops on the command line but specifies a too large heap a warning message will be logged and UseCompressedOops will be turned off. I am always hesitant to rearrange the order of calls in Arguments::parse(). But in this case it is necessary to get the correct behavior and I think it is safe. As far as I can tell there is no other code between the two methods that try to read the MaxHeapSize value. Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Mar 8 16:17:27 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Mar 2013 08:17:27 -0800 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <5139E584.1050205@oracle.com> References: <5139E584.1050205@oracle.com> Message-ID: <513A0F17.5040100@oracle.com> The change is reasonable. So why we did not see this problem before? Thanks, Vladimir On 3/8/13 5:20 AM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this change please? > http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ > > I'm sending this to both the GC and the runtime teams since I think > compressed oops is mixed responsibility for both teams. > > Background (mostly from the bug report): > > Hotspot crashes if it is run with a large initial size: > > >./java -Xms70g -version > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, tid=140305232803584 > > The reason is that we enable UseCompressedOops but we use the default > value for ObjectAlignmentInBytes. With a large heap size we would have > needed to adjust the object alignment to be able to use compressed oops. > > However, after reviewing the code it looks like the fix is not to try to > adjust the object alignment but rather to not enable compressed oops for > large heaps. If someone wants to use compressed oops on a very large > heap they need to explicitly set both UseCompressedOops and > ObjectAlignmentInBytes on the command line. As far as I can tell this is > how it is intended to work. > > Here is the reason for the crash and the rational behind the fix: > > In Arguments::set_ergonomics_flags() we check that the max heap size is > small enough before we enable compressed oops: > > if (MaxHeapSize <= max_heap_for_compressed_oops()) { > #if !defined(COMPILER1) || defined(TIERED) > if (FLAG_IS_DEFAULT(UseCompressedOops)) { > FLAG_SET_ERGO(bool, UseCompressedOops, true); > } > #endif > > And after that we print a warning message if the heap is too large: > > if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { > warning("Max heap size too large for Compressed Oops"); > FLAG_SET_DEFAULT(UseCompressedOops, false); > FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); > } > > Now the problem is that when we don't set the max heap size on the > command line it will be adjusted based on the initial size (-Xms) and > this happens in Arguments::set_heap_size(), which is called *after* > Arguments::set_ergonomics_flags() has been called. So, when we do the > check against the max size in Arguments::set_ergonomics_flags(), we > check against the default value for the max size. This value fits well > with a compressed heap, so we enable compressed oops and crash later on > when we can't address the upper part of the heap. > > The fix is to move the call to set_heap_size() to *before* the call to > set_ergonomics_flags(). This way the check is done against the correct > value. This has two effects: > > 1) We don't enable UseCompressedOops on heap sizes that are too large > 2) If someone sets -XX:+UseCompressedOops on the command line but > specifies a too large heap a warning message will be logged and > UseCompressedOops will be turned off. > > I am always hesitant to rearrange the order of calls in > Arguments::parse(). But in this case it is necessary to get the correct > behavior and I think it is safe. As far as I can tell there is no other > code between the two methods that try to read the MaxHeapSize value. > > Thanks, > Bengt From vladimir.kozlov at oracle.com Fri Mar 8 18:09:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Mar 2013 10:09:01 -0800 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513A22E2.1060904@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> Message-ID: <513A293D.8020702@oracle.com> I am wondering should we also add a check into Universe::reserve_heap() before calling Universe::preferred_heap_base(). Vladimir On 3/8/13 9:41 AM, harold seigel wrote: > The change looks good. Perhaps this problem wasn't seen before because > this scenario hadn't been tested? > > Harold > > On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >> The change is reasonable. >> >> So why we did not see this problem before? >> >> Thanks, >> Vladimir >> >> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this change please? >>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>> >>> I'm sending this to both the GC and the runtime teams since I think >>> compressed oops is mixed responsibility for both teams. >>> >>> Background (mostly from the bug report): >>> >>> Hotspot crashes if it is run with a large initial size: >>> >>> >./java -Xms70g -version >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, tid=140305232803584 >>> >>> The reason is that we enable UseCompressedOops but we use the default >>> value for ObjectAlignmentInBytes. With a large heap size we would have >>> needed to adjust the object alignment to be able to use compressed oops. >>> >>> However, after reviewing the code it looks like the fix is not to try to >>> adjust the object alignment but rather to not enable compressed oops for >>> large heaps. If someone wants to use compressed oops on a very large >>> heap they need to explicitly set both UseCompressedOops and >>> ObjectAlignmentInBytes on the command line. As far as I can tell this is >>> how it is intended to work. >>> >>> Here is the reason for the crash and the rational behind the fix: >>> >>> In Arguments::set_ergonomics_flags() we check that the max heap size is >>> small enough before we enable compressed oops: >>> >>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>> #if !defined(COMPILER1) || defined(TIERED) >>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>> } >>> #endif >>> >>> And after that we print a warning message if the heap is too large: >>> >>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>> warning("Max heap size too large for Compressed Oops"); >>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>> } >>> >>> Now the problem is that when we don't set the max heap size on the >>> command line it will be adjusted based on the initial size (-Xms) and >>> this happens in Arguments::set_heap_size(), which is called *after* >>> Arguments::set_ergonomics_flags() has been called. So, when we do the >>> check against the max size in Arguments::set_ergonomics_flags(), we >>> check against the default value for the max size. This value fits well >>> with a compressed heap, so we enable compressed oops and crash later on >>> when we can't address the upper part of the heap. >>> >>> The fix is to move the call to set_heap_size() to *before* the call to >>> set_ergonomics_flags(). This way the check is done against the correct >>> value. This has two effects: >>> >>> 1) We don't enable UseCompressedOops on heap sizes that are too large >>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>> specifies a too large heap a warning message will be logged and >>> UseCompressedOops will be turned off. >>> >>> I am always hesitant to rearrange the order of calls in >>> Arguments::parse(). But in this case it is necessary to get the correct >>> behavior and I think it is safe. As far as I can tell there is no other >>> code between the two methods that try to read the MaxHeapSize value. >>> >>> Thanks, >>> Bengt > From staffan.larsen at oracle.com Fri Mar 8 12:34:35 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 8 Mar 2013 13:34:35 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <5139DB53.3030001@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> Message-ID: <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> Looks good to me. /Staffan On 8 mar 2013, at 13:36, Erik Helin wrote: > Bengt and Staffan, > > thanks for he feedback! > > I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. > > I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ > > Thanks, > Erik > > On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >> >> Erik and Staffan, >> >> The ProcessTools class has the method getPlatformSpecificVMArgs() that >> returns "-d64" if necessary. You can't use this as is since you need to >> get "J-d64" but I think we should do something to make your solution >> more general. >> >> Either adding a possible prefix to the getPlatformSpecificVMArgs() or >> adding a separate method that returns "JDK-tools formatted" args. It >> seems a bit too limited to fix this only for your particular test. Would >> be nice to get it in to the testlibrary somehow. >> >> Bengt >> >> >> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>> Looks good. I wish we could abstract this away so that not every test >>> needs to do this work. >>> >>> /Staffan (mobile) >>> >>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>> >>>> Hi all, >>>> >>>> this change adds the option "-J-d64" or "-J-d32" (depending on arch) >>>> when running jmap in the test >>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>> >>>> Thanks, >>>> Erik >> > From jon.masamitsu at oracle.com Fri Mar 8 19:05:34 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 08 Mar 2013 11:05:34 -0800 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <5139E584.1050205@oracle.com> References: <5139E584.1050205@oracle.com> Message-ID: <513A367E.2000505@oracle.com> Bengt, With your change the order is set_heap_size() set_ergonomics_flags() set_ergonomics_flags() can turn on UseCompressedOops. set_heap_size() uses UseCompressedOops Right? It might not be a problem today but it makes me nervous. Is there a real circularity there? I don't know but if there is a way to exclude a circularity, then I won't have to think about it. Jon On 3/8/2013 5:20 AM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this change please? > http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ > > I'm sending this to both the GC and the runtime teams since I think > compressed oops is mixed responsibility for both teams. > > Background (mostly from the bug report): > > Hotspot crashes if it is run with a large initial size: > > >./java -Xms70g -version > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, tid=140305232803584 > > The reason is that we enable UseCompressedOops but we use the default > value for ObjectAlignmentInBytes. With a large heap size we would have > needed to adjust the object alignment to be able to use compressed oops. > > However, after reviewing the code it looks like the fix is not to try > to adjust the object alignment but rather to not enable compressed > oops for large heaps. If someone wants to use compressed oops on a > very large heap they need to explicitly set both UseCompressedOops and > ObjectAlignmentInBytes on the command line. As far as I can tell this > is how it is intended to work. > > Here is the reason for the crash and the rational behind the fix: > > In Arguments::set_ergonomics_flags() we check that the max heap size > is small enough before we enable compressed oops: > > if (MaxHeapSize <= max_heap_for_compressed_oops()) { > #if !defined(COMPILER1) || defined(TIERED) > if (FLAG_IS_DEFAULT(UseCompressedOops)) { > FLAG_SET_ERGO(bool, UseCompressedOops, true); > } > #endif > > And after that we print a warning message if the heap is too large: > > if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { > warning("Max heap size too large for Compressed Oops"); > FLAG_SET_DEFAULT(UseCompressedOops, false); > FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); > } > > Now the problem is that when we don't set the max heap size on the > command line it will be adjusted based on the initial size (-Xms) and > this happens in Arguments::set_heap_size(), which is called *after* > Arguments::set_ergonomics_flags() has been called. So, when we do the > check against the max size in Arguments::set_ergonomics_flags(), we > check against the default value for the max size. This value fits well > with a compressed heap, so we enable compressed oops and crash later > on when we can't address the upper part of the heap. > > The fix is to move the call to set_heap_size() to *before* the call to > set_ergonomics_flags(). This way the check is done against the correct > value. This has two effects: > > 1) We don't enable UseCompressedOops on heap sizes that are too large > 2) If someone sets -XX:+UseCompressedOops on the command line but > specifies a too large heap a warning message will be logged and > UseCompressedOops will be turned off. > > I am always hesitant to rearrange the order of calls in > Arguments::parse(). But in this case it is necessary to get the > correct behavior and I think it is safe. As far as I can tell there is > no other code between the two methods that try to read the MaxHeapSize > value. > > Thanks, > Bengt > From kevin.walls at oracle.com Fri Mar 8 23:39:56 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 08 Mar 2013 23:39:56 +0000 Subject: RFR: 8009723 CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Message-ID: <513A76CC.50806@oracle.com> Hi, This is a review request for a small change: http://cr.openjdk.java.net/~kevinw/8009723/webrev/ Using CMS and disabling UseCMSCompactAtFullCollection on the command line easily produces a double-logging of the "(concurrent mode failure)" message. This was spotted by Erik Helin. This is like removing a print statement. The webrev contains a testcase, but I am currently suggesting I commit this without the test as: 1) it's fairly trivial: remove a print statement, you don't the see output of that print statement. 2) it requires -XX:-UseCMSCompactAtFullCollection which I don't believe is commonly used 3) it is a CMS-specific and the current test framework is quite awkward to make the test specific (manual work in the java test, or re-exec. If re-execing do we ignore TESTVMOPTS or parse it and add UseConcMarkSweepGC?... a few issues there we should solve but this may not be the test change that needs that...) So the test is possible, and useful for verifying it if anybody wants to run it right now, but does not seem a necessity and for this small change adding to the test harness library to make it more elegant seems unnecessary for this minor problem... Thanks Kevin From stefan.karlsson at oracle.com Mon Mar 11 10:04:02 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Mar 2013 11:04:02 +0100 Subject: Review request: 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Message-ID: <513DAC12.4050801@oracle.com> http://cr.openjdk.java.net/~stefank/8004697/webrev.00/ The JVM crashes because it accidentally frees memory in the survivor regions, at one point where it is supposed to only free freeing memory in the eden. The code in os::scan_pages(start, end, ...) in solaris_os.cpp looks at pages starting beyond 'end'. This causes MutableNUMASpace::LGRPSpace::scan_pages to free memory outside eden, when the last page starts in, but ends outside of eden. Testing: The JVM used to crash within in a couple of minutes. With the patch, the test has been running over the weekend without any crashes. thanks, StefanK From mikael.gerdin at oracle.com Mon Mar 11 10:11:58 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 11 Mar 2013 11:11:58 +0100 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <5138FF3A.6070902@oracle.com> References: <513855CC.5030009@oracle.com> <5138FF3A.6070902@oracle.com> Message-ID: <513DADEE.4040302@oracle.com> Jon, On 2013-03-07 21:57, Jon Masamitsu wrote: > > > On 03/07/13 00:54, Mikael Gerdin wrote: >> Hi >> >> >> When deciding when to reserve more metaspace memory we erroneously >> looked only at the "capacity" of the metaspace insted of the reserved >> space (which is what we ask this function when expanding). > > Using MetaspaceAux::reserved_in_bytes() means that we > could return false here > > 1105 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)&& > 1106 MetaspaceAux::reserved_in_bytes()>= MaxMetaspaceSize) { > 1107 return false; > 1108 } > > when most of the space reserved in one or two VirtualSpace's is unused. > With the current value of parameters, that could almost be 512kb. Yes. I guess the question is: Should MaxMetaspaceSize limit the amount of virtual address space reserved for metaspaces or should it limit the amount of committed pages? To be consistent with how the Java heap is handled my opinion is that we should limit the amount of reserved memory. I any case the current version is incorrect since MetaspaceGC::should_expand was queried to determine if we should reserve more virtual address space or not and the size check was against the amount of committed memory. /Mikael > > Jon > >> >> Additionally, we didn't check MaxMetaspaceSize against the sum of >> reserved(Class) + reserved(NonClass) which caused us to use more than >> MaxMetaspaceSize even when it was set. >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >> (not yet available at the time of writing this mail) >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >> >> Testing: >> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >> path. From jesper.wilhelmsson at oracle.com Mon Mar 11 11:02:01 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 11 Mar 2013 12:02:01 +0100 Subject: RFR: 8009723 CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection In-Reply-To: <513A76CC.50806@oracle.com> References: <513A76CC.50806@oracle.com> Message-ID: <513DB9A9.20101@oracle.com> Looks good! I agree with not adding the test. /Jesper On 9/3/13 12:39 AM, Kevin Walls wrote: > Hi, > > This is a review request for a small change: > > http://cr.openjdk.java.net/~kevinw/8009723/webrev/ > > Using CMS and disabling UseCMSCompactAtFullCollection on the command line easily > produces a double-logging of the "(concurrent mode failure)" message. This was > spotted by Erik Helin. > > This is like removing a print statement. > > The webrev contains a testcase, but I am currently suggesting I commit this > without the test as: > > 1) it's fairly trivial: remove a print statement, you don't the see output of > that print statement. > 2) it requires -XX:-UseCMSCompactAtFullCollection which I don't believe is > commonly used > 3) it is a CMS-specific and the current test framework is quite awkward to make > the test specific (manual work in the java test, or re-exec. If re-execing do > we ignore TESTVMOPTS or parse it and add UseConcMarkSweepGC?... a few issues > there we should solve but this may not be the test change that needs that...) > > So the test is possible, and useful for verifying it if anybody wants to run it > right now, but does not seem a necessity and for this small change adding to the > test harness library to make it more elegant seems unnecessary for this minor > problem... > > Thanks > Kevin > From jesper.wilhelmsson at oracle.com Mon Mar 11 11:33:42 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 11 Mar 2013 12:33:42 +0100 Subject: Review request: 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA In-Reply-To: <513DAC12.4050801@oracle.com> References: <513DAC12.4050801@oracle.com> Message-ID: <513DC116.4080801@oracle.com> The change looks good. I especially like the assert :-) Ship it! /Jesper On 11/3/13 11:04 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8004697/webrev.00/ > > The JVM crashes because it accidentally frees memory in the survivor regions, at > one point where it is supposed to only free freeing memory in the eden. > > The code in os::scan_pages(start, end, ...) in solaris_os.cpp looks at pages > starting beyond 'end'. This causes MutableNUMASpace::LGRPSpace::scan_pages to > free memory outside eden, when the last page starts in, but ends outside of eden. > > Testing: The JVM used to crash within in a couple of minutes. With the patch, > the test has been running over the weekend without any crashes. > > thanks, > StefanK From bengt.rutisson at oracle.com Mon Mar 11 11:40:16 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 11 Mar 2013 12:40:16 +0100 Subject: RFR: 8009723 CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection In-Reply-To: <513A76CC.50806@oracle.com> References: <513A76CC.50806@oracle.com> Message-ID: <513DC2A0.3060209@oracle.com> Hi Kevin, Looks good! I'm fine with pushing this without the test, but I kind of think it is better to include the test. If we have a taken the time to write a test I think it is a good idea to include it. We really need the test framework to allow us to specify how the tests can be run to not waste resources. So, I think 3) below is something we are always running in to and need fixed. Thus, I don't think that should stop us from adding tests. If you decide to include the test I would like to review it more closely. One thing is that I think it might be simpler to write the test using the testlibrary rather than implementing your own process support. Bengt On 3/9/13 12:39 AM, Kevin Walls wrote: > Hi, > > This is a review request for a small change: > > http://cr.openjdk.java.net/~kevinw/8009723/webrev/ > > Using CMS and disabling UseCMSCompactAtFullCollection on the command > line easily produces a double-logging of the "(concurrent mode > failure)" message. This was spotted by Erik Helin. > > This is like removing a print statement. > > The webrev contains a testcase, but I am currently suggesting I commit > this without the test as: > > 1) it's fairly trivial: remove a print statement, you don't the see > output of that print statement. > 2) it requires -XX:-UseCMSCompactAtFullCollection which I don't > believe is commonly used > 3) it is a CMS-specific and the current test framework is quite > awkward to make the test specific (manual work in the java test, or > re-exec. If re-execing do we ignore TESTVMOPTS or parse it and add > UseConcMarkSweepGC?... a few issues there we should solve but this may > not be the test change that needs that...) > > So the test is possible, and useful for verifying it if anybody wants > to run it right now, but does not seem a necessity and for this small > change adding to the test harness library to make it more elegant > seems unnecessary for this minor problem... > > Thanks > Kevin > From stefan.karlsson at oracle.com Mon Mar 11 12:02:40 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 11 Mar 2013 12:02:40 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 32 new changesets Message-ID: <20130311120351.7F5F948061@hg.openjdk.java.net> Changeset: 1f9994892f89 Author: stefank Date: 2013-02-21 17:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1f9994892f89 8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive Summary: SystemDictionary::find(...) should not create and register ClassLoaderData objects for class loaders. Reviewed-by: coleenp, acorn Contributed-by: Stefan Karlsson , Erik Helin ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3c9db54c2660 Author: mikael Date: 2013-02-26 08:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c9db54c2660 8008081: Print outs do not have matching arguments Summary: Corrected formatted prints to have matching arguments, removed dead print_frame_layout function Reviewed-by: sla, dholmes ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/services/memReporter.cpp ! src/share/vm/utilities/numberSeq.cpp Changeset: 05f2fc6b4ea7 Author: dholmes Date: 2013-02-27 04:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/05f2fc6b4ea7 Merge Changeset: 96bd4772ec62 Author: kevinw Date: 2013-02-27 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/96bd4772ec62 8008807: SA: jstack crash when target has mismatched bitness (Linux) Reviewed-by: rbackman, sla, poonam ! agent/src/os/linux/LinuxDebuggerLocal.c Changeset: 698b615a1cde Author: kevinw Date: 2013-02-27 16:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/698b615a1cde Merge Changeset: 651919d134f7 Author: kevinw Date: 2013-02-27 22:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/651919d134f7 7178741: SA: jstack -m produce UnalignedAddressException in output (Linux) Reviewed-by: poonam, sla ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java Changeset: 5ee250974db9 Author: dcubed Date: 2013-02-27 15:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5ee250974db9 8007476: assert(the_owner != NULL) failed: Did not find owning Java thread for lock word address Summary: Make deadlock detection a little more robust in the case of being unable to find the JavaThread associated with an object lock. Reviewed-by: sla, acorn ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/threadService.cpp Changeset: a140cd925462 Author: dcubed Date: 2013-02-28 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a140cd925462 Merge Changeset: 63e54c37ac64 Author: simonis Date: 2013-02-27 09:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/63e54c37ac64 8008959: Fix non-PCH build on Linux, Windows and MacOS X Summary: Fix the build without precompiled headers by either including the missing ".inline.hpp" files into the appropriate files or by turning inline-functions declared in header files into ordinary functions in ".cpp" files. Reviewed-by: coleenp, stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp Changeset: a506ac816f14 Author: coleenp Date: 2013-02-27 07:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a506ac816f14 Merge Changeset: 143973ced9ab Author: coleenp Date: 2013-02-28 18:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/143973ced9ab Merge Changeset: 3e83d69c19db Author: dcubed Date: 2013-03-01 15:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3e83d69c19db Merge Changeset: c71e15057f1d Author: stefank Date: 2013-03-07 14:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c71e15057f1d Merge Changeset: 7369298bec7e Author: collins Date: 2013-02-27 20:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7369298bec7e 7115383: TEST_BUG: some jtreg tests fail because they explicitly specify -server option Summary: Small changes to hotspot tests to remove "-server" and replace with ${TESTVMOPTS} Reviewed-by: kvn ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6946040/TestCharShortByteSwap.java ! test/compiler/7068051/Test7068051.sh ! test/compiler/8000805/Test8000805.java Changeset: 5cf033ff06c4 Author: bpittore Date: 2013-03-01 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5cf033ff06c4 Merge Changeset: af5ac43f06e9 Author: jprovino Date: 2013-03-07 10:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/af5ac43f06e9 Merge Changeset: 0b8f9c8d2617 Author: jiangli Date: 2013-03-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0b8f9c8d2617 Merge Changeset: 40b7c6b800ab Author: morris Date: 2013-03-01 14:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/40b7c6b800ab 8008327: [parfait] Unitialized variable in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m Summary: Fix unitialized variable and return value. Reviewed-by: kvn ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: bf06968a8a00 Author: morris Date: 2013-03-04 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf06968a8a00 8008559: [parfait] Path through non-void function '_ZN2os15thread_cpu_timeEP6Thread' returns an undefined value Summary: safety checks for non-Apple thread time functions Reviewed-by: kvn ! src/os/bsd/vm/os_bsd.cpp Changeset: c40fbf634c90 Author: morris Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c40fbf634c90 8008574: [parfait] Null pointer deference in hotspot/src/share/vm/runtime/frame.cpp Summary: fix null pointer Reviewed-by: kvn ! src/share/vm/runtime/frame.cpp Changeset: 571076d3c79d Author: shade Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/571076d3c79d 8009120: Fuzz instruction scheduling in HotSpot compilers Reviewed-by: kvn, vlivanov ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 4f553e24b3b5 Author: vlivanov Date: 2013-03-05 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4f553e24b3b5 Merge Changeset: 872b3feace55 Author: morris Date: 2013-03-05 18:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/872b3feace55 8008750: [partfait] Null pointer deference in hotspot/src/share/vm/oops/instanceKlass.hpp Summary: fix null pointer Reviewed-by: kvn, coleenp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 8651f608fea4 Author: roland Date: 2013-03-06 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8651f608fea4 8009460: C2compiler crash in machnode::in_regmask(unsigned int) Summary: 7121140 may not correctly break the Allocate -> MemBarStoreStore link Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: ff55877839bc Author: kvn Date: 2013-03-06 12:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ff55877839bc 8009472: Print additional information for 8004640 failure Summary: dump nodes and types in 8004640 case. Reviewed-by: roland ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp Changeset: bdb602473679 Author: morris Date: 2013-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bdb602473679 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: b5bd25d55994 Author: morris Date: 2013-03-07 18:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b5bd25d55994 Merge Changeset: fbda7e1dee9a Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fbda7e1dee9a Added tag jdk8-b80 for changeset 4a198b201f3c ! .hgtags Changeset: dd6350b4abc4 Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dd6350b4abc4 Merge Changeset: 65b797426a3b Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/65b797426a3b Added tag hs25-b22 for changeset dd6350b4abc4 ! .hgtags Changeset: 8196357e95b5 Author: amurillo Date: 2013-03-08 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8196357e95b5 8009688: new hotspot build - hs25-b23 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1f3354851c91 Author: stefank Date: 2013-03-11 08:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1f3354851c91 Merge From erik.helin at oracle.com Mon Mar 11 12:13:53 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 11 Mar 2013 13:13:53 +0100 Subject: RFR: 8009723 CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection In-Reply-To: <513A76CC.50806@oracle.com> References: <513A76CC.50806@oracle.com> Message-ID: <513DCA81.6060507@oracle.com> Kevin, On 03/09/2013 12:39 AM, Kevin Walls wrote: > Hi, > > This is a review request for a small change: > > http://cr.openjdk.java.net/~kevinw/8009723/webrev/ > > Using CMS and disabling UseCMSCompactAtFullCollection on the command > line easily produces a double-logging of the "(concurrent mode failure)" > message. This was spotted by Erik Helin. > > This is like removing a print statement. The change looks good, thanks for fixing this! On 03/09/2013 12:39 AM, Kevin Walls wrote: > The webrev contains a testcase, but I am currently suggesting I commit > this without the test as: > > 1) it's fairly trivial: remove a print statement, you don't the see > output of that print statement. > 2) it requires -XX:-UseCMSCompactAtFullCollection which I don't believe > is commonly used > 3) it is a CMS-specific and the current test framework is quite awkward > to make the test specific (manual work in the java test, or re-exec. If > re-execing do we ignore TESTVMOPTS or parse it and add > UseConcMarkSweepGC?... a few issues there we should solve but this may > not be the test change that needs that...) > > So the test is possible, and useful for verifying it if anybody wants to > run it right now, but does not seem a necessity and for this small > change adding to the test harness library to make it more elegant seems > unnecessary for this minor problem... I've looked at the tests and I think it looks good. Is there a way, besides removing things from TESTVMOPTS, that you can make sure that the test only runs using only the flags you want? It is fine with me if you want to push the change first and push an updated test later. Thanks, Erik > Thanks > Kevin > From kevin.walls at oracle.com Mon Mar 11 12:54:14 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 11 Mar 2013 12:54:14 +0000 Subject: RFR: 8009723 CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection In-Reply-To: <513DB9A9.20101@oracle.com> References: <513A76CC.50806@oracle.com> <513DB9A9.20101@oracle.com> Message-ID: <513DD3F6.2060406@oracle.com> Thanks Jesper, Erik, Bengt, I'll go ahead with this now so I can then come back with a refreshed webrev for the CMS Concurrent Mode Failure event (8008917). Thanks Kevin #On 11/03/13 11:02, Jesper Wilhelmsson wrote: > Looks good! > I agree with not adding the test. > /Jesper > > On 9/3/13 12:39 AM, Kevin Walls wrote: >> Hi, >> >> This is a review request for a small change: >> >> http://cr.openjdk.java.net/~kevinw/8009723/webrev/ >> >> Using CMS and disabling UseCMSCompactAtFullCollection on the command >> line easily >> produces a double-logging of the "(concurrent mode failure)" >> message. This was >> spotted by Erik Helin. >> >> This is like removing a print statement. >> >> The webrev contains a testcase, but I am currently suggesting I >> commit this >> without the test as: >> >> 1) it's fairly trivial: remove a print statement, you don't the see >> output of >> that print statement. >> 2) it requires -XX:-UseCMSCompactAtFullCollection which I don't >> believe is >> commonly used >> 3) it is a CMS-specific and the current test framework is quite >> awkward to make >> the test specific (manual work in the java test, or re-exec. If >> re-execing do >> we ignore TESTVMOPTS or parse it and add UseConcMarkSweepGC?... a few >> issues >> there we should solve but this may not be the test change that needs >> that...) >> >> So the test is possible, and useful for verifying it if anybody wants >> to run it >> right now, but does not seem a necessity and for this small change >> adding to the >> test harness library to make it more elegant seems unnecessary for >> this minor >> problem... >> >> Thanks >> Kevin >> From mikael.gerdin at oracle.com Mon Mar 11 13:08:01 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 11 Mar 2013 14:08:01 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <5134B367.8020708@oracle.com> References: <5134B367.8020708@oracle.com> Message-ID: <513DD731.7050707@oracle.com> Anyone? On 2013-03-04 15:44, Mikael Gerdin wrote: > Hi all, > > Please review this change to enable CMS to hand back memory for unloaded > classes when running in concurrent mode. > > Bug link: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 > Webrev: > http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ > > > The core change in this patch is the inserted call in sweep(): > 6101 > 6102 if (should_unload_classes()) { > 6103 ClassLoaderDataGraph::purge(); > 6104 } > 6105 > > This is needed because even though we claim to perform "class unloading" > in the final remark phase we can't deallocate the memory for classes > until after we've performed the sweep phase since the sweeper needs to > find the size of objects even though they and their class is not > considered live anymore. > > The rest of the changes in concurrentMarkSweepGeneration.cpp only relate > to logging information about released metaspace memory and cms gen > occupancy to make it easier to analyze what's happening. An example of > this new logging output is: > > 134.069: [CMS-concurrent-sweep-start] > 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 > sys=0.02, real=0.01 secs] > 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: > 277487K->133228K(370885K/412976K)] ] > 134.166: [CMS-concurrent-reset-start] > 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 > sys=0.00, real=0.02 secs] > > The change in genCollectedHeap.cpp is needed to avoid artificially > inflating the size of the Metaspace memory, since memory is considered > "used" until purge() has been called. By calling purge() before > compute_new_size() (as the other collectors do) we use the correct figures. > > The disabled assert in metaspace.cpp is faulty because a thread may be > allocating classes and expanding the metaspace memory while we are in > compute_new_size, I've verified that this assert can in fact fail on a > build without these changes. > The change in ~SpaceManager is because of lock order restrictions, > sum_capacity_in_chunks_in_use takes the Metaspace lock and would do it > out of order with regards to the expand_lock. > > I've tested these changes primarily by running the ParallelClassLoading > tests with a small young gen size to enable regular class unloading cycles. > > Thanks > /Mikael From mikael.gerdin at oracle.com Mon Mar 11 13:12:31 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 11 Mar 2013 14:12:31 +0100 Subject: Review request (XS): JDK-8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Message-ID: <513DD83F.6000807@oracle.com> Hi, Please review this small fix for an incorrect assert that can trigger when we run out of metaspace memory. Webrev: http://cr.openjdk.java.net/~mgerdin/8009282/webrev.0/ The reasoning behind this change is that when running with the command line flags specified in the bug report we call MetaspaceAux::print_on when we're about to throw an j.l.OutOfMemoryError. At that point another thread may be successful in allocating metaspace memory in another class loader or smaller memory chunks which are available. The assert condition must only hold when the VM is at a safe point and no other thread may be allocating metaspace memory. Thanks /Mikael From stefan.karlsson at oracle.com Mon Mar 11 13:39:30 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Mar 2013 14:39:30 +0100 Subject: Review request (XS): JDK-8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation In-Reply-To: <513DD83F.6000807@oracle.com> References: <513DD83F.6000807@oracle.com> Message-ID: <513DDE92.4080207@oracle.com> Looks reasonable. StefanK On 03/11/2013 02:12 PM, Mikael Gerdin wrote: > Hi, > > Please review this small fix for an incorrect assert that can trigger > when we run out of metaspace memory. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8009282/webrev.0/ > > > The reasoning behind this change is that when running with the command > line flags specified in the bug report we call MetaspaceAux::print_on > when we're about to throw an j.l.OutOfMemoryError. At that point > another thread may be successful in allocating metaspace memory in > another class loader or smaller memory chunks which are available. > > The assert condition must only hold when the VM is at a safe point and > no other thread may be allocating metaspace memory. > > Thanks > /Mikael From bengt.rutisson at oracle.com Mon Mar 11 14:34:45 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 11 Mar 2013 15:34:45 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513A367E.2000505@oracle.com> References: <5139E584.1050205@oracle.com> <513A367E.2000505@oracle.com> Message-ID: <513DEB85.9060807@oracle.com> Hi Jon, On 3/8/13 8:05 PM, Jon Masamitsu wrote: > Bengt, > > With your change the order is > > set_heap_size() > set_ergonomics_flags() > > set_ergonomics_flags() can turn on UseCompressedOops. > set_heap_size() uses UseCompressedOops > > Right? > > It might not be a problem today but it makes me nervous. > > Is there a real circularity there? I don't know but if there is > a way to exclude a circularity, then I won't have to think > about it. Thanks for spotting this, Jon! There is definitely a circular dependency between set_heap_size() and set_ergonomics_flags(). I could not figure out a nice and clean way of breaking the circular dependency. But the circular dependency actually originates from the fact that set_heap_size() does the check that the original bug reports as an issue. It reduces the max heap size if UseCompressedOops is enabled. The problem is that _after_ that it adjust the max heap size to be at least as large as the initial heap size. This is why we crash. So, one way to fix this is to use the knowledge that the initial heap size is the only thing in set_heap_size() that can increase the max heap size beyond what UseCompressedOops will work with. Here is a webrev for what that could look like: http://cr.openjdk.java.net/~brutisso/8001049/webrev.01/ I think there is another circular dependency already present in the code. If you look at max_heap_for_compressed_oops() its implementation uses ClassMetaspaceSize. But this value may be updated a bit later in set_ergonomics_flags(): FLAG_SET_ERGO(uintx, ClassMetaspaceSize, 100*M); Is this a problem? It is not really related to my current change, but if it is a problem we should probably file a bug for it. Thanks again for looking at this! Bengt > > > Jon > > > On 3/8/2013 5:20 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this change please? >> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >> >> I'm sending this to both the GC and the runtime teams since I think >> compressed oops is mixed responsibility for both teams. >> >> Background (mostly from the bug report): >> >> Hotspot crashes if it is run with a large initial size: >> >> >./java -Xms70g -version >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, tid=140305232803584 >> >> The reason is that we enable UseCompressedOops but we use the default >> value for ObjectAlignmentInBytes. With a large heap size we would >> have needed to adjust the object alignment to be able to use >> compressed oops. >> >> However, after reviewing the code it looks like the fix is not to try >> to adjust the object alignment but rather to not enable compressed >> oops for large heaps. If someone wants to use compressed oops on a >> very large heap they need to explicitly set both UseCompressedOops >> and ObjectAlignmentInBytes on the command line. As far as I can tell >> this is how it is intended to work. >> >> Here is the reason for the crash and the rational behind the fix: >> >> In Arguments::set_ergonomics_flags() we check that the max heap size >> is small enough before we enable compressed oops: >> >> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >> #if !defined(COMPILER1) || defined(TIERED) >> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >> FLAG_SET_ERGO(bool, UseCompressedOops, true); >> } >> #endif >> >> And after that we print a warning message if the heap is too large: >> >> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >> warning("Max heap size too large for Compressed Oops"); >> FLAG_SET_DEFAULT(UseCompressedOops, false); >> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >> } >> >> Now the problem is that when we don't set the max heap size on the >> command line it will be adjusted based on the initial size (-Xms) and >> this happens in Arguments::set_heap_size(), which is called *after* >> Arguments::set_ergonomics_flags() has been called. So, when we do the >> check against the max size in Arguments::set_ergonomics_flags(), we >> check against the default value for the max size. This value fits >> well with a compressed heap, so we enable compressed oops and crash >> later on when we can't address the upper part of the heap. >> >> The fix is to move the call to set_heap_size() to *before* the call >> to set_ergonomics_flags(). This way the check is done against the >> correct value. This has two effects: >> >> 1) We don't enable UseCompressedOops on heap sizes that are too large >> 2) If someone sets -XX:+UseCompressedOops on the command line but >> specifies a too large heap a warning message will be logged and >> UseCompressedOops will be turned off. >> >> I am always hesitant to rearrange the order of calls in >> Arguments::parse(). But in this case it is necessary to get the >> correct behavior and I think it is safe. As far as I can tell there >> is no other code between the two methods that try to read the >> MaxHeapSize value. >> >> Thanks, >> Bengt >> > From erik.helin at oracle.com Mon Mar 11 15:25:52 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 11 Mar 2013 16:25:52 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> Message-ID: <513DF780.3040709@oracle.com> All, I've updated the change quite a bit based on feedback from Bengt and Christian. The class JmapLauncher has moved to the newly created gc testlibrary. This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to contain utilities that can be used by all the gc jtreg tests. If there are code that is of interest for additional tests, then code can be easily be moved from the gc testlibrary to the general testlibrary. I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of this new gc testlibrary. Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ Thanks, Erik On 03/08/2013 01:34 PM, Staffan Larsen wrote: > Looks good to me. > > /Staffan > > On 8 mar 2013, at 13:36, Erik Helin wrote: > >> Bengt and Staffan, >> >> thanks for he feedback! >> >> I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. >> >> I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >> >> Thanks, >> Erik >> >> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>> >>> Erik and Staffan, >>> >>> The ProcessTools class has the method getPlatformSpecificVMArgs() that >>> returns "-d64" if necessary. You can't use this as is since you need to >>> get "J-d64" but I think we should do something to make your solution >>> more general. >>> >>> Either adding a possible prefix to the getPlatformSpecificVMArgs() or >>> adding a separate method that returns "JDK-tools formatted" args. It >>> seems a bit too limited to fix this only for your particular test. Would >>> be nice to get it in to the testlibrary somehow. >>> >>> Bengt >>> >>> >>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>> Looks good. I wish we could abstract this away so that not every test >>>> needs to do this work. >>>> >>>> /Staffan (mobile) >>>> >>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>> >>>>> Hi all, >>>>> >>>>> this change adds the option "-J-d64" or "-J-d32" (depending on arch) >>>>> when running jmap in the test >>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>> >>>>> Thanks, >>>>> Erik >>> >> > From jon.masamitsu at oracle.com Mon Mar 11 15:24:41 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 08:24:41 -0700 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513DD731.7050707@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> Message-ID: <513DF739.6010900@oracle.com> Mikael, Changes look good. Your change of the assertion at the end of Metaspace compute_new_size brought something to mind. This is separate from your changes, but do you think the Metaspace compute_new_size() should take the expand_lock()? As you note classes are being loaded and metadata is being allocated. The high-water-mark (capacity_until_GC) is being changed in compute_new_size() and being read in the should_expand() method. I don't think it will make a difference. Jon On 03/11/13 06:08, Mikael Gerdin wrote: > Anyone? > > On 2013-03-04 15:44, Mikael Gerdin wrote: >> Hi all, >> >> Please review this change to enable CMS to hand back memory for unloaded >> classes when running in concurrent mode. >> >> Bug link: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >> >> >> The core change in this patch is the inserted call in sweep(): >> 6101 >> 6102 if (should_unload_classes()) { >> 6103 ClassLoaderDataGraph::purge(); >> 6104 } >> 6105 >> >> This is needed because even though we claim to perform "class unloading" >> in the final remark phase we can't deallocate the memory for classes >> until after we've performed the sweep phase since the sweeper needs to >> find the size of objects even though they and their class is not >> considered live anymore. >> >> The rest of the changes in concurrentMarkSweepGeneration.cpp only relate >> to logging information about released metaspace memory and cms gen >> occupancy to make it easier to analyze what's happening. An example of >> this new logging output is: >> >> 134.069: [CMS-concurrent-sweep-start] >> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >> sys=0.02, real=0.01 secs] >> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >> 277487K->133228K(370885K/412976K)] ] >> 134.166: [CMS-concurrent-reset-start] >> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >> sys=0.00, real=0.02 secs] >> >> The change in genCollectedHeap.cpp is needed to avoid artificially >> inflating the size of the Metaspace memory, since memory is considered >> "used" until purge() has been called. By calling purge() before >> compute_new_size() (as the other collectors do) we use the correct >> figures. >> >> The disabled assert in metaspace.cpp is faulty because a thread may be >> allocating classes and expanding the metaspace memory while we are in >> compute_new_size, I've verified that this assert can in fact fail on a >> build without these changes. >> The change in ~SpaceManager is because of lock order restrictions, >> sum_capacity_in_chunks_in_use takes the Metaspace lock and would do it >> out of order with regards to the expand_lock. >> >> I've tested these changes primarily by running the ParallelClassLoading >> tests with a small young gen size to enable regular class unloading >> cycles. >> >> Thanks >> /Mikael From jon.masamitsu at oracle.com Mon Mar 11 15:45:35 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 08:45:35 -0700 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513DEB85.9060807@oracle.com> References: <5139E584.1050205@oracle.com> <513A367E.2000505@oracle.com> <513DEB85.9060807@oracle.com> Message-ID: <513DFC1F.6010208@oracle.com> On 03/11/13 07:34, Bengt Rutisson wrote: > > Hi Jon, > > On 3/8/13 8:05 PM, Jon Masamitsu wrote: >> Bengt, >> >> With your change the order is >> >> set_heap_size() >> set_ergonomics_flags() >> >> set_ergonomics_flags() can turn on UseCompressedOops. >> set_heap_size() uses UseCompressedOops >> >> Right? >> >> It might not be a problem today but it makes me nervous. >> >> Is there a real circularity there? I don't know but if there is >> a way to exclude a circularity, then I won't have to think >> about it. > > Thanks for spotting this, Jon! There is definitely a circular > dependency between set_heap_size() and set_ergonomics_flags(). > > I could not figure out a nice and clean way of breaking the circular > dependency. But the circular dependency actually originates from the > fact that set_heap_size() does the check that the original bug reports > as an issue. It reduces the max heap size if UseCompressedOops is > enabled. The problem is that _after_ that it adjust the max heap size > to be at least as large as the initial heap size. This is why we crash. > > So, one way to fix this is to use the knowledge that the initial heap > size is the only thing in set_heap_size() that can increase the max > heap size beyond what UseCompressedOops will work with. Here is a > webrev for what that could look like: > > http://cr.openjdk.java.net/~brutisso/8001049/webrev.01/ Did you intend to call set_use_compressed_oops() before set_heap_size() and set_ergonomics_flags()? In the webrev the call to set_use_compressed_oops() is in set_ergonmonics_flags(). > > I think there is another circular dependency already present in the > code. If you look at max_heap_for_compressed_oops() its implementation > uses ClassMetaspaceSize. But this value may be updated a bit later in > set_ergonomics_flags(): > > FLAG_SET_ERGO(uintx, ClassMetaspaceSize, 100*M); > > Is this a problem? It is not really related to my current change, but > if it is a problem we should probably file a bug for it. I'll file a bug for this. Thanks. Jon > > Thanks again for looking at this! > Bengt > >> >> >> Jon >> >> >> On 3/8/2013 5:20 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this change please? >>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>> >>> I'm sending this to both the GC and the runtime teams since I think >>> compressed oops is mixed responsibility for both teams. >>> >>> Background (mostly from the bug report): >>> >>> Hotspot crashes if it is run with a large initial size: >>> >>> >./java -Xms70g -version >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>> tid=140305232803584 >>> >>> The reason is that we enable UseCompressedOops but we use the >>> default value for ObjectAlignmentInBytes. With a large heap size we >>> would have needed to adjust the object alignment to be able to use >>> compressed oops. >>> >>> However, after reviewing the code it looks like the fix is not to >>> try to adjust the object alignment but rather to not enable >>> compressed oops for large heaps. If someone wants to use compressed >>> oops on a very large heap they need to explicitly set both >>> UseCompressedOops and ObjectAlignmentInBytes on the command line. As >>> far as I can tell this is how it is intended to work. >>> >>> Here is the reason for the crash and the rational behind the fix: >>> >>> In Arguments::set_ergonomics_flags() we check that the max heap size >>> is small enough before we enable compressed oops: >>> >>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>> #if !defined(COMPILER1) || defined(TIERED) >>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>> } >>> #endif >>> >>> And after that we print a warning message if the heap is too large: >>> >>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>> warning("Max heap size too large for Compressed Oops"); >>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>> } >>> >>> Now the problem is that when we don't set the max heap size on the >>> command line it will be adjusted based on the initial size (-Xms) >>> and this happens in Arguments::set_heap_size(), which is called >>> *after* Arguments::set_ergonomics_flags() has been called. So, when >>> we do the check against the max size in >>> Arguments::set_ergonomics_flags(), we check against the default >>> value for the max size. This value fits well with a compressed heap, >>> so we enable compressed oops and crash later on when we can't >>> address the upper part of the heap. >>> >>> The fix is to move the call to set_heap_size() to *before* the call >>> to set_ergonomics_flags(). This way the check is done against the >>> correct value. This has two effects: >>> >>> 1) We don't enable UseCompressedOops on heap sizes that are too large >>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>> specifies a too large heap a warning message will be logged and >>> UseCompressedOops will be turned off. >>> >>> I am always hesitant to rearrange the order of calls in >>> Arguments::parse(). But in this case it is necessary to get the >>> correct behavior and I think it is safe. As far as I can tell there >>> is no other code between the two methods that try to read the >>> MaxHeapSize value. >>> >>> Thanks, >>> Bengt >>> >> > From mikael.gerdin at oracle.com Mon Mar 11 16:16:19 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 11 Mar 2013 17:16:19 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513DF739.6010900@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> <513DF739.6010900@oracle.com> Message-ID: <513E0353.60902@oracle.com> Jon, On 2013-03-11 16:24, Jon Masamitsu wrote: > Mikael, > > Changes look good. Thanks > > Your change of the assertion at the end of > Metaspace compute_new_size brought > something to mind. This is separate from > your changes, but do you think the > Metaspace compute_new_size() should take > the expand_lock()? As you note classes are > being loaded and metadata is being allocated. > The high-water-mark (capacity_until_GC) is > being changed in compute_new_size() and > being read in the should_expand() method. > I don't think it will make a difference. It's interesting that you suggest this. I had a MutexLocker on the expand_lock() in my earlier versions but I had completely forgotten why I put it there. In the end I didn't move any of the calls to compute_new_size so I thought I'd skip the locking since I couldn't see any new obvious problems with it removed. But in principle I agree that we should probably hold expand_lock() in compute_new_size, but only as long as we only look at the metaspace on the level which is protected by that lock. If we start looking at individual chunks and their usage we'll need to take the appropriate metaspace_lock and not only the expand_lock. /Mikael > > Jon > > On 03/11/13 06:08, Mikael Gerdin wrote: >> Anyone? >> >> On 2013-03-04 15:44, Mikael Gerdin wrote: >>> Hi all, >>> >>> Please review this change to enable CMS to hand back memory for unloaded >>> classes when running in concurrent mode. >>> >>> Bug link: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >>> >>> >>> The core change in this patch is the inserted call in sweep(): >>> 6101 >>> 6102 if (should_unload_classes()) { >>> 6103 ClassLoaderDataGraph::purge(); >>> 6104 } >>> 6105 >>> >>> This is needed because even though we claim to perform "class unloading" >>> in the final remark phase we can't deallocate the memory for classes >>> until after we've performed the sweep phase since the sweeper needs to >>> find the size of objects even though they and their class is not >>> considered live anymore. >>> >>> The rest of the changes in concurrentMarkSweepGeneration.cpp only relate >>> to logging information about released metaspace memory and cms gen >>> occupancy to make it easier to analyze what's happening. An example of >>> this new logging output is: >>> >>> 134.069: [CMS-concurrent-sweep-start] >>> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >>> sys=0.02, real=0.01 secs] >>> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >>> 277487K->133228K(370885K/412976K)] ] >>> 134.166: [CMS-concurrent-reset-start] >>> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >>> sys=0.00, real=0.02 secs] >>> >>> The change in genCollectedHeap.cpp is needed to avoid artificially >>> inflating the size of the Metaspace memory, since memory is considered >>> "used" until purge() has been called. By calling purge() before >>> compute_new_size() (as the other collectors do) we use the correct >>> figures. >>> >>> The disabled assert in metaspace.cpp is faulty because a thread may be >>> allocating classes and expanding the metaspace memory while we are in >>> compute_new_size, I've verified that this assert can in fact fail on a >>> build without these changes. >>> The change in ~SpaceManager is because of lock order restrictions, >>> sum_capacity_in_chunks_in_use takes the Metaspace lock and would do it >>> out of order with regards to the expand_lock. >>> >>> I've tested these changes primarily by running the ParallelClassLoading >>> tests with a small young gen size to enable regular class unloading >>> cycles. >>> >>> Thanks >>> /Mikael From jon.masamitsu at oracle.com Mon Mar 11 16:32:36 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 09:32:36 -0700 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513E0353.60902@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> <513DF739.6010900@oracle.com> <513E0353.60902@oracle.com> Message-ID: <513E0724.9010404@oracle.com> On 03/11/13 09:16, Mikael Gerdin wrote: > Jon, > > On 2013-03-11 16:24, Jon Masamitsu wrote: >> Mikael, >> >> Changes look good. > Thanks > >> >> Your change of the assertion at the end of >> Metaspace compute_new_size brought >> something to mind. This is separate from >> your changes, but do you think the >> Metaspace compute_new_size() should take >> the expand_lock()? As you note classes are >> being loaded and metadata is being allocated. >> The high-water-mark (capacity_until_GC) is >> being changed in compute_new_size() and >> being read in the should_expand() method. >> I don't think it will make a difference. > > It's interesting that you suggest this. > I had a MutexLocker on the expand_lock() in my earlier versions but I > had completely forgotten why I put it there. > In the end I didn't move any of the calls to compute_new_size so I > thought I'd skip the locking since I couldn't see any new obvious > problems with it removed. That's fine with me. > > But in principle I agree that we should probably hold expand_lock() in > compute_new_size, but only as long as we only look at the metaspace on > the level which is protected by that lock. > If we start looking at individual chunks and their usage we'll need to > take the appropriate metaspace_lock and not only the expand_lock. Right. compute_new_size() is more globals than any particular Metaspace so only the expand_lock would be appropriate at this point. Again, looks good. Jon > > /Mikael > >> >> Jon >> >> On 03/11/13 06:08, Mikael Gerdin wrote: >>> Anyone? >>> >>> On 2013-03-04 15:44, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> Please review this change to enable CMS to hand back memory for >>>> unloaded >>>> classes when running in concurrent mode. >>>> >>>> Bug link: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >>>> >>>> >>>> The core change in this patch is the inserted call in sweep(): >>>> 6101 >>>> 6102 if (should_unload_classes()) { >>>> 6103 ClassLoaderDataGraph::purge(); >>>> 6104 } >>>> 6105 >>>> >>>> This is needed because even though we claim to perform "class >>>> unloading" >>>> in the final remark phase we can't deallocate the memory for classes >>>> until after we've performed the sweep phase since the sweeper needs to >>>> find the size of objects even though they and their class is not >>>> considered live anymore. >>>> >>>> The rest of the changes in concurrentMarkSweepGeneration.cpp only >>>> relate >>>> to logging information about released metaspace memory and cms gen >>>> occupancy to make it easier to analyze what's happening. An example of >>>> this new logging output is: >>>> >>>> 134.069: [CMS-concurrent-sweep-start] >>>> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >>>> sys=0.02, real=0.01 secs] >>>> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >>>> 277487K->133228K(370885K/412976K)] ] >>>> 134.166: [CMS-concurrent-reset-start] >>>> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >>>> sys=0.00, real=0.02 secs] >>>> >>>> The change in genCollectedHeap.cpp is needed to avoid artificially >>>> inflating the size of the Metaspace memory, since memory is considered >>>> "used" until purge() has been called. By calling purge() before >>>> compute_new_size() (as the other collectors do) we use the correct >>>> figures. >>>> >>>> The disabled assert in metaspace.cpp is faulty because a thread may be >>>> allocating classes and expanding the metaspace memory while we are in >>>> compute_new_size, I've verified that this assert can in fact fail on a >>>> build without these changes. >>>> The change in ~SpaceManager is because of lock order restrictions, >>>> sum_capacity_in_chunks_in_use takes the Metaspace lock and would do it >>>> out of order with regards to the expand_lock. >>>> >>>> I've tested these changes primarily by running the >>>> ParallelClassLoading >>>> tests with a small young gen size to enable regular class unloading >>>> cycles. >>>> >>>> Thanks >>>> /Mikael From kevin.walls at oracle.com Mon Mar 11 16:38:43 2013 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Mon, 11 Mar 2013 16:38:43 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20130311163851.A98D848069@hg.openjdk.java.net> Changeset: 167812fe00bb Author: kevinw Date: 2013-03-11 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/167812fe00bb 8009723: CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Reviewed-by: jwilhelm, ehelin, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 71f619500f9b Author: kevinw Date: 2013-03-11 15:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/71f619500f9b Merge From jesper.wilhelmsson at oracle.com Mon Mar 11 17:59:53 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 11 Mar 2013 18:59:53 +0100 Subject: RFR (XS): 8007003: ParNew sends the heap summary too early Message-ID: <513E1B99.3020001@oracle.com> Hi, Looking for a couple of reviews for this small fix. If there is a risk for promotion failure then ParNew can decide to do an early exit. In ParNew::collect, the heap summary event is sent before this check, which means that there might be a heap summary without a corresponding garbage collection event. The fix is to send the event after the early exit. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007003 Webrev: http://cr.openjdk.java.net/~jwilhelm/8007003/webrev/ Thanks, /Jesper From jon.masamitsu at oracle.com Mon Mar 11 18:10:36 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 11:10:36 -0700 Subject: Review request: 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA In-Reply-To: <513DAC12.4050801@oracle.com> References: <513DAC12.4050801@oracle.com> Message-ID: <513E1E1C.1060201@oracle.com> Looks good. Jon On 03/11/13 03:04, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8004697/webrev.00/ > > The JVM crashes because it accidentally frees memory in the survivor > regions, at one point where it is supposed to only free freeing memory > in the eden. > > The code in os::scan_pages(start, end, ...) in solaris_os.cpp looks at > pages starting beyond 'end'. This causes > MutableNUMASpace::LGRPSpace::scan_pages to free memory outside eden, > when the last page starts in, but ends outside of eden. > > Testing: The JVM used to crash within in a couple of minutes. With the > patch, the test has been running over the weekend without any crashes. > > thanks, > StefanK From jon.masamitsu at oracle.com Mon Mar 11 18:33:20 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 11:33:20 -0700 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <513DADEE.4040302@oracle.com> References: <513855CC.5030009@oracle.com> <5138FF3A.6070902@oracle.com> <513DADEE.4040302@oracle.com> Message-ID: <513E2370.3030704@oracle.com> Mikael, This change looks good. I looked over your replies and am OK with them. At some point we may need to limit the space in the "last" Virtualspace so that the total reserved is at MaxMetaspaceSize, but that is a different change. Thanks. Jon On 03/11/13 03:11, Mikael Gerdin wrote: > Jon, > > On 2013-03-07 21:57, Jon Masamitsu wrote: >> >> >> On 03/07/13 00:54, Mikael Gerdin wrote: >>> Hi >>> >>> >>> When deciding when to reserve more metaspace memory we erroneously >>> looked only at the "capacity" of the metaspace insted of the reserved >>> space (which is what we ask this function when expanding). >> >> Using MetaspaceAux::reserved_in_bytes() means that we >> could return false here >> >> 1105 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)&& >> 1106 MetaspaceAux::reserved_in_bytes()>= MaxMetaspaceSize) { >> 1107 return false; >> 1108 } >> >> when most of the space reserved in one or two VirtualSpace's is unused. >> With the current value of parameters, that could almost be 512kb. > > Yes. > > I guess the question is: > Should MaxMetaspaceSize limit the amount of virtual address space > reserved for metaspaces or should it limit the amount of committed pages? > > To be consistent with how the Java heap is handled my opinion is that > we should limit the amount of reserved memory. > > I any case the current version is incorrect since > MetaspaceGC::should_expand was queried to determine if we should > reserve more virtual address space or not and the size check was > against the amount of committed memory. > > /Mikael > >> >> Jon >> >>> >>> Additionally, we didn't check MaxMetaspaceSize against the sum of >>> reserved(Class) + reserved(NonClass) which caused us to use more than >>> MaxMetaspaceSize even when it was set. >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >>> (not yet available at the time of writing this mail) >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >>> >>> Testing: >>> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >>> path. From jon.masamitsu at oracle.com Mon Mar 11 18:35:32 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 11 Mar 2013 11:35:32 -0700 Subject: Review request (XS): JDK-8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation In-Reply-To: <513DD83F.6000807@oracle.com> References: <513DD83F.6000807@oracle.com> Message-ID: <513E23F4.3040107@oracle.com> Looks good. Jon On 03/11/13 06:12, Mikael Gerdin wrote: > Hi, > > Please review this small fix for an incorrect assert that can trigger > when we run out of metaspace memory. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8009282/webrev.0/ > > > The reasoning behind this change is that when running with the command > line flags specified in the bug report we call MetaspaceAux::print_on > when we're about to throw an j.l.OutOfMemoryError. At that point > another thread may be successful in allocating metaspace memory in > another class loader or smaller memory chunks which are available. > > The assert condition must only hold when the VM is at a safe point and > no other thread may be allocating metaspace memory. > > Thanks > /Mikael From john.cuthbertson at oracle.com Mon Mar 11 21:35:58 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 11 Mar 2013 14:35:58 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing Message-ID: <513E4E3E.4020405@oracle.com> Hi Everyone, Can I have a couple of volunteers review these changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/. First of all - many thanks to Uwe Schindler for discovering an reporting the problem and providing very clear instructions on how to reproduce the issue. Many thanks also Dawid Weiss for also stepping in with a self-contained reproducer. I also wish to thank Bengt for his help. It was Bengt who gave me the magic proxy formula that allowed Ivy to satisfy and download all the dependencies for the test case. Bengt also diagnosed the problem and gave an initial fix (which the changes in the webrev are based upon). Summary: During the remark pause, the execution of the parallel RemarkTask set the number of workers thread in the ParallelTaskTerminator and the first and second barrier syncs. During serial reference processing, the marking stack overflowed causing the single (VMThread) thread to enter the overflow handling code in CMTask::do_marking_step(). This overflow code using two WorkBarrierSyncs to synchronize the threads before resetting the marking state for restarting marking. The barrier syncs were waiting for the number of threads that participated in the RemarkTask) but, since only the VM thread was executing, only a single thread entered the barrier - resulting in the barrier indefinitely waiting for the other (non existent) threads. A proposed solution was to call set_phase to reset the number of threads in the parallel task terminator and the barriers to the number of active threads for the reference processing. This solution ran into a similar hang while processing the JNI references with parallel reference processing enabled. (In parallel reference processing, the JNI references are processed serially by the calling thread). Resetting the phase to single-threaded before processing the JNI refs solved the second hang but resulted in an assertion failure: only a concurrentGC thread can enter a barrier sync and the calling thread was the VM thread. Furthermore another problem was discovered. If the marking state is reset, a subsequent call to set_phase() will assert as the global finger has been set to start of the heap. This was a discovered by the marking stack overflowing during the RemarkTask and parallel reference processing calling set_phase() to reinitialize number of workers in the parallel task terminator. It was also discovered when trying out another proposed solution: adding a start_gc closure to reference processing which would call set_phase() before each processing phase. As a result the marking state is only reset by worker 0 if an overflow occurs during the concurrent phase of marking; if an overflow occurs during remark, reference processing is skipped, and the marking state is reset by the VM thread. Resetting the marking state before reference processing was a benign error (objects would be marked but not pushed on to the stack as they were no longer below the finger; the objects would then be traced, in the normal fashion, when marking restarted) but it's better to safe than sorry. The other part of the fix for this secondary problem is that the parallel reference processing task executor now calls the terminator's reset_for_reuse() routine instead of set_phase(). The resulting solution for the hang is based upon the patch sent out by Bengt - namely we do not enter the sync barriers when CMTask::do_marking_step() is being called serially. The difference is that I added an extra parameter to CMTask::do_marking_step() instead of piggy-backing on the existing parameter list. Additionally, if this new parameter indicates serial operation, the current thread will skip offering termination. This allows the serial drain closure to enter the termination protocol and execute the guarantees contained therein. The other changes are for the secondary issues, described above, that were discovered while out trying other possible solutions. Testing: The lucene test case with serial reference processing (with and without verification); the lucene test case with parallel reference processing (with and without verification). GC test suite with a mark stack size of 1K and 4K, with both serial and parallel reference processing (with and without verification). From ysr1729 at gmail.com Mon Mar 11 23:11:10 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 11 Mar 2013 16:11:10 -0700 Subject: Mismatch between JDK and JVM re largest byte array that VM can allocate? Message-ID: I am looking at code in (for example) ByteArrayOutputStream.java :- 96 /** 97 * Increases the capacity to ensure that it can hold at least the 98 * number of elements specified by the minimum capacity argument. 99 * 100 * @param minCapacity the desired minimum capacity 101 */ 102 private void grow(int minCapacity) { 103 // overflow-conscious code 104 int oldCapacity = buf.length; 105 int newCapacity = oldCapacity << 1; 106 if (newCapacity - minCapacity < 0) 107 newCapacity = minCapacity; 108 if (newCapacity < 0) { 109 if (minCapacity < 0) // overflow 110 throw new OutOfMemoryError(); 111 newCapacity = Integer.MAX_VALUE; 112 } 113 buf = Arrays.copyOf(buf, newCapacity); 114 } This can result in a request for an array of size Integer.MAX_VALUE (because of line 111 above), see below:- 2874 /** 2875 * Copies the specified array, truncating or padding with zeros (if necessary) 2876 * so the copy has the specified length. For all indices that are 2877 * valid in both the original array and the copy, the two arrays will 2878 * contain identical values. For any indices that are valid in the 2879 * copy but not the original, the copy will contain (byte)0. 2880 * Such indices will exist if and only if the specified length 2881 * is greater than that of the original array. 2882 * 2883 * @param original the array to be copied 2884 * @param newLength the length of the copy to be returned 2885 * @return a copy of the original array, truncated or padded with zeros 2886 * to obtain the specified length 2887 * @throws NegativeArraySizeException if newLength is negative 2888 * @throws NullPointerException if original is null 2889 * @since 1.6 2890 */ 2891 public static byte[] copyOf(byte[] original, int newLength) { 2892 byte[] copy = new byte[newLength]; 2893 System.arraycopy(original, 0, copy, 0, 2894 Math.min(original.length, newLength)); 2895 return copy; 2896 } So the call at line 2892 can cause a request for an array with Integer.MAX_VALUE entries, yet the JVM doesn't give you arrays that large; witness this code in arrayOop.cpp where this will flatten out:- // Return the maximum length of an array of BasicType. The length can passed // to typeArrayOop::object_size(scale, length, header_size) without causing an // overflow. We also need to make sure that this will not overflow a size_t on // 32 bit platforms when we convert it to a byte size. static int32_t max_array_length(BasicType type) { assert(type >= 0 && type < T_CONFLICT, "wrong type"); assert(type2aelembytes(type) != 0, "wrong type"); const size_t max_element_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); const size_t max_elements_per_size_t = HeapWordSize * max_element_words_per_size_t / type2aelembytes(type); if ((size_t)max_jint < max_elements_per_size_t) { // It should be ok to return max_jint here, but parts of the code // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for // passing around the size (in words) of an object. So, we need to avoid // overflowing an int when we add the header. See CRs 4718400 and 7110613. return align_size_down(max_jint - header_size(type), MinObjAlignment); } return (int32_t)max_elements_per_size_t; } Is there any plan to fix this mismatch ? May be it's as simple(!) as checking the GC code to make sure it doesn't traffic in int's and fix the code above to return max_jint for the byte array case as well? I have a vague recollection of a bug id already for this, but it's been a while.... Thanks! -- ramki From tao.mao at oracle.com Tue Mar 12 00:54:15 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 11 Mar 2013 17:54:15 -0700 Subject: Review request (XS): JDK-8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation In-Reply-To: <513E23F4.3040107@oracle.com> References: <513DD83F.6000807@oracle.com> <513E23F4.3040107@oracle.com> Message-ID: <513E7CB7.9030508@oracle.com> Looks good to me, too. As safety check, did you test the change clear on any machine you previously were able to reproduce the bug? Tao On 3/11/2013 11:35 AM, Jon Masamitsu wrote: > Looks good. > > Jon > > On 03/11/13 06:12, Mikael Gerdin wrote: >> Hi, >> >> Please review this small fix for an incorrect assert that can trigger >> when we run out of metaspace memory. >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8009282/webrev.0/ >> >> >> The reasoning behind this change is that when running with the >> command line flags specified in the bug report we call >> MetaspaceAux::print_on when we're about to throw an >> j.l.OutOfMemoryError. At that point another thread may be successful >> in allocating metaspace memory in another class loader or smaller >> memory chunks which are available. >> >> The assert condition must only hold when the VM is at a safe point >> and no other thread may be allocating metaspace memory. >> >> Thanks >> /Mikael From david.holmes at oracle.com Tue Mar 12 01:25:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2013 11:25:28 +1000 Subject: Mismatch between JDK and JVM re largest byte array that VM can allocate? In-Reply-To: References: Message-ID: <513E8408.8060107@oracle.com> Hi Ramki, The maximum array size is a VM limitation based on the internal implementation, so I don't think the JDK code should be aware of this limitation. At least with the present code the request for a size of Integer.MAX_VALUE will fail immediately, rather than spending half an hour failing to allocate an insanely large array ;-) If huge arrays eventually make their way into Java we will have to address this, but otherwise it seems pretty low priority to me. Is this actually causing an issue or is it just an observation? Cheers, David On 12/03/2013 9:11 AM, Srinivas Ramakrishna wrote: > I am looking at code in (for example) ByteArrayOutputStream.java :- > > 96 /** > > 97 * Increases the capacity to ensure that it can hold at least the > > 98 * number of elements specified by the minimum capacity argument. > > 99 * > > 100 * @param minCapacity the desired minimum capacity > > 101 */ > > 102 private void grow(int minCapacity) { > > 103 // overflow-conscious code > > 104 int oldCapacity = buf.length; > > 105 int newCapacity = oldCapacity << 1; > > 106 if (newCapacity - minCapacity < 0) > > 107 newCapacity = minCapacity; > > 108 if (newCapacity < 0) { > > 109 if (minCapacity < 0) // overflow > > 110 throw new OutOfMemoryError(); > > 111 newCapacity = Integer.MAX_VALUE; > > 112 } > > 113 buf = Arrays.copyOf(buf, newCapacity); > > 114 } > > > This can result in a request for an array of size Integer.MAX_VALUE > (because of line 111 above), see below:- > > 2874 /** > > 2875 * Copies the specified array, truncating or padding > with zeros (if necessary) > > 2876 * so the copy has the specified length. For all indices that are > > 2877 * valid in both the original array and the copy, the > two arrays will > > 2878 * contain identical values. For any indices that are > valid in the > > 2879 * copy but not the original, the copy will contain > (byte)0. > > 2880 * Such indices will exist if and only if the specified length > > 2881 * is greater than that of the original array. > > 2882 * > > 2883 * @param original the array to be copied > > 2884 * @param newLength the length of the copy to be returned > > 2885 * @return a copy of the original array, truncated or > padded with zeros > > 2886 * to obtain the specified length > > 2887 * @throws NegativeArraySizeException if > newLength is negative > > 2888 * @throws NullPointerException if original is null > > 2889 * @since 1.6 > > 2890 */ > > 2891 public static byte[] copyOf(byte[] original, int newLength) { > > 2892 byte[] copy = new byte[newLength]; > > 2893 System.arraycopy(original, 0, copy, 0, > > 2894 Math.min(original.length, newLength)); > > 2895 return copy; > > 2896 } > > > So the call at line 2892 can cause a request for an array with > Integer.MAX_VALUE entries, yet the JVM doesn't give you arrays that > large; witness this code in arrayOop.cpp where this will flatten out:- > > // Return the maximum length of an array of BasicType. The length can passed > // to typeArrayOop::object_size(scale, length, header_size) without causing an > // overflow. We also need to make sure that this will not overflow a size_t on > // 32 bit platforms when we convert it to a byte size. > static int32_t max_array_length(BasicType type) { > assert(type >= 0 && type < T_CONFLICT, "wrong type"); > assert(type2aelembytes(type) != 0, "wrong type"); > > const size_t max_element_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = > HeapWordSize * max_element_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t) { > // It should be ok to return max_jint here, but parts of the code > // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for > // passing around the size (in words) of an object. So, we need to avoid > // overflowing an int when we add the header. See CRs 4718400 and 7110613. > return align_size_down(max_jint - header_size(type), MinObjAlignment); > } > return (int32_t)max_elements_per_size_t; > } > > > Is there any plan to fix this mismatch ? May be it's as simple(!) as > checking the GC code to make sure it doesn't traffic in int's and > fix the code above to return max_jint for the byte array case as well? > I have a vague recollection of a bug id already for this, but > it's been a while.... > > Thanks! > -- ramki > From ysr1729 at gmail.com Tue Mar 12 05:22:20 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 11 Mar 2013 22:22:20 -0700 Subject: Mismatch between JDK and JVM re largest byte array that VM can allocate? In-Reply-To: <513E8408.8060107@oracle.com> References: <513E8408.8060107@oracle.com> Message-ID: It's causing an issue -- which can be worked around in our code -- which is how I stumbled upon this. My thinking was that perhaps the jvm limit could be communicated to the libs via a suitable jvm method. Or better still the unnecessary limitation could be removed for the 64 bit jvm and everyone's happy. Max sized byte arrays are not that uncommon in certain kinds of apps using large heaps. The unfortunate part is that the workaround might require one to stay well away from the actual limit -- to the extent of less than half of max-int minus header size. So, definitely not a show-stopper, but would be nice to fix-- and perhaps easy to in the 64 bit case which is where it matters anyway. -- Ramki ysr1729 On Mar 11, 2013, at 18:25, David Holmes wrote: > Hi Ramki, > > The maximum array size is a VM limitation based on the internal implementation, so I don't think the JDK code should be aware of this limitation. > > At least with the present code the request for a size of Integer.MAX_VALUE will fail immediately, rather than spending half an hour failing to allocate an insanely large array ;-) > > If huge arrays eventually make their way into Java we will have to address this, but otherwise it seems pretty low priority to me. > > Is this actually causing an issue or is it just an observation? > > Cheers, > David > > On 12/03/2013 9:11 AM, Srinivas Ramakrishna wrote: >> I am looking at code in (for example) ByteArrayOutputStream.java :- >> >> 96 /** >> >> 97 * Increases the capacity to ensure that it can hold at least the >> >> 98 * number of elements specified by the minimum capacity argument. >> >> 99 * >> >> 100 * @param minCapacity the desired minimum capacity >> >> 101 */ >> >> 102 private void grow(int minCapacity) { >> >> 103 // overflow-conscious code >> >> 104 int oldCapacity = buf.length; >> >> 105 int newCapacity = oldCapacity << 1; >> >> 106 if (newCapacity - minCapacity < 0) >> >> 107 newCapacity = minCapacity; >> >> 108 if (newCapacity < 0) { >> >> 109 if (minCapacity < 0) // overflow >> >> 110 throw new OutOfMemoryError(); >> >> 111 newCapacity = Integer.MAX_VALUE; >> >> 112 } >> >> 113 buf = Arrays.copyOf(buf, newCapacity); >> >> 114 } >> >> >> This can result in a request for an array of size Integer.MAX_VALUE >> (because of line 111 above), see below:- >> >> 2874 /** >> >> 2875 * Copies the specified array, truncating or padding >> with zeros (if necessary) >> >> 2876 * so the copy has the specified length. For all indices that are >> >> 2877 * valid in both the original array and the copy, the >> two arrays will >> >> 2878 * contain identical values. For any indices that are >> valid in the >> >> 2879 * copy but not the original, the copy will contain >> (byte)0. >> >> 2880 * Such indices will exist if and only if the specified length >> >> 2881 * is greater than that of the original array. >> >> 2882 * >> >> 2883 * @param original the array to be copied >> >> 2884 * @param newLength the length of the copy to be returned >> >> 2885 * @return a copy of the original array, truncated or >> padded with zeros >> >> 2886 * to obtain the specified length >> >> 2887 * @throws NegativeArraySizeException if >> newLength is negative >> >> 2888 * @throws NullPointerException if original is null >> >> 2889 * @since 1.6 >> >> 2890 */ >> >> 2891 public static byte[] copyOf(byte[] original, int newLength) { >> >> 2892 byte[] copy = new byte[newLength]; >> >> 2893 System.arraycopy(original, 0, copy, 0, >> >> 2894 Math.min(original.length, newLength)); >> >> 2895 return copy; >> >> 2896 } >> >> >> So the call at line 2892 can cause a request for an array with >> Integer.MAX_VALUE entries, yet the JVM doesn't give you arrays that >> large; witness this code in arrayOop.cpp where this will flatten out:- >> >> // Return the maximum length of an array of BasicType. The length can passed >> // to typeArrayOop::object_size(scale, length, header_size) without causing an >> // overflow. We also need to make sure that this will not overflow a size_t on >> // 32 bit platforms when we convert it to a byte size. >> static int32_t max_array_length(BasicType type) { >> assert(type >= 0 && type < T_CONFLICT, "wrong type"); >> assert(type2aelembytes(type) != 0, "wrong type"); >> >> const size_t max_element_words_per_size_t = >> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >> MinObjAlignment); >> const size_t max_elements_per_size_t = >> HeapWordSize * max_element_words_per_size_t / type2aelembytes(type); >> if ((size_t)max_jint < max_elements_per_size_t) { >> // It should be ok to return max_jint here, but parts of the code >> // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for >> // passing around the size (in words) of an object. So, we need to avoid >> // overflowing an int when we add the header. See CRs 4718400 and 7110613. >> return align_size_down(max_jint - header_size(type), MinObjAlignment); >> } >> return (int32_t)max_elements_per_size_t; >> } >> >> >> Is there any plan to fix this mismatch ? May be it's as simple(!) as >> checking the GC code to make sure it doesn't traffic in int's and >> fix the code above to return max_jint for the byte array case as well? >> I have a vague recollection of a bug id already for this, but >> it's been a while.... >> >> Thanks! >> -- ramki >> From bengt.rutisson at oracle.com Tue Mar 12 06:40:45 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 07:40:45 +0100 Subject: RFR (XS): 8007003: ParNew sends the heap summary too early In-Reply-To: <513E1B99.3020001@oracle.com> References: <513E1B99.3020001@oracle.com> Message-ID: <649D14D0-2C8C-47D8-9B0C-E92818F92AEA@oracle.com> Hi Jesper, Looks good. I think you can move this line down to after the early exit too: 894 ParNewTracer gc_tracer; Bengt 11 mar 2013 kl. 18:59 skrev Jesper Wilhelmsson : > Hi, > > Looking for a couple of reviews for this small fix. > > If there is a risk for promotion failure then ParNew can decide to do an early exit. In ParNew::collect, the heap summary event is sent before this check, which means that there might be a heap summary without a corresponding garbage collection event. > > The fix is to send the event after the early exit. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007003 > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8007003/webrev/ > > Thanks, > /Jesper -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Tue Mar 12 07:25:27 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 12 Mar 2013 11:25:27 +0400 Subject: RFR: 8009763 Add WB test for String.intern() Message-ID: <513ED867.2070902@oracle.com> Hi I've added a small test which: 1) creates java string and intern it 2) verify that it presents in StringTable 3) clear reference and call fullGC 4) verify that there is no such string in StringTable Here is webrev: http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.0/ Tested locally and by JPRT -- Leonid Mesnik JVM SQE From erik.helin at oracle.com Tue Mar 12 07:31:32 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 12 Mar 2013 08:31:32 +0100 Subject: RFR (XS): 8007003: ParNew sends the heap summary too early In-Reply-To: <513E1B99.3020001@oracle.com> References: <513E1B99.3020001@oracle.com> Message-ID: <513ED9D4.9090509@oracle.com> Hi Jesper, the change looks good! I agree with Bengt on moving down the definition of gc_tracer, please fix this before pushing (no need for another webrev). Thanks, Erik On 03/11/2013 06:59 PM, Jesper Wilhelmsson wrote: > Hi, > > Looking for a couple of reviews for this small fix. > > If there is a risk for promotion failure then ParNew can decide to do an > early exit. In ParNew::collect, the heap summary event is sent before > this check, which means that there might be a heap summary without a > corresponding garbage collection event. > > The fix is to send the event after the early exit. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007003 > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8007003/webrev/ > > Thanks, > /Jesper From bengt.rutisson at oracle.com Tue Mar 12 07:40:53 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 08:40:53 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513E2441.3050709@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513A293D.8020702@oracle.com> <513DF0D2.8060408@oracle.com> <513E2441.3050709@oracle.com> Message-ID: <513EDC05.1030807@oracle.com> Hi Vladimir, On 3/11/13 7:36 PM, Vladimir Kozlov wrote: > On 3/11/13 7:57 AM, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> Thanks for looking at this! >> >> On 3/8/13 7:09 PM, Vladimir Kozlov wrote: >>> I am wondering should we also add a check into >>> Universe::reserve_heap() before calling >>> Universe::preferred_heap_base(). >> >> Do you mean that we should add an assert in Universe::reserve_heap() to >> check that the size we reserve is compatible with the compressed oop > > Yes, I want > > size_t total_reserved = align_size_up(heap_size + > Universe::class_metaspace_size(), alignment); > + assert(!UseCompressedOops || (total_reserved <= (OopEncodingHeapMax > - os::vm_page_size())), "heap size is too big for compressed oops"); > char* addr = Universe::preferred_heap_base(total_reserved, > Universe::UnscaledNarrowOop); > > You don't need to duplicate max_heap_for_compressed_oops() because > total_reserved includes class_metaspace. Thanks for this clarification! I added the assert. > There are size rounding codes in some places after arguments parsing > and someone could add an other ergonomic code after checks during > arguments parsing. To have an assert to catch such cases would be nice. Good point. Thanks for the help with this. Bengt > > Thanks, > Vladimir > >> state? I think that's fine but that means that I either have to >> duplicate the code in max_heap_for_compressed_oops() or make it publicly >> available somewhere. Currently it is just a local function inside >> Arguments.cpp. >> >> Personally I am not sure the assert will be worth the code change, but >> I'm fine with adding it if you want to. >> >> Thanks, >> Bengt >> >> >>> >>> Vladimir >>> >>> On 3/8/13 9:41 AM, harold seigel wrote: >>>> The change looks good. Perhaps this problem wasn't seen before >>>> because >>>> this scenario hadn't been tested? >>>> >>>> Harold >>>> >>>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>>> The change is reasonable. >>>>> >>>>> So why we did not see this problem before? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change please? >>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>> >>>>>> I'm sending this to both the GC and the runtime teams since I think >>>>>> compressed oops is mixed responsibility for both teams. >>>>>> >>>>>> Background (mostly from the bug report): >>>>>> >>>>>> Hotspot crashes if it is run with a large initial size: >>>>>> >>>>>> >./java -Xms70g -version >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>> tid=140305232803584 >>>>>> >>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>> default >>>>>> value for ObjectAlignmentInBytes. With a large heap size we would >>>>>> have >>>>>> needed to adjust the object alignment to be able to use compressed >>>>>> oops. >>>>>> >>>>>> However, after reviewing the code it looks like the fix is not to >>>>>> try to >>>>>> adjust the object alignment but rather to not enable compressed >>>>>> oops for >>>>>> large heaps. If someone wants to use compressed oops on a very large >>>>>> heap they need to explicitly set both UseCompressedOops and >>>>>> ObjectAlignmentInBytes on the command line. As far as I can tell >>>>>> this is >>>>>> how it is intended to work. >>>>>> >>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>> >>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>> size is >>>>>> small enough before we enable compressed oops: >>>>>> >>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>> } >>>>>> #endif >>>>>> >>>>>> And after that we print a warning message if the heap is too large: >>>>>> >>>>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>> } >>>>>> >>>>>> Now the problem is that when we don't set the max heap size on the >>>>>> command line it will be adjusted based on the initial size (-Xms) >>>>>> and >>>>>> this happens in Arguments::set_heap_size(), which is called *after* >>>>>> Arguments::set_ergonomics_flags() has been called. So, when we do >>>>>> the >>>>>> check against the max size in Arguments::set_ergonomics_flags(), we >>>>>> check against the default value for the max size. This value fits >>>>>> well >>>>>> with a compressed heap, so we enable compressed oops and crash >>>>>> later on >>>>>> when we can't address the upper part of the heap. >>>>>> >>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>> call to >>>>>> set_ergonomics_flags(). This way the check is done against the >>>>>> correct >>>>>> value. This has two effects: >>>>>> >>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>> large >>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>> specifies a too large heap a warning message will be logged and >>>>>> UseCompressedOops will be turned off. >>>>>> >>>>>> I am always hesitant to rearrange the order of calls in >>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>> correct >>>>>> behavior and I think it is safe. As far as I can tell there is no >>>>>> other >>>>>> code between the two methods that try to read the MaxHeapSize value. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >> From bengt.rutisson at oracle.com Tue Mar 12 07:41:46 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 08:41:46 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513DF957.9090805@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513DED5D.8060605@oracle.com> <513DF957.9090805@oracle.com> Message-ID: <513EDC3A.8060106@oracle.com> Hi Harold, Thanks for the review and thanks for spotting the spelling mistake! Fixed it. Bengt On 3/11/13 4:33 PM, harold seigel wrote: > Hi Bengt, > > These changes also look good. > > One very minor nit is that InitialHeapSize (IniitalHeapSize)is > misspelled in one of the comments. > > Thanks, Harold > > On 3/11/2013 10:42 AM, Bengt Rutisson wrote: >> >> Hi Harold, >> >> Thanks for looking at these changes. >> >> On 3/8/13 6:41 PM, harold seigel wrote: >>> The change looks good. >> >> Thanks, I had to update the webrev. Let me know what you think about >> that solution. >> >>> Perhaps this problem wasn't seen before because this scenario hadn't >>> been tested? >> >> Yes, this is not tested and it is actually difficult to add a >> meaningful test for it. The problem will only appear on machines with >> more than 32 GB memory. We don't have many of them in our testing. >> There is no way to tell the test infrastructure that the test has to >> be run on a large machine. So, if I write the test (which would be >> very simple) it would most of the time just consume time and >> resources without testing anything since it would be run on too small >> machines. And I would have to write the test to "pass" on those. >> >> Bengt >> >>> >>> Harold >>> >>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>> The change is reasonable. >>>> >>>> So why we did not see this problem before? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this change please? >>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>> >>>>> I'm sending this to both the GC and the runtime teams since I think >>>>> compressed oops is mixed responsibility for both teams. >>>>> >>>>> Background (mostly from the bug report): >>>>> >>>>> Hotspot crashes if it is run with a large initial size: >>>>> >>>>> >./java -Xms70g -version >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>> tid=140305232803584 >>>>> >>>>> The reason is that we enable UseCompressedOops but we use the default >>>>> value for ObjectAlignmentInBytes. With a large heap size we would >>>>> have >>>>> needed to adjust the object alignment to be able to use compressed >>>>> oops. >>>>> >>>>> However, after reviewing the code it looks like the fix is not to >>>>> try to >>>>> adjust the object alignment but rather to not enable compressed >>>>> oops for >>>>> large heaps. If someone wants to use compressed oops on a very large >>>>> heap they need to explicitly set both UseCompressedOops and >>>>> ObjectAlignmentInBytes on the command line. As far as I can tell >>>>> this is >>>>> how it is intended to work. >>>>> >>>>> Here is the reason for the crash and the rational behind the fix: >>>>> >>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>> size is >>>>> small enough before we enable compressed oops: >>>>> >>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>> } >>>>> #endif >>>>> >>>>> And after that we print a warning message if the heap is too large: >>>>> >>>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>> warning("Max heap size too large for Compressed Oops"); >>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>> } >>>>> >>>>> Now the problem is that when we don't set the max heap size on the >>>>> command line it will be adjusted based on the initial size (-Xms) and >>>>> this happens in Arguments::set_heap_size(), which is called *after* >>>>> Arguments::set_ergonomics_flags() has been called. So, when we do the >>>>> check against the max size in Arguments::set_ergonomics_flags(), we >>>>> check against the default value for the max size. This value fits >>>>> well >>>>> with a compressed heap, so we enable compressed oops and crash >>>>> later on >>>>> when we can't address the upper part of the heap. >>>>> >>>>> The fix is to move the call to set_heap_size() to *before* the >>>>> call to >>>>> set_ergonomics_flags(). This way the check is done against the >>>>> correct >>>>> value. This has two effects: >>>>> >>>>> 1) We don't enable UseCompressedOops on heap sizes that are too large >>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>> specifies a too large heap a warning message will be logged and >>>>> UseCompressedOops will be turned off. >>>>> >>>>> I am always hesitant to rearrange the order of calls in >>>>> Arguments::parse(). But in this case it is necessary to get the >>>>> correct >>>>> behavior and I think it is safe. As far as I can tell there is no >>>>> other >>>>> code between the two methods that try to read the MaxHeapSize value. >>>>> >>>>> Thanks, >>>>> Bengt >>> >> > From bengt.rutisson at oracle.com Tue Mar 12 07:47:15 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 08:47:15 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513DFC1F.6010208@oracle.com> References: <5139E584.1050205@oracle.com> <513A367E.2000505@oracle.com> <513DEB85.9060807@oracle.com> <513DFC1F.6010208@oracle.com> Message-ID: <513EDD83.4040403@oracle.com> Hi Jon, On 3/11/13 4:45 PM, Jon Masamitsu wrote: > > > On 03/11/13 07:34, Bengt Rutisson wrote: >> >> Hi Jon, >> >> On 3/8/13 8:05 PM, Jon Masamitsu wrote: >>> Bengt, >>> >>> With your change the order is >>> >>> set_heap_size() >>> set_ergonomics_flags() >>> >>> set_ergonomics_flags() can turn on UseCompressedOops. >>> set_heap_size() uses UseCompressedOops >>> >>> Right? >>> >>> It might not be a problem today but it makes me nervous. >>> >>> Is there a real circularity there? I don't know but if there is >>> a way to exclude a circularity, then I won't have to think >>> about it. >> >> Thanks for spotting this, Jon! There is definitely a circular >> dependency between set_heap_size() and set_ergonomics_flags(). >> >> I could not figure out a nice and clean way of breaking the circular >> dependency. But the circular dependency actually originates from the >> fact that set_heap_size() does the check that the original bug >> reports as an issue. It reduces the max heap size if >> UseCompressedOops is enabled. The problem is that _after_ that it >> adjust the max heap size to be at least as large as the initial heap >> size. This is why we crash. >> >> So, one way to fix this is to use the knowledge that the initial heap >> size is the only thing in set_heap_size() that can increase the max >> heap size beyond what UseCompressedOops will work with. Here is a >> webrev for what that could look like: >> >> http://cr.openjdk.java.net/~brutisso/8001049/webrev.01/ > > Did you intend to call set_use_compressed_oops() before > set_heap_size() and set_ergonomics_flags()? In the webrev > the call to set_use_compressed_oops() is in > set_ergonmonics_flags(). I left the call to set_use_compressed_oops() inside set_ergonomics_flags() on purpose. This was both for minimizing the risk of the change (everything is now done in the exact same order as before) and for making sure that set_use_compressed_oops() has been called before we start reading UseCompressedOops inside set_ergonomics_flags(). I am not completely happy with how this looks. It might be better to move all of the compressed handling out of set_ergonomics_flags(), but if it is all right with you I would like to avoid that at the moment. > >> >> I think there is another circular dependency already present in the >> code. If you look at max_heap_for_compressed_oops() its >> implementation uses ClassMetaspaceSize. But this value may be updated >> a bit later in set_ergonomics_flags(): >> >> FLAG_SET_ERGO(uintx, ClassMetaspaceSize, 100*M); >> >> Is this a problem? It is not really related to my current change, but >> if it is a problem we should probably file a bug for it. > > I'll file a bug for this. Thanks. Great, thanks! Bengt > > Jon > >> >> Thanks again for looking at this! >> Bengt >> >>> >>> >>> Jon >>> >>> >>> On 3/8/2013 5:20 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this change please? >>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>> >>>> I'm sending this to both the GC and the runtime teams since I think >>>> compressed oops is mixed responsibility for both teams. >>>> >>>> Background (mostly from the bug report): >>>> >>>> Hotspot crashes if it is run with a large initial size: >>>> >>>> >./java -Xms70g -version >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>> tid=140305232803584 >>>> >>>> The reason is that we enable UseCompressedOops but we use the >>>> default value for ObjectAlignmentInBytes. With a large heap size we >>>> would have needed to adjust the object alignment to be able to use >>>> compressed oops. >>>> >>>> However, after reviewing the code it looks like the fix is not to >>>> try to adjust the object alignment but rather to not enable >>>> compressed oops for large heaps. If someone wants to use compressed >>>> oops on a very large heap they need to explicitly set both >>>> UseCompressedOops and ObjectAlignmentInBytes on the command line. >>>> As far as I can tell this is how it is intended to work. >>>> >>>> Here is the reason for the crash and the rational behind the fix: >>>> >>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>> size is small enough before we enable compressed oops: >>>> >>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>> #if !defined(COMPILER1) || defined(TIERED) >>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>> } >>>> #endif >>>> >>>> And after that we print a warning message if the heap is too large: >>>> >>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>> warning("Max heap size too large for Compressed Oops"); >>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>> } >>>> >>>> Now the problem is that when we don't set the max heap size on the >>>> command line it will be adjusted based on the initial size (-Xms) >>>> and this happens in Arguments::set_heap_size(), which is called >>>> *after* Arguments::set_ergonomics_flags() has been called. So, when >>>> we do the check against the max size in >>>> Arguments::set_ergonomics_flags(), we check against the default >>>> value for the max size. This value fits well with a compressed >>>> heap, so we enable compressed oops and crash later on when we can't >>>> address the upper part of the heap. >>>> >>>> The fix is to move the call to set_heap_size() to *before* the call >>>> to set_ergonomics_flags(). This way the check is done against the >>>> correct value. This has two effects: >>>> >>>> 1) We don't enable UseCompressedOops on heap sizes that are too large >>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>> specifies a too large heap a warning message will be logged and >>>> UseCompressedOops will be turned off. >>>> >>>> I am always hesitant to rearrange the order of calls in >>>> Arguments::parse(). But in this case it is necessary to get the >>>> correct behavior and I think it is safe. As far as I can tell there >>>> is no other code between the two methods that try to read the >>>> MaxHeapSize value. >>>> >>>> Thanks, >>>> Bengt >>>> >>> >> From bengt.rutisson at oracle.com Tue Mar 12 07:48:44 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 08:48:44 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513EDC05.1030807@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513A293D.8020702@oracle.com> <513DF0D2.8060408@oracle.com> <513E2441.3050709@oracle.com> <513EDC05.1030807@oracle.com> Message-ID: <513EDDDC.4090005@oracle.com> Updated webrev based on the comments from Vladimir, Jon and Harold: http://cr.openjdk.java.net/~brutisso/8001049/webrev.02/ Thanks, Bengt On 3/12/13 8:40 AM, Bengt Rutisson wrote: > > Hi Vladimir, > > On 3/11/13 7:36 PM, Vladimir Kozlov wrote: >> On 3/11/13 7:57 AM, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for looking at this! >>> >>> On 3/8/13 7:09 PM, Vladimir Kozlov wrote: >>>> I am wondering should we also add a check into >>>> Universe::reserve_heap() before calling >>>> Universe::preferred_heap_base(). >>> >>> Do you mean that we should add an assert in Universe::reserve_heap() to >>> check that the size we reserve is compatible with the compressed oop >> >> Yes, I want >> >> size_t total_reserved = align_size_up(heap_size + >> Universe::class_metaspace_size(), alignment); >> + assert(!UseCompressedOops || (total_reserved <= >> (OopEncodingHeapMax - os::vm_page_size())), "heap size is too big for >> compressed oops"); >> char* addr = Universe::preferred_heap_base(total_reserved, >> Universe::UnscaledNarrowOop); >> >> You don't need to duplicate max_heap_for_compressed_oops() because >> total_reserved includes class_metaspace. > > Thanks for this clarification! I added the assert. > >> There are size rounding codes in some places after arguments parsing >> and someone could add an other ergonomic code after checks during >> arguments parsing. To have an assert to catch such cases would be nice. > > Good point. Thanks for the help with this. > > Bengt > >> >> Thanks, >> Vladimir >> >>> state? I think that's fine but that means that I either have to >>> duplicate the code in max_heap_for_compressed_oops() or make it >>> publicly >>> available somewhere. Currently it is just a local function inside >>> Arguments.cpp. >>> >>> Personally I am not sure the assert will be worth the code change, but >>> I'm fine with adding it if you want to. >>> >>> Thanks, >>> Bengt >>> >>> >>>> >>>> Vladimir >>>> >>>> On 3/8/13 9:41 AM, harold seigel wrote: >>>>> The change looks good. Perhaps this problem wasn't seen before >>>>> because >>>>> this scenario hadn't been tested? >>>>> >>>>> Harold >>>>> >>>>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>>>> The change is reasonable. >>>>>> >>>>>> So why we did not see this problem before? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews for this change please? >>>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>>> >>>>>>> I'm sending this to both the GC and the runtime teams since I think >>>>>>> compressed oops is mixed responsibility for both teams. >>>>>>> >>>>>>> Background (mostly from the bug report): >>>>>>> >>>>>>> Hotspot crashes if it is run with a large initial size: >>>>>>> >>>>>>> >./java -Xms70g -version >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>>> tid=140305232803584 >>>>>>> >>>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>>> default >>>>>>> value for ObjectAlignmentInBytes. With a large heap size we >>>>>>> would have >>>>>>> needed to adjust the object alignment to be able to use compressed >>>>>>> oops. >>>>>>> >>>>>>> However, after reviewing the code it looks like the fix is not to >>>>>>> try to >>>>>>> adjust the object alignment but rather to not enable compressed >>>>>>> oops for >>>>>>> large heaps. If someone wants to use compressed oops on a very >>>>>>> large >>>>>>> heap they need to explicitly set both UseCompressedOops and >>>>>>> ObjectAlignmentInBytes on the command line. As far as I can tell >>>>>>> this is >>>>>>> how it is intended to work. >>>>>>> >>>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>>> >>>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>>> size is >>>>>>> small enough before we enable compressed oops: >>>>>>> >>>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>>> } >>>>>>> #endif >>>>>>> >>>>>>> And after that we print a warning message if the heap is too large: >>>>>>> >>>>>>> if (UseCompressedOops && >>>>>>> !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>>> } >>>>>>> >>>>>>> Now the problem is that when we don't set the max heap size on the >>>>>>> command line it will be adjusted based on the initial size >>>>>>> (-Xms) and >>>>>>> this happens in Arguments::set_heap_size(), which is called *after* >>>>>>> Arguments::set_ergonomics_flags() has been called. So, when we >>>>>>> do the >>>>>>> check against the max size in Arguments::set_ergonomics_flags(), we >>>>>>> check against the default value for the max size. This value >>>>>>> fits well >>>>>>> with a compressed heap, so we enable compressed oops and crash >>>>>>> later on >>>>>>> when we can't address the upper part of the heap. >>>>>>> >>>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>>> call to >>>>>>> set_ergonomics_flags(). This way the check is done against the >>>>>>> correct >>>>>>> value. This has two effects: >>>>>>> >>>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>>> large >>>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>>> specifies a too large heap a warning message will be logged and >>>>>>> UseCompressedOops will be turned off. >>>>>>> >>>>>>> I am always hesitant to rearrange the order of calls in >>>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>>> correct >>>>>>> behavior and I think it is safe. As far as I can tell there is no >>>>>>> other >>>>>>> code between the two methods that try to read the MaxHeapSize >>>>>>> value. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>> >>> > From mikael.gerdin at oracle.com Tue Mar 12 09:42:20 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 10:42:20 +0100 Subject: Review request (XS): JDK-8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation In-Reply-To: <513E7CB7.9030508@oracle.com> References: <513DD83F.6000807@oracle.com> <513E23F4.3040107@oracle.com> <513E7CB7.9030508@oracle.com> Message-ID: <513EF87C.3010207@oracle.com> Tao On 2013-03-12 01:54, Tao Mao wrote: > Looks good to me, too. As safety check, did you test the change clear on > any machine you previously were able to reproduce the bug? Yes I did. I also did a JPRT stree run. I've put this in the jprt queue now. Thanks for the reviews Stefan, Jon and Tao. /Mikael > Tao > > On 3/11/2013 11:35 AM, Jon Masamitsu wrote: >> Looks good. >> >> Jon >> >> On 03/11/13 06:12, Mikael Gerdin wrote: >>> Hi, >>> >>> Please review this small fix for an incorrect assert that can trigger >>> when we run out of metaspace memory. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8009282/webrev.0/ >>> >>> >>> The reasoning behind this change is that when running with the >>> command line flags specified in the bug report we call >>> MetaspaceAux::print_on when we're about to throw an >>> j.l.OutOfMemoryError. At that point another thread may be successful >>> in allocating metaspace memory in another class loader or smaller >>> memory chunks which are available. >>> >>> The assert condition must only hold when the VM is at a safe point >>> and no other thread may be allocating metaspace memory. >>> >>> Thanks >>> /Mikael > From mikael.gerdin at oracle.com Tue Mar 12 09:44:51 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 10:44:51 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513E0724.9010404@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> <513DF739.6010900@oracle.com> <513E0353.60902@oracle.com> <513E0724.9010404@oracle.com> Message-ID: <513EF913.9070303@oracle.com> On 2013-03-11 17:32, Jon Masamitsu wrote: > > > On 03/11/13 09:16, Mikael Gerdin wrote: >> Jon, >> >> On 2013-03-11 16:24, Jon Masamitsu wrote: >>> Mikael, >>> >>> Changes look good. >> Thanks >> >>> >>> Your change of the assertion at the end of >>> Metaspace compute_new_size brought >>> something to mind. This is separate from >>> your changes, but do you think the >>> Metaspace compute_new_size() should take >>> the expand_lock()? As you note classes are >>> being loaded and metadata is being allocated. >>> The high-water-mark (capacity_until_GC) is >>> being changed in compute_new_size() and >>> being read in the should_expand() method. >>> I don't think it will make a difference. >> >> It's interesting that you suggest this. >> I had a MutexLocker on the expand_lock() in my earlier versions but I >> had completely forgotten why I put it there. >> In the end I didn't move any of the calls to compute_new_size so I >> thought I'd skip the locking since I couldn't see any new obvious >> problems with it removed. > > That's fine with me. > >> >> But in principle I agree that we should probably hold expand_lock() in >> compute_new_size, but only as long as we only look at the metaspace on >> the level which is protected by that lock. >> If we start looking at individual chunks and their usage we'll need to >> take the appropriate metaspace_lock and not only the expand_lock. > > Right. compute_new_size() is more globals than any particular > Metaspace so only the expand_lock would be appropriate at > this point. > > Again, looks good. Thanks Jon. I need one more review for this change. Any takers? /Mikael > > Jon > >> >> /Mikael >> >>> >>> Jon >>> >>> On 03/11/13 06:08, Mikael Gerdin wrote: >>>> Anyone? >>>> >>>> On 2013-03-04 15:44, Mikael Gerdin wrote: >>>>> Hi all, >>>>> >>>>> Please review this change to enable CMS to hand back memory for >>>>> unloaded >>>>> classes when running in concurrent mode. >>>>> >>>>> Bug link: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >>>>> >>>>> >>>>> The core change in this patch is the inserted call in sweep(): >>>>> 6101 >>>>> 6102 if (should_unload_classes()) { >>>>> 6103 ClassLoaderDataGraph::purge(); >>>>> 6104 } >>>>> 6105 >>>>> >>>>> This is needed because even though we claim to perform "class >>>>> unloading" >>>>> in the final remark phase we can't deallocate the memory for classes >>>>> until after we've performed the sweep phase since the sweeper needs to >>>>> find the size of objects even though they and their class is not >>>>> considered live anymore. >>>>> >>>>> The rest of the changes in concurrentMarkSweepGeneration.cpp only >>>>> relate >>>>> to logging information about released metaspace memory and cms gen >>>>> occupancy to make it easier to analyze what's happening. An example of >>>>> this new logging output is: >>>>> >>>>> 134.069: [CMS-concurrent-sweep-start] >>>>> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >>>>> sys=0.02, real=0.01 secs] >>>>> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >>>>> 277487K->133228K(370885K/412976K)] ] >>>>> 134.166: [CMS-concurrent-reset-start] >>>>> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >>>>> sys=0.00, real=0.02 secs] >>>>> >>>>> The change in genCollectedHeap.cpp is needed to avoid artificially >>>>> inflating the size of the Metaspace memory, since memory is considered >>>>> "used" until purge() has been called. By calling purge() before >>>>> compute_new_size() (as the other collectors do) we use the correct >>>>> figures. >>>>> >>>>> The disabled assert in metaspace.cpp is faulty because a thread may be >>>>> allocating classes and expanding the metaspace memory while we are in >>>>> compute_new_size, I've verified that this assert can in fact fail on a >>>>> build without these changes. >>>>> The change in ~SpaceManager is because of lock order restrictions, >>>>> sum_capacity_in_chunks_in_use takes the Metaspace lock and would do it >>>>> out of order with regards to the expand_lock. >>>>> >>>>> I've tested these changes primarily by running the >>>>> ParallelClassLoading >>>>> tests with a small young gen size to enable regular class unloading >>>>> cycles. >>>>> >>>>> Thanks >>>>> /Mikael From thomas.schatzl at oracle.com Tue Mar 12 10:13:37 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 12 Mar 2013 11:13:37 +0100 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <513E4E3E.4020405@oracle.com> References: <513E4E3E.4020405@oracle.com> Message-ID: <1363083217.2540.46.camel@cirrus> Hi, On Mon, 2013-03-11 at 14:35 -0700, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review these changes? The webrev can > be found at: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/. > - maybe in concurrentMark.cpp you can now replace 992: reset_marking_state(concurrent() /* clear_overflow */); by reset_marking_state(true /* clear_overflow */); As the whole block is guarded by that. Not sure if it is better, but when reading the code with that change you don't need to think what the value of concurrent() is. Keeping it is as fine. - I'm slightly confused by using the "serial" G1CMKeepAliveAndDrainClosure and G1CMDrainMarkingStackClosure closures (that don't synchronize with other threads) in weakRefsWork() at line 2465 and 2466. Or at least the comment above it. So, this "is_serial" flag indicates to the do_marking_step() that it should not try to synchronize with concurrent mark threads when terminating, as there are none. There are still the parallel work gang threads using these "is_serial" closures for processing (by the partaskexecutor used in process_discovered_references()). Following the code, in the parallel case, if a thread spawned by weakRefsWork() fails "fails" due to mark stack overflow, it does not try to synchronize with others. Mainly because the work gang it is running in (in Workgang::run_task()) that waits for all threads anyway. (Couldn't this synchronization potentially take a long time as e.g. one thread is able to completely finish work using local buffers as others are waiting on it?) Then, regardless of parallelism, two (or three) caller levels above in ConcurrentMarkThread::run(), after the vm thread finishes the safepoint, the current code will notice that there has been an overflow during remark and do another safepoint. (Is there a reason to schedule another safepoint to recover from a marking overflow? This involves a back-to-back safepoint. Is this cheaper than just retrying in the current safepoint?) What do you think of renaming that flag? Maybe something like "synchronize_with_cm_threads". Unfortunately I cannot come up with a better, more generic name, as do_marking_step() does exactly that, and that's what the change wants to avoid (well, it has the flag the other way around). The problem seems to be that do_marking_step() as is now is too much geared towards use in the concurrent marking threads, it uses a lot of details from it. And the current code reuses do_marking_step() although it's not running in the marking threads. So another option could be to extract the concurrent marking thread specific stuff (e.g. termination) from do_marking_step() into a helper class/interface and pass a suitable implementation for each of its uses. Instead of the many _cm-> references in do_marking_step, call appropriate methods of that. But that would be quite some additional work... (and I didn't think it through, just a thought) Anyway, could the comment above these lines changed as the current comment indicates (to me) that the closures are run by the vmthread. E.g. instead of 2463:// Serial (i.e executed by VMThread) instances of the 'Keep Alive' 2464:// and 'Complete GC' closures. use something like: // These closures do not need to synchronize with concurrent marking // threads as this code is either run serially by this thread (e.g. // processing_is_mt is false which uses the VM thread), or the worker // gang tasks which have their own synchronization. - one other minor thing in concurrentMark.cpp: 4317: bool finished = (is_serial ? true :_cm->terminator()->offer_termination(this)); Maybe change this to bool finished = (is_serial || _cm->terminator()->offer_termination(this)); While this is no different, I actually had to pause and think what the intent of the use of the "?" operator was here :) It seems easier to read and more common to to not use the "?" operator in such cases. Thomas From stefan.karlsson at oracle.com Tue Mar 12 12:20:22 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Mar 2013 13:20:22 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513EF913.9070303@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> <513DF739.6010900@oracle.com> <513E0353.60902@oracle.com> <513E0724.9010404@oracle.com> <513EF913.9070303@oracle.com> Message-ID: <513F1D86.20400@oracle.com> On 03/12/2013 10:44 AM, Mikael Gerdin wrote: > > > On 2013-03-11 17:32, Jon Masamitsu wrote: >> >> >> On 03/11/13 09:16, Mikael Gerdin wrote: >>> Jon, >>> >>> On 2013-03-11 16:24, Jon Masamitsu wrote: >>>> Mikael, >>>> >>>> Changes look good. >>> Thanks >>> >>>> >>>> Your change of the assertion at the end of >>>> Metaspace compute_new_size brought >>>> something to mind. This is separate from >>>> your changes, but do you think the >>>> Metaspace compute_new_size() should take >>>> the expand_lock()? As you note classes are >>>> being loaded and metadata is being allocated. >>>> The high-water-mark (capacity_until_GC) is >>>> being changed in compute_new_size() and >>>> being read in the should_expand() method. >>>> I don't think it will make a difference. >>> >>> It's interesting that you suggest this. >>> I had a MutexLocker on the expand_lock() in my earlier versions but I >>> had completely forgotten why I put it there. >>> In the end I didn't move any of the calls to compute_new_size so I >>> thought I'd skip the locking since I couldn't see any new obvious >>> problems with it removed. >> >> That's fine with me. >> >>> >>> But in principle I agree that we should probably hold expand_lock() in >>> compute_new_size, but only as long as we only look at the metaspace on >>> the level which is protected by that lock. >>> If we start looking at individual chunks and their usage we'll need to >>> take the appropriate metaspace_lock and not only the expand_lock. >> >> Right. compute_new_size() is more globals than any particular >> Metaspace so only the expand_lock would be appropriate at >> this point. >> >> Again, looks good. > > Thanks Jon. > > I need one more review for this change. Any takers? Mikael guided me through these changes, and I think this looks good. Though, I would prefer if the print changes were pushed in a separate changeset. StefanK > > /Mikael > >> >> Jon >> >>> >>> /Mikael >>> >>>> >>>> Jon >>>> >>>> On 03/11/13 06:08, Mikael Gerdin wrote: >>>>> Anyone? >>>>> >>>>> On 2013-03-04 15:44, Mikael Gerdin wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change to enable CMS to hand back memory for >>>>>> unloaded >>>>>> classes when running in concurrent mode. >>>>>> >>>>>> Bug link: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >>>>>> >>>>>> >>>>>> The core change in this patch is the inserted call in sweep(): >>>>>> 6101 >>>>>> 6102 if (should_unload_classes()) { >>>>>> 6103 ClassLoaderDataGraph::purge(); >>>>>> 6104 } >>>>>> 6105 >>>>>> >>>>>> This is needed because even though we claim to perform "class >>>>>> unloading" >>>>>> in the final remark phase we can't deallocate the memory for classes >>>>>> until after we've performed the sweep phase since the sweeper >>>>>> needs to >>>>>> find the size of objects even though they and their class is not >>>>>> considered live anymore. >>>>>> >>>>>> The rest of the changes in concurrentMarkSweepGeneration.cpp only >>>>>> relate >>>>>> to logging information about released metaspace memory and cms gen >>>>>> occupancy to make it easier to analyze what's happening. An >>>>>> example of >>>>>> this new logging output is: >>>>>> >>>>>> 134.069: [CMS-concurrent-sweep-start] >>>>>> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >>>>>> sys=0.02, real=0.01 secs] >>>>>> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >>>>>> 277487K->133228K(370885K/412976K)] ] >>>>>> 134.166: [CMS-concurrent-reset-start] >>>>>> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >>>>>> sys=0.00, real=0.02 secs] >>>>>> >>>>>> The change in genCollectedHeap.cpp is needed to avoid artificially >>>>>> inflating the size of the Metaspace memory, since memory is >>>>>> considered >>>>>> "used" until purge() has been called. By calling purge() before >>>>>> compute_new_size() (as the other collectors do) we use the correct >>>>>> figures. >>>>>> >>>>>> The disabled assert in metaspace.cpp is faulty because a thread >>>>>> may be >>>>>> allocating classes and expanding the metaspace memory while we >>>>>> are in >>>>>> compute_new_size, I've verified that this assert can in fact fail >>>>>> on a >>>>>> build without these changes. >>>>>> The change in ~SpaceManager is because of lock order restrictions, >>>>>> sum_capacity_in_chunks_in_use takes the Metaspace lock and would >>>>>> do it >>>>>> out of order with regards to the expand_lock. >>>>>> >>>>>> I've tested these changes primarily by running the >>>>>> ParallelClassLoading >>>>>> tests with a small young gen size to enable regular class unloading >>>>>> cycles. >>>>>> >>>>>> Thanks >>>>>> /Mikael From mikael.gerdin at oracle.com Tue Mar 12 12:35:21 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Tue, 12 Mar 2013 12:35:21 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Message-ID: <20130312123527.B9DA4480A3@hg.openjdk.java.net> Changeset: 1c88b99a2b01 Author: mgerdin Date: 2013-03-12 09:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1c88b99a2b01 8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Summary: Assertion is only valid when at a safepoint, adjust accordingly. Reviewed-by: stefank, jmasa, tamao ! src/share/vm/memory/metaspace.cpp From mikael.gerdin at oracle.com Tue Mar 12 12:45:18 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 13:45:18 +0100 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed In-Reply-To: <1362639401.2659.3.camel@cirrus> References: <1362571695.2599.23.camel@cirrus> <513777ED.6030209@oracle.com> <1362639401.2659.3.camel@cirrus> Message-ID: <513F235E.8070908@oracle.com> Thomas, On 2013-03-07 07:56, Thomas Schatzl wrote: > Hi, > > new webrev at > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8008684/webrev.1/ > > Passes jprt. Looks good to me. It's good that this gets cleaned up. /Mikael > > Note that tty->stamp(bool) automatically adds the colons, so I removed > them from the string. > > Hth, > Thomas > > On Wed, 2013-03-06 at 09:07 -0800, Jon Masamitsu wrote: >> Thomas, >> >> I've added a comment to the bug report to clarify what >> I think should be changed. Sorry that my original description >> was lacking. Please take a look and let me know if it is >> still not clear. >> >> Jon >> >> On 3/6/2013 4:08 AM, Thomas Schatzl wrote: >>> Hi all, >>> >>> this change always adds a timestamp marker for CMS concurrent phase >>> messages as suggested by the CR. >>> I added an extra space between timestamp and the original message for >>> better readability. >>> >>> I.e. instead of printing >>> >>> [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 sys=0.00, >>> real=0.09 secs] >>> [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 sys=0.00, >>> real=0.00 secs] >>> >>> the VM now prints >>> >>> 20.014 [CMS-concurrent-mark: 0.081/0.081 secs] [Times: user=0.16 >>> sys=0.00, real=0.09 secs] >>> 20.019 [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.01 >>> sys=0.00, real=0.00 secs] >>> >>> if -XX:+PrintGCDetails is set with CMS. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8008684/webrev/ >>> >>> Bugs >>> http://bugs.sun.com/view_bug.do?bug_id=8008684 >>> >>> JIRA: >>> https://jbs.oracle.com/bugs/browse/JDK-8008684 >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Thomas >>> >> > > From bengt.rutisson at oracle.com Tue Mar 12 12:45:29 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 13:45:29 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <7e829440-65ac-41ea-802b-e7401c44e8ff@default> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513A293D.8020702@oracle.com> <513DF0D2.8060408@oracle.com> <513E2441.3050709@oracle.com> <513EDC05.1030807@oracle.com> <7e829440-65ac-41ea-802b-e7401c44e8ff@default> Message-ID: <513F2369.6030107@oracle.com> Hi Christian, Thanks for verifying this change! I agree that the results look like what we want. Thanks again for doing the extra testing! Bengt On 3/12/13 1:11 PM, Christian T?rnqvist wrote: > Hi Bengt, > > Did some sanity testing using one of your builds vs jdk8-b79 on a Linux x64 machine (sthoel01.se.oracle.com which has 144GB of memory): > > -Xms50g -Xmx60g No difference, no coops > -Xms50g -Xmx60g -XX:+UseCompressedOops, No difference, no coops, warning printed: "Max heap size too large for Compressed Oops" > -Xms50g -Xmx60g -XX:+UseCompressedOops -XX:ObjectAlignmentInBytes=16, No difference, coops enabled > -Xms50g -Xmx60g -XX:ObjectAlignmentInBytes=16, No difference, coops enabled > > -Xms50g jdk8-b79 crashes, fixed jvm starts without coops and no warning messages > -Xms50g -XX:+UseCompressedOops jdk8-b79 crashes, fixed jvm prints warning: "Max heap size too large for Compressed Oops" > -Xms50g -XX:+UseCompressedOops -XX:ObjectAlignmentInBytes=16, No difference, coops enabled > -Xms50g -XX:ObjectAlignmentInBytes=16, No difference, coops enabled > > Code change looks good and behavior seems consistent with earlier versions. > > Thanks, > Christian > > -----Original Message----- > From: Bengt Rutisson > Sent: den 12 mars 2013 08:41 > To: Vladimir Kozlov > Cc: hotspot-gc-dev openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes > > > Hi Vladimir, > > On 3/11/13 7:36 PM, Vladimir Kozlov wrote: >> On 3/11/13 7:57 AM, Bengt Rutisson wrote: >>> Hi Vladimir, >>> >>> Thanks for looking at this! >>> >>> On 3/8/13 7:09 PM, Vladimir Kozlov wrote: >>>> I am wondering should we also add a check into >>>> Universe::reserve_heap() before calling >>>> Universe::preferred_heap_base(). >>> Do you mean that we should add an assert in Universe::reserve_heap() >>> to check that the size we reserve is compatible with the compressed >>> oop >> Yes, I want >> >> size_t total_reserved = align_size_up(heap_size + >> Universe::class_metaspace_size(), alignment); >> + assert(!UseCompressedOops || (total_reserved <= (OopEncodingHeapMax >> - os::vm_page_size())), "heap size is too big for compressed oops"); >> char* addr = Universe::preferred_heap_base(total_reserved, >> Universe::UnscaledNarrowOop); >> >> You don't need to duplicate max_heap_for_compressed_oops() because >> total_reserved includes class_metaspace. > Thanks for this clarification! I added the assert. > >> There are size rounding codes in some places after arguments parsing >> and someone could add an other ergonomic code after checks during >> arguments parsing. To have an assert to catch such cases would be nice. > Good point. Thanks for the help with this. > > Bengt > >> Thanks, >> Vladimir >> >>> state? I think that's fine but that means that I either have to >>> duplicate the code in max_heap_for_compressed_oops() or make it >>> publicly available somewhere. Currently it is just a local function >>> inside Arguments.cpp. >>> >>> Personally I am not sure the assert will be worth the code change, >>> but I'm fine with adding it if you want to. >>> >>> Thanks, >>> Bengt >>> >>> >>>> Vladimir >>>> >>>> On 3/8/13 9:41 AM, harold seigel wrote: >>>>> The change looks good. Perhaps this problem wasn't seen before >>>>> because this scenario hadn't been tested? >>>>> >>>>> Harold >>>>> >>>>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>>>> The change is reasonable. >>>>>> >>>>>> So why we did not see this problem before? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews for this change please? >>>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>>> >>>>>>> I'm sending this to both the GC and the runtime teams since I >>>>>>> think compressed oops is mixed responsibility for both teams. >>>>>>> >>>>>>> Background (mostly from the bug report): >>>>>>> >>>>>>> Hotspot crashes if it is run with a large initial size: >>>>>>> >>>>>>> >./java -Xms70g -version >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>>> tid=140305232803584 >>>>>>> >>>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>>> default value for ObjectAlignmentInBytes. With a large heap size >>>>>>> we would have needed to adjust the object alignment to be able to >>>>>>> use compressed oops. >>>>>>> >>>>>>> However, after reviewing the code it looks like the fix is not to >>>>>>> try to adjust the object alignment but rather to not enable >>>>>>> compressed oops for large heaps. If someone wants to use >>>>>>> compressed oops on a very large heap they need to explicitly set >>>>>>> both UseCompressedOops and ObjectAlignmentInBytes on the command >>>>>>> line. As far as I can tell this is how it is intended to work. >>>>>>> >>>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>>> >>>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>>> size is small enough before we enable compressed oops: >>>>>>> >>>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { #if >>>>>>> !defined(COMPILER1) || defined(TIERED) >>>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>>> } >>>>>>> #endif >>>>>>> >>>>>>> And after that we print a warning message if the heap is too large: >>>>>>> >>>>>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>>> } >>>>>>> >>>>>>> Now the problem is that when we don't set the max heap size on >>>>>>> the command line it will be adjusted based on the initial size >>>>>>> (-Xms) and this happens in Arguments::set_heap_size(), which is >>>>>>> called *after* >>>>>>> Arguments::set_ergonomics_flags() has been called. So, when we do >>>>>>> the check against the max size in >>>>>>> Arguments::set_ergonomics_flags(), we check against the default >>>>>>> value for the max size. This value fits well with a compressed >>>>>>> heap, so we enable compressed oops and crash later on when we >>>>>>> can't address the upper part of the heap. >>>>>>> >>>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>>> call to set_ergonomics_flags(). This way the check is done >>>>>>> against the correct value. This has two effects: >>>>>>> >>>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>>> large >>>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>>> specifies a too large heap a warning message will be logged and >>>>>>> UseCompressedOops will be turned off. >>>>>>> >>>>>>> I am always hesitant to rearrange the order of calls in >>>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>>> correct behavior and I think it is safe. As far as I can tell >>>>>>> there is no other code between the two methods that try to read >>>>>>> the MaxHeapSize value. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt From mikael.gerdin at oracle.com Tue Mar 12 12:45:54 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 13:45:54 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513F1D86.20400@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> <513DF739.6010900@oracle.com> <513E0353.60902@oracle.com> <513E0724.9010404@oracle.com> <513EF913.9070303@oracle.com> <513F1D86.20400@oracle.com> Message-ID: <513F2382.7030707@oracle.com> Stefan, On 2013-03-12 13:20, Stefan Karlsson wrote: > On 03/12/2013 10:44 AM, Mikael Gerdin wrote: >> >> >> On 2013-03-11 17:32, Jon Masamitsu wrote: >>> >>> >>> On 03/11/13 09:16, Mikael Gerdin wrote: >>>> Jon, >>>> >>>> On 2013-03-11 16:24, Jon Masamitsu wrote: >>>>> Mikael, >>>>> >>>>> Changes look good. >>>> Thanks >>>> >>>>> >>>>> Your change of the assertion at the end of >>>>> Metaspace compute_new_size brought >>>>> something to mind. This is separate from >>>>> your changes, but do you think the >>>>> Metaspace compute_new_size() should take >>>>> the expand_lock()? As you note classes are >>>>> being loaded and metadata is being allocated. >>>>> The high-water-mark (capacity_until_GC) is >>>>> being changed in compute_new_size() and >>>>> being read in the should_expand() method. >>>>> I don't think it will make a difference. >>>> >>>> It's interesting that you suggest this. >>>> I had a MutexLocker on the expand_lock() in my earlier versions but I >>>> had completely forgotten why I put it there. >>>> In the end I didn't move any of the calls to compute_new_size so I >>>> thought I'd skip the locking since I couldn't see any new obvious >>>> problems with it removed. >>> >>> That's fine with me. >>> >>>> >>>> But in principle I agree that we should probably hold expand_lock() in >>>> compute_new_size, but only as long as we only look at the metaspace on >>>> the level which is protected by that lock. >>>> If we start looking at individual chunks and their usage we'll need to >>>> take the appropriate metaspace_lock and not only the expand_lock. >>> >>> Right. compute_new_size() is more globals than any particular >>> Metaspace so only the expand_lock would be appropriate at >>> this point. >>> >>> Again, looks good. >> >> Thanks Jon. >> >> I need one more review for this change. Any takers? > > Mikael guided me through these changes, and I think this looks good. Thanks for the review. > > Though, I would prefer if the print changes were pushed in a separate > changeset. Since these changes will also conflict with Thomas' fix for 8008684 I will back out the logging changes and fix them in a separate CR. /Mikael > > StefanK > >> >> /Mikael >> >>> >>> Jon >>> >>>> >>>> /Mikael >>>> >>>>> >>>>> Jon >>>>> >>>>> On 03/11/13 06:08, Mikael Gerdin wrote: >>>>>> Anyone? >>>>>> >>>>>> On 2013-03-04 15:44, Mikael Gerdin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change to enable CMS to hand back memory for >>>>>>> unloaded >>>>>>> classes when running in concurrent mode. >>>>>>> >>>>>>> Bug link: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >>>>>>> >>>>>>> >>>>>>> The core change in this patch is the inserted call in sweep(): >>>>>>> 6101 >>>>>>> 6102 if (should_unload_classes()) { >>>>>>> 6103 ClassLoaderDataGraph::purge(); >>>>>>> 6104 } >>>>>>> 6105 >>>>>>> >>>>>>> This is needed because even though we claim to perform "class >>>>>>> unloading" >>>>>>> in the final remark phase we can't deallocate the memory for classes >>>>>>> until after we've performed the sweep phase since the sweeper >>>>>>> needs to >>>>>>> find the size of objects even though they and their class is not >>>>>>> considered live anymore. >>>>>>> >>>>>>> The rest of the changes in concurrentMarkSweepGeneration.cpp only >>>>>>> relate >>>>>>> to logging information about released metaspace memory and cms gen >>>>>>> occupancy to make it easier to analyze what's happening. An >>>>>>> example of >>>>>>> this new logging output is: >>>>>>> >>>>>>> 134.069: [CMS-concurrent-sweep-start] >>>>>>> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >>>>>>> sys=0.02, real=0.01 secs] >>>>>>> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >>>>>>> 277487K->133228K(370885K/412976K)] ] >>>>>>> 134.166: [CMS-concurrent-reset-start] >>>>>>> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >>>>>>> sys=0.00, real=0.02 secs] >>>>>>> >>>>>>> The change in genCollectedHeap.cpp is needed to avoid artificially >>>>>>> inflating the size of the Metaspace memory, since memory is >>>>>>> considered >>>>>>> "used" until purge() has been called. By calling purge() before >>>>>>> compute_new_size() (as the other collectors do) we use the correct >>>>>>> figures. >>>>>>> >>>>>>> The disabled assert in metaspace.cpp is faulty because a thread >>>>>>> may be >>>>>>> allocating classes and expanding the metaspace memory while we >>>>>>> are in >>>>>>> compute_new_size, I've verified that this assert can in fact fail >>>>>>> on a >>>>>>> build without these changes. >>>>>>> The change in ~SpaceManager is because of lock order restrictions, >>>>>>> sum_capacity_in_chunks_in_use takes the Metaspace lock and would >>>>>>> do it >>>>>>> out of order with regards to the expand_lock. >>>>>>> >>>>>>> I've tested these changes primarily by running the >>>>>>> ParallelClassLoading >>>>>>> tests with a small young gen size to enable regular class unloading >>>>>>> cycles. >>>>>>> >>>>>>> Thanks >>>>>>> /Mikael > From mikael.gerdin at oracle.com Tue Mar 12 13:05:03 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 14:05:03 +0100 Subject: RFR: 8009763 Add WB test for String.intern() In-Reply-To: <513ED867.2070902@oracle.com> References: <513ED867.2070902@oracle.com> Message-ID: <513F27FF.5080607@oracle.com> Hi Leonid, On 2013-03-12 08:25, Leonid Mesnik wrote: > Hi > I've added a small test which: > 1) creates java string and intern it > 2) verify that it presents in StringTable > 3) clear reference and call fullGC > 4) verify that there is no such string in StringTable > > Here is webrev: > http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.0/ Overall this looks reasonable. I have some comments though: WB_IsInStringTable is defined to return a jboolean (Ljava/lang/String;)Z but the actual function is defined to return an jint. This will probably work but you should fix this to make it consistent. The function WB_fullGC should have a capital F to be consistent with the naming of the other WB_* functions. > > Tested locally and by JPRT > did you run jprt with -retest '*-*-*-runtime/interned' as well? /Mikael From mikael.gerdin at oracle.com Tue Mar 12 13:32:54 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 14:32:54 +0100 Subject: Request for review: JDK-8005602 NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used In-Reply-To: <513F2382.7030707@oracle.com> References: <5134B367.8020708@oracle.com> <513DD731.7050707@oracle.com> <513DF739.6010900@oracle.com> <513E0353.60902@oracle.com> <513E0724.9010404@oracle.com> <513EF913.9070303@oracle.com> <513F1D86.20400@oracle.com> <513F2382.7030707@oracle.com> Message-ID: <513F2E86.3080304@oracle.com> On 2013-03-12 13:45, Mikael Gerdin wrote: > Stefan, > > On 2013-03-12 13:20, Stefan Karlsson wrote: >> On 03/12/2013 10:44 AM, Mikael Gerdin wrote: >>> >>> >>> On 2013-03-11 17:32, Jon Masamitsu wrote: >>>> >>>> >>>> On 03/11/13 09:16, Mikael Gerdin wrote: >>>>> Jon, >>>>> >>>>> On 2013-03-11 16:24, Jon Masamitsu wrote: >>>>>> Mikael, >>>>>> >>>>>> Changes look good. >>>>> Thanks >>>>> >>>>>> >>>>>> Your change of the assertion at the end of >>>>>> Metaspace compute_new_size brought >>>>>> something to mind. This is separate from >>>>>> your changes, but do you think the >>>>>> Metaspace compute_new_size() should take >>>>>> the expand_lock()? As you note classes are >>>>>> being loaded and metadata is being allocated. >>>>>> The high-water-mark (capacity_until_GC) is >>>>>> being changed in compute_new_size() and >>>>>> being read in the should_expand() method. >>>>>> I don't think it will make a difference. >>>>> >>>>> It's interesting that you suggest this. >>>>> I had a MutexLocker on the expand_lock() in my earlier versions but I >>>>> had completely forgotten why I put it there. >>>>> In the end I didn't move any of the calls to compute_new_size so I >>>>> thought I'd skip the locking since I couldn't see any new obvious >>>>> problems with it removed. >>>> >>>> That's fine with me. >>>> >>>>> >>>>> But in principle I agree that we should probably hold expand_lock() in >>>>> compute_new_size, but only as long as we only look at the metaspace on >>>>> the level which is protected by that lock. >>>>> If we start looking at individual chunks and their usage we'll need to >>>>> take the appropriate metaspace_lock and not only the expand_lock. >>>> >>>> Right. compute_new_size() is more globals than any particular >>>> Metaspace so only the expand_lock would be appropriate at >>>> this point. >>>> >>>> Again, looks good. >>> >>> Thanks Jon. >>> >>> I need one more review for this change. Any takers? >> >> Mikael guided me through these changes, and I think this looks good. > > Thanks for the review. > >> >> Though, I would prefer if the print changes were pushed in a separate >> changeset. > > Since these changes will also conflict with Thomas' fix for 8008684 I > will back out the logging changes and fix them in a separate CR. For reference, the changes with the logging reverted are: http://cr.openjdk.java.net/~mgerdin/8005602/webrev.5/ /Mikael > > /Mikael > >> >> StefanK >> >>> >>> /Mikael >>> >>>> >>>> Jon >>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Jon >>>>>> >>>>>> On 03/11/13 06:08, Mikael Gerdin wrote: >>>>>>> Anyone? >>>>>>> >>>>>>> On 2013-03-04 15:44, Mikael Gerdin wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this change to enable CMS to hand back memory for >>>>>>>> unloaded >>>>>>>> classes when running in concurrent mode. >>>>>>>> >>>>>>>> Bug link: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005602 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8005602/webrev.4/ >>>>>>>> >>>>>>>> >>>>>>>> The core change in this patch is the inserted call in sweep(): >>>>>>>> 6101 >>>>>>>> 6102 if (should_unload_classes()) { >>>>>>>> 6103 ClassLoaderDataGraph::purge(); >>>>>>>> 6104 } >>>>>>>> 6105 >>>>>>>> >>>>>>>> This is needed because even though we claim to perform "class >>>>>>>> unloading" >>>>>>>> in the final remark phase we can't deallocate the memory for >>>>>>>> classes >>>>>>>> until after we've performed the sweep phase since the sweeper >>>>>>>> needs to >>>>>>>> find the size of objects even though they and their class is not >>>>>>>> considered live anymore. >>>>>>>> >>>>>>>> The rest of the changes in concurrentMarkSweepGeneration.cpp only >>>>>>>> relate >>>>>>>> to logging information about released metaspace memory and cms gen >>>>>>>> occupancy to make it easier to analyze what's happening. An >>>>>>>> example of >>>>>>>> this new logging output is: >>>>>>>> >>>>>>>> 134.069: [CMS-concurrent-sweep-start] >>>>>>>> 134.073: [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 >>>>>>>> sys=0.02, real=0.01 secs] >>>>>>>> 134.164: [CMS-resizing: [CMS: 532K->382K(63488K)], [Metaspace: >>>>>>>> 277487K->133228K(370885K/412976K)] ] >>>>>>>> 134.166: [CMS-concurrent-reset-start] >>>>>>>> 134.179: [CMS-concurrent-reset: 0.014/0.014 secs] [Times: user=0.02 >>>>>>>> sys=0.00, real=0.02 secs] >>>>>>>> >>>>>>>> The change in genCollectedHeap.cpp is needed to avoid artificially >>>>>>>> inflating the size of the Metaspace memory, since memory is >>>>>>>> considered >>>>>>>> "used" until purge() has been called. By calling purge() before >>>>>>>> compute_new_size() (as the other collectors do) we use the correct >>>>>>>> figures. >>>>>>>> >>>>>>>> The disabled assert in metaspace.cpp is faulty because a thread >>>>>>>> may be >>>>>>>> allocating classes and expanding the metaspace memory while we >>>>>>>> are in >>>>>>>> compute_new_size, I've verified that this assert can in fact fail >>>>>>>> on a >>>>>>>> build without these changes. >>>>>>>> The change in ~SpaceManager is because of lock order restrictions, >>>>>>>> sum_capacity_in_chunks_in_use takes the Metaspace lock and would >>>>>>>> do it >>>>>>>> out of order with regards to the expand_lock. >>>>>>>> >>>>>>>> I've tested these changes primarily by running the >>>>>>>> ParallelClassLoading >>>>>>>> tests with a small young gen size to enable regular class unloading >>>>>>>> cycles. >>>>>>>> >>>>>>>> Thanks >>>>>>>> /Mikael >> From thomas.schatzl at oracle.com Tue Mar 12 13:39:02 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 12 Mar 2013 14:39:02 +0100 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed In-Reply-To: <513F235E.8070908@oracle.com> References: <1362571695.2599.23.camel@cirrus> <513777ED.6030209@oracle.com> <1362639401.2659.3.camel@cirrus> <513F235E.8070908@oracle.com> Message-ID: <1363095542.2540.61.camel@cirrus> Hi, On Tue, 2013-03-12 at 13:45 +0100, Mikael Gerdin wrote: > Thomas, > > On 2013-03-07 07:56, Thomas Schatzl wrote: > > Hi, > > > > new webrev at > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8008684/webrev.1/ > > > > Passes jprt. > > Looks good to me. > It's good that this gets cleaned up. > > /Mikael Thanks. Could you (or jon) also shepherd this change into the repository? :) Here's an example openjdk commit text for this change (please adjust if needed): 8008684: CMS: concurrent phase start markers should always be printed Summary: Print the concurrent phase start markers for CMS when PrintGCDetails is enabled, not only if both PrintGCDetails and PrintGCTimeStamps are. Reviewed-by: mgerdin, jmasa Contributed-by: tschatzl Thanks, Thomas From mikael.gerdin at oracle.com Tue Mar 12 14:17:54 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Mar 2013 15:17:54 +0100 Subject: RFR (XXS): 8008684 - CMS: concurrent phase start markers should always be printed In-Reply-To: <1363095542.2540.61.camel@cirrus> References: <1362571695.2599.23.camel@cirrus> <513777ED.6030209@oracle.com> <1362639401.2659.3.camel@cirrus> <513F235E.8070908@oracle.com> <1363095542.2540.61.camel@cirrus> Message-ID: <513F3912.6050100@oracle.com> Thomas, On 2013-03-12 14:39, Thomas Schatzl wrote: > Hi, > > On Tue, 2013-03-12 at 13:45 +0100, Mikael Gerdin wrote: >> Thomas, >> >> On 2013-03-07 07:56, Thomas Schatzl wrote: >>> Hi, >>> >>> new webrev at >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8008684/webrev.1/ >>> >>> Passes jprt. >> >> Looks good to me. >> It's good that this gets cleaned up. >> >> /Mikael > > Thanks. Could you (or jon) also shepherd this change into the > repository? :) I'll take care of it. /Mikael > > Here's an example openjdk commit text for this change (please adjust if > needed): > > 8008684: CMS: concurrent phase start markers should always be printed > Summary: Print the concurrent phase start markers for CMS when > PrintGCDetails is enabled, not only if both PrintGCDetails and > PrintGCTimeStamps are. > Reviewed-by: mgerdin, jmasa > Contributed-by: tschatzl > > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Tue Mar 12 15:05:04 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 16:05:04 +0100 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <513E4E3E.4020405@oracle.com> References: <513E4E3E.4020405@oracle.com> Message-ID: <513F4420.8050307@oracle.com> Hi John, Thanks for fixing this so quickly! I have only had a quick look at the change. I'll make sure to look closer tomorrow. However, I have two questions. If you have time to answer them it would be good. If you don't have time I hope they become clear when I look more in detail at the change tomorrow... First, in the constructor for G1CMDrainMarkingStackClosure() we do: 2285 _do_stealing = !_is_serial; 2286 _do_termination = true; Just from looking at this it seems like we could get away with only having one instance variable instead of three. Is that the case or can any of _do_stealing, _is_serial or _do_termination change during the life time of a G1CMDrainMarkingStackClosure instance? Second, as you describe in the text below you are actually fixing two issues with this patch. Would it make sense to split the changes up into two changesets? Thanks, Bengt On 3/11/13 10:35 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review these changes? The webrev can > be found at: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/. > > First of all - many thanks to Uwe Schindler for discovering an > reporting the problem and providing very clear instructions on how to > reproduce the issue. Many thanks also Dawid Weiss for also stepping in > with a self-contained reproducer. > > I also wish to thank Bengt for his help. It was Bengt who gave me the > magic proxy formula that allowed Ivy to satisfy and download all the > dependencies for the test case. Bengt also diagnosed the problem and > gave an initial fix (which the changes in the webrev are based upon). > > Summary: > During the remark pause, the execution of the parallel RemarkTask set > the number of workers thread in the ParallelTaskTerminator and the > first and second barrier syncs. During serial reference processing, > the marking stack overflowed causing the single (VMThread) thread to > enter the overflow handling code in CMTask::do_marking_step(). This > overflow code using two WorkBarrierSyncs to synchronize the threads > before resetting the marking state for restarting marking. The barrier > syncs were waiting for the number of threads that participated in the > RemarkTask) but, since only the VM thread was executing, only a single > thread entered the barrier - resulting in the barrier indefinitely > waiting for the other (non existent) threads. > > A proposed solution was to call set_phase to reset the number of > threads in the parallel task terminator and the barriers to the number > of active threads for the reference processing. This solution ran into > a similar hang while processing the JNI references with parallel > reference processing enabled. (In parallel reference processing, the > JNI references are processed serially by the calling thread). > Resetting the phase to single-threaded before processing the JNI refs > solved the second hang but resulted in an assertion failure: only a > concurrentGC thread can enter a barrier sync and the calling thread > was the VM thread. > > Furthermore another problem was discovered. If the marking state is > reset, a subsequent call to set_phase() will assert as the global > finger has been set to start of the heap. This was a discovered by the > marking stack overflowing during the RemarkTask and parallel reference > processing calling set_phase() to reinitialize number of workers in > the parallel task terminator. It was also discovered when trying out > another proposed solution: adding a start_gc closure to reference > processing which would call set_phase() before each processing phase. > As a result the marking state is only reset by worker 0 if an overflow > occurs during the concurrent phase of marking; if an overflow occurs > during remark, reference processing is skipped, and the marking state > is reset by the VM thread. Resetting the marking state before > reference processing was a benign error (objects would be marked but > not pushed on to the stack as they were no longer below the finger; > the objects would then be traced, in the normal fashion, when marking > restarted) but it's better to safe than sorry. The other part of the > fix for this secondary problem is that the parallel reference > processing task executor now calls the terminator's reset_for_reuse() > routine instead of set_phase(). > > The resulting solution for the hang is based upon the patch sent out > by Bengt - namely we do not enter the sync barriers when > CMTask::do_marking_step() is being called serially. The difference is > that I added an extra parameter to CMTask::do_marking_step() instead > of piggy-backing on the existing parameter list. Additionally, if this > new parameter indicates serial operation, the current thread will skip > offering termination. This allows the serial drain closure to enter > the termination protocol and execute the guarantees contained therein. > > The other changes are for the secondary issues, described above, that > were discovered while out trying other possible solutions. > > Testing: > The lucene test case with serial reference processing (with and > without verification); the lucene test case with parallel reference > processing (with and without verification). > GC test suite with a mark stack size of 1K and 4K, with both serial > and parallel reference processing (with and without verification). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Mar 12 15:41:19 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 12 Mar 2013 08:41:19 -0700 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513EDD83.4040403@oracle.com> References: <5139E584.1050205@oracle.com> <513A367E.2000505@oracle.com> <513DEB85.9060807@oracle.com> <513DFC1F.6010208@oracle.com> <513EDD83.4040403@oracle.com> Message-ID: <513F4C9F.8020408@oracle.com> On 03/12/13 00:47, Bengt Rutisson wrote: > > Hi Jon, > > On 3/11/13 4:45 PM, Jon Masamitsu wrote: >> >> >> On 03/11/13 07:34, Bengt Rutisson wrote: >>> >>> Hi Jon, >>> >>> On 3/8/13 8:05 PM, Jon Masamitsu wrote: >>>> Bengt, >>>> >>>> With your change the order is >>>> >>>> set_heap_size() >>>> set_ergonomics_flags() >>>> >>>> set_ergonomics_flags() can turn on UseCompressedOops. >>>> set_heap_size() uses UseCompressedOops >>>> >>>> Right? >>>> >>>> It might not be a problem today but it makes me nervous. >>>> >>>> Is there a real circularity there? I don't know but if there is >>>> a way to exclude a circularity, then I won't have to think >>>> about it. >>> >>> Thanks for spotting this, Jon! There is definitely a circular >>> dependency between set_heap_size() and set_ergonomics_flags(). >>> >>> I could not figure out a nice and clean way of breaking the circular >>> dependency. But the circular dependency actually originates from the >>> fact that set_heap_size() does the check that the original bug >>> reports as an issue. It reduces the max heap size if >>> UseCompressedOops is enabled. The problem is that _after_ that it >>> adjust the max heap size to be at least as large as the initial heap >>> size. This is why we crash. >>> >>> So, one way to fix this is to use the knowledge that the initial >>> heap size is the only thing in set_heap_size() that can increase the >>> max heap size beyond what UseCompressedOops will work with. Here is >>> a webrev for what that could look like: >>> >>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.01/ >> >> Did you intend to call set_use_compressed_oops() before >> set_heap_size() and set_ergonomics_flags()? In the webrev >> the call to set_use_compressed_oops() is in >> set_ergonmonics_flags(). > > I left the call to set_use_compressed_oops() inside > set_ergonomics_flags() on purpose. This was both for minimizing the > risk of the change (everything is now done in the exact same order as > before) and for making sure that set_use_compressed_oops() has been > called before we start reading UseCompressedOops inside > set_ergonomics_flags(). > > I am not completely happy with how this looks. It might be better to > move all of the compressed handling out of set_ergonomics_flags(), but > if it is all right with you I would like to avoid that at the moment. I'm OK with the current fix. Moving the code to deal with COOPS seems like a good idea. I've filed an RFE for this issue. JDK-8009910 - Refactor code in arguments.cpp to break circularity in COOPS settings Your fix looks ready to go. Jon >> >>> >>> I think there is another circular dependency already present in the >>> code. If you look at max_heap_for_compressed_oops() its >>> implementation uses ClassMetaspaceSize. But this value may be >>> updated a bit later in set_ergonomics_flags(): >>> >>> FLAG_SET_ERGO(uintx, ClassMetaspaceSize, 100*M); >>> >>> Is this a problem? It is not really related to my current change, >>> but if it is a problem we should probably file a bug for it. >> >> I'll file a bug for this. Thanks. > > Great, thanks! > > Bengt > > >> >> Jon >> >>> >>> Thanks again for looking at this! >>> Bengt >>> >>>> >>>> >>>> Jon >>>> >>>> >>>> On 3/8/2013 5:20 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this change please? >>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>> >>>>> I'm sending this to both the GC and the runtime teams since I >>>>> think compressed oops is mixed responsibility for both teams. >>>>> >>>>> Background (mostly from the bug report): >>>>> >>>>> Hotspot crashes if it is run with a large initial size: >>>>> >>>>> >./java -Xms70g -version >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>> tid=140305232803584 >>>>> >>>>> The reason is that we enable UseCompressedOops but we use the >>>>> default value for ObjectAlignmentInBytes. With a large heap size >>>>> we would have needed to adjust the object alignment to be able to >>>>> use compressed oops. >>>>> >>>>> However, after reviewing the code it looks like the fix is not to >>>>> try to adjust the object alignment but rather to not enable >>>>> compressed oops for large heaps. If someone wants to use >>>>> compressed oops on a very large heap they need to explicitly set >>>>> both UseCompressedOops and ObjectAlignmentInBytes on the command >>>>> line. As far as I can tell this is how it is intended to work. >>>>> >>>>> Here is the reason for the crash and the rational behind the fix: >>>>> >>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>> size is small enough before we enable compressed oops: >>>>> >>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>> } >>>>> #endif >>>>> >>>>> And after that we print a warning message if the heap is too large: >>>>> >>>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>> warning("Max heap size too large for Compressed Oops"); >>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>> } >>>>> >>>>> Now the problem is that when we don't set the max heap size on the >>>>> command line it will be adjusted based on the initial size (-Xms) >>>>> and this happens in Arguments::set_heap_size(), which is called >>>>> *after* Arguments::set_ergonomics_flags() has been called. So, >>>>> when we do the check against the max size in >>>>> Arguments::set_ergonomics_flags(), we check against the default >>>>> value for the max size. This value fits well with a compressed >>>>> heap, so we enable compressed oops and crash later on when we >>>>> can't address the upper part of the heap. >>>>> >>>>> The fix is to move the call to set_heap_size() to *before* the >>>>> call to set_ergonomics_flags(). This way the check is done against >>>>> the correct value. This has two effects: >>>>> >>>>> 1) We don't enable UseCompressedOops on heap sizes that are too large >>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>> specifies a too large heap a warning message will be logged and >>>>> UseCompressedOops will be turned off. >>>>> >>>>> I am always hesitant to rearrange the order of calls in >>>>> Arguments::parse(). But in this case it is necessary to get the >>>>> correct behavior and I think it is safe. As far as I can tell >>>>> there is no other code between the two methods that try to read >>>>> the MaxHeapSize value. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Tue Mar 12 12:11:24 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 12 Mar 2013 05:11:24 -0700 (PDT) Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513EDC05.1030807@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513A293D.8020702@oracle.com> <513DF0D2.8060408@oracle.com> <513E2441.3050709@oracle.com> <513EDC05.1030807@oracle.com> Message-ID: <7e829440-65ac-41ea-802b-e7401c44e8ff@default> Hi Bengt, Did some sanity testing using one of your builds vs jdk8-b79 on a Linux x64 machine (sthoel01.se.oracle.com which has 144GB of memory): -Xms50g -Xmx60g No difference, no coops -Xms50g -Xmx60g -XX:+UseCompressedOops, No difference, no coops, warning printed: "Max heap size too large for Compressed Oops" -Xms50g -Xmx60g -XX:+UseCompressedOops -XX:ObjectAlignmentInBytes=16, No difference, coops enabled -Xms50g -Xmx60g -XX:ObjectAlignmentInBytes=16, No difference, coops enabled -Xms50g jdk8-b79 crashes, fixed jvm starts without coops and no warning messages -Xms50g -XX:+UseCompressedOops jdk8-b79 crashes, fixed jvm prints warning: "Max heap size too large for Compressed Oops" -Xms50g -XX:+UseCompressedOops -XX:ObjectAlignmentInBytes=16, No difference, coops enabled -Xms50g -XX:ObjectAlignmentInBytes=16, No difference, coops enabled Code change looks good and behavior seems consistent with earlier versions. Thanks, Christian -----Original Message----- From: Bengt Rutisson Sent: den 12 mars 2013 08:41 To: Vladimir Kozlov Cc: hotspot-gc-dev openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Hi Vladimir, On 3/11/13 7:36 PM, Vladimir Kozlov wrote: > On 3/11/13 7:57 AM, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> Thanks for looking at this! >> >> On 3/8/13 7:09 PM, Vladimir Kozlov wrote: >>> I am wondering should we also add a check into >>> Universe::reserve_heap() before calling >>> Universe::preferred_heap_base(). >> >> Do you mean that we should add an assert in Universe::reserve_heap() >> to check that the size we reserve is compatible with the compressed >> oop > > Yes, I want > > size_t total_reserved = align_size_up(heap_size + > Universe::class_metaspace_size(), alignment); > + assert(!UseCompressedOops || (total_reserved <= (OopEncodingHeapMax > - os::vm_page_size())), "heap size is too big for compressed oops"); > char* addr = Universe::preferred_heap_base(total_reserved, > Universe::UnscaledNarrowOop); > > You don't need to duplicate max_heap_for_compressed_oops() because > total_reserved includes class_metaspace. Thanks for this clarification! I added the assert. > There are size rounding codes in some places after arguments parsing > and someone could add an other ergonomic code after checks during > arguments parsing. To have an assert to catch such cases would be nice. Good point. Thanks for the help with this. Bengt > > Thanks, > Vladimir > >> state? I think that's fine but that means that I either have to >> duplicate the code in max_heap_for_compressed_oops() or make it >> publicly available somewhere. Currently it is just a local function >> inside Arguments.cpp. >> >> Personally I am not sure the assert will be worth the code change, >> but I'm fine with adding it if you want to. >> >> Thanks, >> Bengt >> >> >>> >>> Vladimir >>> >>> On 3/8/13 9:41 AM, harold seigel wrote: >>>> The change looks good. Perhaps this problem wasn't seen before >>>> because this scenario hadn't been tested? >>>> >>>> Harold >>>> >>>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>>> The change is reasonable. >>>>> >>>>> So why we did not see this problem before? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change please? >>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>> >>>>>> I'm sending this to both the GC and the runtime teams since I >>>>>> think compressed oops is mixed responsibility for both teams. >>>>>> >>>>>> Background (mostly from the bug report): >>>>>> >>>>>> Hotspot crashes if it is run with a large initial size: >>>>>> >>>>>> >./java -Xms70g -version >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>> tid=140305232803584 >>>>>> >>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>> default value for ObjectAlignmentInBytes. With a large heap size >>>>>> we would have needed to adjust the object alignment to be able to >>>>>> use compressed oops. >>>>>> >>>>>> However, after reviewing the code it looks like the fix is not to >>>>>> try to adjust the object alignment but rather to not enable >>>>>> compressed oops for large heaps. If someone wants to use >>>>>> compressed oops on a very large heap they need to explicitly set >>>>>> both UseCompressedOops and ObjectAlignmentInBytes on the command >>>>>> line. As far as I can tell this is how it is intended to work. >>>>>> >>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>> >>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>> size is small enough before we enable compressed oops: >>>>>> >>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { #if >>>>>> !defined(COMPILER1) || defined(TIERED) >>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>> } >>>>>> #endif >>>>>> >>>>>> And after that we print a warning message if the heap is too large: >>>>>> >>>>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>> } >>>>>> >>>>>> Now the problem is that when we don't set the max heap size on >>>>>> the command line it will be adjusted based on the initial size >>>>>> (-Xms) and this happens in Arguments::set_heap_size(), which is >>>>>> called *after* >>>>>> Arguments::set_ergonomics_flags() has been called. So, when we do >>>>>> the check against the max size in >>>>>> Arguments::set_ergonomics_flags(), we check against the default >>>>>> value for the max size. This value fits well with a compressed >>>>>> heap, so we enable compressed oops and crash later on when we >>>>>> can't address the upper part of the heap. >>>>>> >>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>> call to set_ergonomics_flags(). This way the check is done >>>>>> against the correct value. This has two effects: >>>>>> >>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>> large >>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>> specifies a too large heap a warning message will be logged and >>>>>> UseCompressedOops will be turned off. >>>>>> >>>>>> I am always hesitant to rearrange the order of calls in >>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>> correct behavior and I think it is safe. As far as I can tell >>>>>> there is no other code between the two methods that try to read >>>>>> the MaxHeapSize value. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >> From bengt.rutisson at oracle.com Tue Mar 12 15:45:51 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 16:45:51 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513F4C9F.8020408@oracle.com> References: <5139E584.1050205@oracle.com> <513A367E.2000505@oracle.com> <513DEB85.9060807@oracle.com> <513DFC1F.6010208@oracle.com> <513EDD83.4040403@oracle.com> <513F4C9F.8020408@oracle.com> Message-ID: <513F4DAF.9020902@oracle.com> Thanks for the review, Jon! And thanks for filing the refactoring bug! Bengt On 3/12/13 4:41 PM, Jon Masamitsu wrote: > > > On 03/12/13 00:47, Bengt Rutisson wrote: >> >> Hi Jon, >> >> On 3/11/13 4:45 PM, Jon Masamitsu wrote: >>> >>> >>> On 03/11/13 07:34, Bengt Rutisson wrote: >>>> >>>> Hi Jon, >>>> >>>> On 3/8/13 8:05 PM, Jon Masamitsu wrote: >>>>> Bengt, >>>>> >>>>> With your change the order is >>>>> >>>>> set_heap_size() >>>>> set_ergonomics_flags() >>>>> >>>>> set_ergonomics_flags() can turn on UseCompressedOops. >>>>> set_heap_size() uses UseCompressedOops >>>>> >>>>> Right? >>>>> >>>>> It might not be a problem today but it makes me nervous. >>>>> >>>>> Is there a real circularity there? I don't know but if there is >>>>> a way to exclude a circularity, then I won't have to think >>>>> about it. >>>> >>>> Thanks for spotting this, Jon! There is definitely a circular >>>> dependency between set_heap_size() and set_ergonomics_flags(). >>>> >>>> I could not figure out a nice and clean way of breaking the >>>> circular dependency. But the circular dependency actually >>>> originates from the fact that set_heap_size() does the check that >>>> the original bug reports as an issue. It reduces the max heap size >>>> if UseCompressedOops is enabled. The problem is that _after_ that >>>> it adjust the max heap size to be at least as large as the initial >>>> heap size. This is why we crash. >>>> >>>> So, one way to fix this is to use the knowledge that the initial >>>> heap size is the only thing in set_heap_size() that can increase >>>> the max heap size beyond what UseCompressedOops will work with. >>>> Here is a webrev for what that could look like: >>>> >>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.01/ >>> >>> Did you intend to call set_use_compressed_oops() before >>> set_heap_size() and set_ergonomics_flags()? In the webrev >>> the call to set_use_compressed_oops() is in >>> set_ergonmonics_flags(). >> >> I left the call to set_use_compressed_oops() inside >> set_ergonomics_flags() on purpose. This was both for minimizing the >> risk of the change (everything is now done in the exact same order as >> before) and for making sure that set_use_compressed_oops() has been >> called before we start reading UseCompressedOops inside >> set_ergonomics_flags(). >> >> I am not completely happy with how this looks. It might be better to >> move all of the compressed handling out of set_ergonomics_flags(), >> but if it is all right with you I would like to avoid that at the >> moment. > > I'm OK with the current fix. Moving the code to deal with > COOPS seems like a good idea. I've filed an RFE for this > issue. > > JDK-8009910 - Refactor code in arguments.cpp to break circularity in > COOPS settings > > Your fix looks ready to go. > > Jon >>> >>>> >>>> I think there is another circular dependency already present in the >>>> code. If you look at max_heap_for_compressed_oops() its >>>> implementation uses ClassMetaspaceSize. But this value may be >>>> updated a bit later in set_ergonomics_flags(): >>>> >>>> FLAG_SET_ERGO(uintx, ClassMetaspaceSize, 100*M); >>>> >>>> Is this a problem? It is not really related to my current change, >>>> but if it is a problem we should probably file a bug for it. >>> >>> I'll file a bug for this. Thanks. >> >> Great, thanks! >> >> Bengt >> >> >>> >>> Jon >>> >>>> >>>> Thanks again for looking at this! >>>> Bengt >>>> >>>>> >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 3/8/2013 5:20 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change please? >>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>> >>>>>> I'm sending this to both the GC and the runtime teams since I >>>>>> think compressed oops is mixed responsibility for both teams. >>>>>> >>>>>> Background (mostly from the bug report): >>>>>> >>>>>> Hotspot crashes if it is run with a large initial size: >>>>>> >>>>>> >./java -Xms70g -version >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>> tid=140305232803584 >>>>>> >>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>> default value for ObjectAlignmentInBytes. With a large heap size >>>>>> we would have needed to adjust the object alignment to be able to >>>>>> use compressed oops. >>>>>> >>>>>> However, after reviewing the code it looks like the fix is not to >>>>>> try to adjust the object alignment but rather to not enable >>>>>> compressed oops for large heaps. If someone wants to use >>>>>> compressed oops on a very large heap they need to explicitly set >>>>>> both UseCompressedOops and ObjectAlignmentInBytes on the command >>>>>> line. As far as I can tell this is how it is intended to work. >>>>>> >>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>> >>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>> size is small enough before we enable compressed oops: >>>>>> >>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>> } >>>>>> #endif >>>>>> >>>>>> And after that we print a warning message if the heap is too large: >>>>>> >>>>>> if (UseCompressedOops && !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>> } >>>>>> >>>>>> Now the problem is that when we don't set the max heap size on >>>>>> the command line it will be adjusted based on the initial size >>>>>> (-Xms) and this happens in Arguments::set_heap_size(), which is >>>>>> called *after* Arguments::set_ergonomics_flags() has been called. >>>>>> So, when we do the check against the max size in >>>>>> Arguments::set_ergonomics_flags(), we check against the default >>>>>> value for the max size. This value fits well with a compressed >>>>>> heap, so we enable compressed oops and crash later on when we >>>>>> can't address the upper part of the heap. >>>>>> >>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>> call to set_ergonomics_flags(). This way the check is done >>>>>> against the correct value. This has two effects: >>>>>> >>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>> large >>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>> specifies a too large heap a warning message will be logged and >>>>>> UseCompressedOops will be turned off. >>>>>> >>>>>> I am always hesitant to rearrange the order of calls in >>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>> correct behavior and I think it is safe. As far as I can tell >>>>>> there is no other code between the two methods that try to read >>>>>> the MaxHeapSize value. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Tue Mar 12 12:14:02 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 12 Mar 2013 05:14:02 -0700 (PDT) Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <513DF780.3040709@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> Message-ID: <98626133-0e7f-4854-80f1-be415b711eb3@default> Hi Erik, The change looks good :) Thanks, Christian -----Original Message----- From: Erik Helin Sent: den 11 mars 2013 16:26 To: Staffan Larsen Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian T?rnqvist Subject: Re: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" All, I've updated the change quite a bit based on feedback from Bengt and Christian. The class JmapLauncher has moved to the newly created gc testlibrary. This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to contain utilities that can be used by all the gc jtreg tests. If there are code that is of interest for additional tests, then code can be easily be moved from the gc testlibrary to the general testlibrary. I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of this new gc testlibrary. Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ Thanks, Erik On 03/08/2013 01:34 PM, Staffan Larsen wrote: > Looks good to me. > > /Staffan > > On 8 mar 2013, at 13:36, Erik Helin wrote: > >> Bengt and Staffan, >> >> thanks for he feedback! >> >> I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. >> >> I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >> >> Thanks, >> Erik >> >> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>> >>> Erik and Staffan, >>> >>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>> that returns "-d64" if necessary. You can't use this as is since you >>> need to get "J-d64" but I think we should do something to make your >>> solution more general. >>> >>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>> or adding a separate method that returns "JDK-tools formatted" args. >>> It seems a bit too limited to fix this only for your particular >>> test. Would be nice to get it in to the testlibrary somehow. >>> >>> Bengt >>> >>> >>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>> Looks good. I wish we could abstract this away so that not every >>>> test needs to do this work. >>>> >>>> /Staffan (mobile) >>>> >>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>> >>>>> Hi all, >>>>> >>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>> arch) when running jmap in the test >>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>> >>>>> Thanks, >>>>> Erik >>> >> > From kevin.walls at oracle.com Tue Mar 12 15:58:22 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 12 Mar 2013 15:58:22 +0000 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <51378071.2060107@oracle.com> References: <5130E68A.4040806@oracle.com> <51378071.2060107@oracle.com> Message-ID: <513F509E.3010808@oracle.com> Hi, This is the updated hsx24 webrev with a more generic name: http://cr.openjdk.java.net/~kevinw/8008917/hsx24.01/webrev/ it builds upon the change for 8009723, so a second failure message is removed when compared to the parent, as that change isn't in hsx24 yet (only latest, so a backport of that is required before pushing this). Thanks Kevin Jesper Wilhelmsson wrote: > Looks good! > > Since we want to implement this event for G1 as well, maybe we should > remove the "CMS" from the event name and path? > > Thanks, > /Jesper > > On 1/3/13 6:34 PM, Kevin Walls wrote: >> Hi, >> >> I'd like some reviews on this CMS Concurrent Mode Failure event: >> >> http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ >> >> The event doesn't actually carry any new information, but it is a >> warning we >> need to capture. >> >> This is against hsx24, I'll prepare the same, or reviewed, changes >> against very >> latest hotspot also. >> >> Thanks >> Kevin >> From stefan.karlsson at oracle.com Tue Mar 12 16:49:41 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Tue, 12 Mar 2013 16:49:41 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Message-ID: <20130312164950.6D93F480B3@hg.openjdk.java.net> Changeset: ca9580859cf4 Author: stefank Date: 2013-03-11 02:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ca9580859cf4 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Summary: Don't scan pages outside the given range. Reviewed-by: jwilhelm, jmasa ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp From john.cuthbertson at oracle.com Tue Mar 12 17:08:31 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 12 Mar 2013 10:08:31 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <513F4420.8050307@oracle.com> References: <513E4E3E.4020405@oracle.com> <513F4420.8050307@oracle.com> Message-ID: <513F610F.1060908@oracle.com> Hi Bengt, Thanks for looking at the changes. On 3/12/2013 8:05 AM, Bengt Rutisson wrote: > > Hi John, > > Thanks for fixing this so quickly! The main change is based upon your patch. It just took a little time to evaluate and disregard the alternatives (as well as fix the underlying problems they discovered). > > I have only had a quick look at the change. I'll make sure to look > closer tomorrow. However, I have two questions. If you have time to > answer them it would be good. If you don't have time I hope they > become clear when I look more in detail at the change tomorrow... > > First, in the constructor for G1CMDrainMarkingStackClosure() we do: > > 2285 _do_stealing = !_is_serial; > 2286 _do_termination = true; Yes we can. I had thought of that but I thought people wouldn't like it. > > Just from looking at this it seems like we could get away with only > having one instance variable instead of three. Is that the case or can > any of _do_stealing, _is_serial or _do_termination change during the > life time of a G1CMDrainMarkingStackClosure instance? > > Second, as you describe in the text below you are actually fixing two > issues with this patch. Would it make sense to split the changes up > into two changesets? OK. That's probably a good idea as long as the second gets in fairly soon - the Lucene tests will fail with an assertion failure when parallel reference processing is enabled, if the overflows occur at just the right points. I'll split them up into adding the serial path to do_marking_step followed by the changes for the assertion failure. New webrev soon. Thanks, JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Tue Mar 12 17:49:43 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 12 Mar 2013 18:49:43 +0100 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <513F509E.3010808@oracle.com> References: <5130E68A.4040806@oracle.com> <51378071.2060107@oracle.com> <513F509E.3010808@oracle.com> Message-ID: <513F6AB7.7080401@oracle.com> Looks good! Ship it! /Jesper On 12/3/13 4:58 PM, Kevin Walls wrote: > Hi, > > This is the updated hsx24 webrev with a more generic name: > > http://cr.openjdk.java.net/~kevinw/8008917/hsx24.01/webrev/ > > it builds upon the change for 8009723, so a second failure message is removed > when compared to the parent, as that change isn't in hsx24 yet (only latest, so > a backport of that is required before pushing this). > > Thanks > Kevin > > > Jesper Wilhelmsson wrote: >> Looks good! >> >> Since we want to implement this event for G1 as well, maybe we should remove >> the "CMS" from the event name and path? >> >> Thanks, >> /Jesper >> >> On 1/3/13 6:34 PM, Kevin Walls wrote: >>> Hi, >>> >>> I'd like some reviews on this CMS Concurrent Mode Failure event: >>> >>> http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ >>> >>> The event doesn't actually carry any new information, but it is a warning we >>> need to capture. >>> >>> This is against hsx24, I'll prepare the same, or reviewed, changes against very >>> latest hotspot also. >>> >>> Thanks >>> Kevin >>> > From vladimir.kozlov at oracle.com Tue Mar 12 18:35:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Mar 2013 11:35:36 -0700 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513EDDDC.4090005@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513A293D.8020702@oracle.com> <513DF0D2.8060408@oracle.com> <513E2441.3050709@oracle.com> <513EDC05.1030807@oracle.com> <513EDDDC.4090005@oracle.com> Message-ID: <513F7578.5020307@oracle.com> Looks good. Thanks, Vladimir On 3/12/13 12:48 AM, Bengt Rutisson wrote: > > Updated webrev based on the comments from Vladimir, Jon and Harold: > > http://cr.openjdk.java.net/~brutisso/8001049/webrev.02/ > > Thanks, > Bengt > > > On 3/12/13 8:40 AM, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> On 3/11/13 7:36 PM, Vladimir Kozlov wrote: >>> On 3/11/13 7:57 AM, Bengt Rutisson wrote: >>>> >>>> Hi Vladimir, >>>> >>>> Thanks for looking at this! >>>> >>>> On 3/8/13 7:09 PM, Vladimir Kozlov wrote: >>>>> I am wondering should we also add a check into >>>>> Universe::reserve_heap() before calling >>>>> Universe::preferred_heap_base(). >>>> >>>> Do you mean that we should add an assert in Universe::reserve_heap() to >>>> check that the size we reserve is compatible with the compressed oop >>> >>> Yes, I want >>> >>> size_t total_reserved = align_size_up(heap_size + >>> Universe::class_metaspace_size(), alignment); >>> + assert(!UseCompressedOops || (total_reserved <= >>> (OopEncodingHeapMax - os::vm_page_size())), "heap size is too big for >>> compressed oops"); >>> char* addr = Universe::preferred_heap_base(total_reserved, >>> Universe::UnscaledNarrowOop); >>> >>> You don't need to duplicate max_heap_for_compressed_oops() because >>> total_reserved includes class_metaspace. >> >> Thanks for this clarification! I added the assert. >> >>> There are size rounding codes in some places after arguments parsing >>> and someone could add an other ergonomic code after checks during >>> arguments parsing. To have an assert to catch such cases would be nice. >> >> Good point. Thanks for the help with this. >> >> Bengt >> >>> >>> Thanks, >>> Vladimir >>> >>>> state? I think that's fine but that means that I either have to >>>> duplicate the code in max_heap_for_compressed_oops() or make it >>>> publicly >>>> available somewhere. Currently it is just a local function inside >>>> Arguments.cpp. >>>> >>>> Personally I am not sure the assert will be worth the code change, but >>>> I'm fine with adding it if you want to. >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> >>>>> Vladimir >>>>> >>>>> On 3/8/13 9:41 AM, harold seigel wrote: >>>>>> The change looks good. Perhaps this problem wasn't seen before >>>>>> because >>>>>> this scenario hadn't been tested? >>>>>> >>>>>> Harold >>>>>> >>>>>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>>>>> The change is reasonable. >>>>>>> >>>>>>> So why we did not see this problem before? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could I have a couple of reviews for this change please? >>>>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>>>> >>>>>>>> I'm sending this to both the GC and the runtime teams since I think >>>>>>>> compressed oops is mixed responsibility for both teams. >>>>>>>> >>>>>>>> Background (mostly from the bug report): >>>>>>>> >>>>>>>> Hotspot crashes if it is run with a large initial size: >>>>>>>> >>>>>>>> >./java -Xms70g -version >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>>>> tid=140305232803584 >>>>>>>> >>>>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>>>> default >>>>>>>> value for ObjectAlignmentInBytes. With a large heap size we >>>>>>>> would have >>>>>>>> needed to adjust the object alignment to be able to use compressed >>>>>>>> oops. >>>>>>>> >>>>>>>> However, after reviewing the code it looks like the fix is not to >>>>>>>> try to >>>>>>>> adjust the object alignment but rather to not enable compressed >>>>>>>> oops for >>>>>>>> large heaps. If someone wants to use compressed oops on a very >>>>>>>> large >>>>>>>> heap they need to explicitly set both UseCompressedOops and >>>>>>>> ObjectAlignmentInBytes on the command line. As far as I can tell >>>>>>>> this is >>>>>>>> how it is intended to work. >>>>>>>> >>>>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>>>> >>>>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>>>> size is >>>>>>>> small enough before we enable compressed oops: >>>>>>>> >>>>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>>>> } >>>>>>>> #endif >>>>>>>> >>>>>>>> And after that we print a warning message if the heap is too large: >>>>>>>> >>>>>>>> if (UseCompressedOops && >>>>>>>> !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>>>> } >>>>>>>> >>>>>>>> Now the problem is that when we don't set the max heap size on the >>>>>>>> command line it will be adjusted based on the initial size >>>>>>>> (-Xms) and >>>>>>>> this happens in Arguments::set_heap_size(), which is called *after* >>>>>>>> Arguments::set_ergonomics_flags() has been called. So, when we >>>>>>>> do the >>>>>>>> check against the max size in Arguments::set_ergonomics_flags(), we >>>>>>>> check against the default value for the max size. This value >>>>>>>> fits well >>>>>>>> with a compressed heap, so we enable compressed oops and crash >>>>>>>> later on >>>>>>>> when we can't address the upper part of the heap. >>>>>>>> >>>>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>>>> call to >>>>>>>> set_ergonomics_flags(). This way the check is done against the >>>>>>>> correct >>>>>>>> value. This has two effects: >>>>>>>> >>>>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>>>> large >>>>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>>>> specifies a too large heap a warning message will be logged and >>>>>>>> UseCompressedOops will be turned off. >>>>>>>> >>>>>>>> I am always hesitant to rearrange the order of calls in >>>>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>>>> correct >>>>>>>> behavior and I think it is safe. As far as I can tell there is no >>>>>>>> other >>>>>>>> code between the two methods that try to read the MaxHeapSize >>>>>>>> value. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>> >>>> >> > From john.cuthbertson at oracle.com Tue Mar 12 19:25:51 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 12 Mar 2013 12:25:51 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <1363083217.2540.46.camel@cirrus> References: <513E4E3E.4020405@oracle.com> <1363083217.2540.46.camel@cirrus> Message-ID: <513F813F.2050208@oracle.com> Hi Thomas, Thanks for looking over the changes. Responses inline.... On 3/12/2013 3:13 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2013-03-11 at 14:35 -0700, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review these changes? The webrev can >> be found at: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/. >> > - maybe in concurrentMark.cpp you can now replace > > 992: reset_marking_state(concurrent() /* clear_overflow */); > > by > > reset_marking_state(true /* clear_overflow */); > > As the whole block is guarded by that. Not sure if it is better, but > when reading the code with that change you don't need to think what the > value of concurrent() is. > > Keeping it is as fine. That's fine. I'm OK making this change. Since Bengt has asked to make the change associated with the set_phase() assertion as a separate fix - this comment no longer applies - but I'll make the change in the second fix. BTW the following replies were done before I got what you were looking for. I think we're in agreement. > - I'm slightly confused by using the "serial" > G1CMKeepAliveAndDrainClosure and G1CMDrainMarkingStackClosure closures > (that don't synchronize with other threads) in weakRefsWork() at line > 2465 and 2466. Or at least the comment above it. Moving the comment about active workers to after instantiation of these closure would be a better place. Would it make more sense if the code was structured: serial_keep_alive; serial_drain; if (!processing_is_mt) { // Serial reference processing is executed by the VMThread. rp->process_discovered_references(&is_alive, &serial_keep_alive, &serial_drain, NULL); } else { // Parallel reference processing is executed by the work gang. .. } I had the code structured like this before and it was changed at the request of some reviewers' comments. Personally I preferred the above but not strongly enough to discount the comment. > So, this "is_serial" flag indicates to the do_marking_step() that it > should not try to synchronize with concurrent mark threads when > terminating, as there are none. The is_serial flag to do_marking_step() is to indicate whether the executing thread is the VM thread. > There are still the parallel work gang threads using these "is_serial" > closures for processing (by the partaskexecutor used in > process_discovered_references()). No. In the JNI refs case it is still the VM thread (actually the caller of process_discovered_references()) that executes the "serial" closures but I think see what you mean. > Following the code, in the parallel case, if a thread spawned by > weakRefsWork() fails "fails" due to mark stack overflow, it does not try > to synchronize with others. Mainly because the work gang it is running > in (in Workgang::run_task()) that waits for all threads anyway. No. The "serial" closures are executed by the VM thread. The parallel closures (where we want the worker to offer termination and enter the sync barriers) are executed by the work gang. I think we just need to call out that processing of JNI refs is performed serially. > (Couldn't this synchronization potentially take a long time as e.g. one > thread is able to completely finish work using local buffers as others > are waiting on it?) Any wait for an event could potentially take a while. That's why there's a timer for the termination. We haven't seen it in the marking code though. > Then, regardless of parallelism, two (or three) caller levels above in > ConcurrentMarkThread::run(), after the vm thread finishes the safepoint, > the current code will notice that there has been an overflow during > remark and do another safepoint. No. Marking restarts from the "concurrent" phase: > int iter = 0; > do { > iter++; > if (!cm()->has_aborted()) { > _cm->markFromRoots(); > } > (Is there a reason to schedule another safepoint to recover from a > marking overflow? This involves a back-to-back safepoint. Is this > cheaper than just retrying in the current safepoint?) There's no safepoint in the above code. The next safepoint is the next remark. > What do you think of renaming that flag? Maybe something like > "synchronize_with_cm_threads". Unfortunately I cannot come up with a > better, more generic name, as do_marking_step() does exactly that, and > that's what the change wants to avoid (well, it has the flag the other > way around). It's not synchronize_with_cm_threads - more like is_VM_thread and I think that is a bit too specific. Also the work gang in question is the CM work gang during the concurrent phase of marking. During remark we use the work gang from the G1 heap. The reason for this is that, by default, the number of marking threads is a fraction of the parallel GC threads (for example on my workstation it's 1 for 4 GC threads). > The problem seems to be that do_marking_step() as is now is too much > geared towards use in the concurrent marking threads, it uses a lot of > details from it. And the current code reuses do_marking_step() although > it's not running in the marking threads. I agree - though I would say it's more geared for use by a work gang. These closures were originally parallel reference processing only and the original serial closures operated directly on the marking stack. We wanted to use them in the serial code because we were starting to see more overflows from the serial reference processing code. Using them in the serial case should reduce the frequency of overflows as do_marking_step() primarily uses the CMTask's local task queue and the global marking stack is used as backing store when the local queue overflows. The problem with do_marking_step() being parallel-centric has always been there - we just never noticed it. Consider the remark case when parallel GC threads = 0. Even though the remark code sets the number of workers in the terminator and the barrier syncs (using set_phase) - and we don't hang - an overflow in do_marking_step() would assert when the VM thread entered the first barrier sync. > So another option could be to extract the concurrent marking thread > specific stuff (e.g. termination) from do_marking_step() into a helper > class/interface and pass a suitable implementation for each of its uses. > Instead of the many _cm-> references in do_marking_step, call > appropriate methods of that. But that would be quite some additional > work... (and I didn't think it through, just a thought) Definitely not for this change. :) > Anyway, could the comment above these lines changed as the current > comment indicates (to me) that the closures are run by the vmthread. > > E.g. instead of > > 2463:// Serial (i.e executed by VMThread) instances of the 'Keep Alive' > 2464:// and 'Complete GC' closures. > > use something like: > > // These closures do not need to synchronize with concurrent marking > // threads as this code is either run serially by this thread (e.g. > // processing_is_mt is false which uses the VM thread), or the worker > // gang tasks which have their own synchronization. The current thread _is_ the VM thread. I guess a better comment would be: // These closures do not need to offer termination or enter the synchronization barriers in do_marking_step(). Actually an amalgamation of both comments would be best. And I still think some restructuring in weakRefsWork() would make it more obvious. > - one other minor thing in concurrentMark.cpp: > > 4317: bool finished = (is_serial ? true > :_cm->terminator()->offer_termination(this)); > > Maybe change this to > > bool finished = (is_serial || > _cm->terminator()->offer_termination(this)); > > While this is no different, I actually had to pause and think what the > intent of the use of the "?" operator was here :) It seems easier to > read and more common to to not use the "?" operator in such cases. Sure. Done. Thanks, JohnC From bengt.rutisson at oracle.com Tue Mar 12 20:47:10 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 21:47:10 +0100 Subject: Request for review (S): 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes In-Reply-To: <513F7578.5020307@oracle.com> References: <5139E584.1050205@oracle.com> <513A0F17.5040100@oracle.com> <513A22E2.1060904@oracle.com> <513A293D.8020702@oracle.com> <513DF0D2.8060408@oracle.com> <513E2441.3050709@oracle.com> <513EDC05.1030807@oracle.com> <513EDDDC.4090005@oracle.com> <513F7578.5020307@oracle.com> Message-ID: <513F944E.7000805@oracle.com> Vladimir, Jon, Harold and Christian, Thanks for the reviews! All set to push now. Bengt On 3/12/13 7:35 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 3/12/13 12:48 AM, Bengt Rutisson wrote: >> >> Updated webrev based on the comments from Vladimir, Jon and Harold: >> >> http://cr.openjdk.java.net/~brutisso/8001049/webrev.02/ >> >> Thanks, >> Bengt >> >> >> On 3/12/13 8:40 AM, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> On 3/11/13 7:36 PM, Vladimir Kozlov wrote: >>>> On 3/11/13 7:57 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Vladimir, >>>>> >>>>> Thanks for looking at this! >>>>> >>>>> On 3/8/13 7:09 PM, Vladimir Kozlov wrote: >>>>>> I am wondering should we also add a check into >>>>>> Universe::reserve_heap() before calling >>>>>> Universe::preferred_heap_base(). >>>>> >>>>> Do you mean that we should add an assert in >>>>> Universe::reserve_heap() to >>>>> check that the size we reserve is compatible with the compressed oop >>>> >>>> Yes, I want >>>> >>>> size_t total_reserved = align_size_up(heap_size + >>>> Universe::class_metaspace_size(), alignment); >>>> + assert(!UseCompressedOops || (total_reserved <= >>>> (OopEncodingHeapMax - os::vm_page_size())), "heap size is too big for >>>> compressed oops"); >>>> char* addr = Universe::preferred_heap_base(total_reserved, >>>> Universe::UnscaledNarrowOop); >>>> >>>> You don't need to duplicate max_heap_for_compressed_oops() because >>>> total_reserved includes class_metaspace. >>> >>> Thanks for this clarification! I added the assert. >>> >>>> There are size rounding codes in some places after arguments parsing >>>> and someone could add an other ergonomic code after checks during >>>> arguments parsing. To have an assert to catch such cases would be >>>> nice. >>> >>> Good point. Thanks for the help with this. >>> >>> Bengt >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> state? I think that's fine but that means that I either have to >>>>> duplicate the code in max_heap_for_compressed_oops() or make it >>>>> publicly >>>>> available somewhere. Currently it is just a local function inside >>>>> Arguments.cpp. >>>>> >>>>> Personally I am not sure the assert will be worth the code change, >>>>> but >>>>> I'm fine with adding it if you want to. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 3/8/13 9:41 AM, harold seigel wrote: >>>>>>> The change looks good. Perhaps this problem wasn't seen before >>>>>>> because >>>>>>> this scenario hadn't been tested? >>>>>>> >>>>>>> Harold >>>>>>> >>>>>>> On 3/8/2013 11:17 AM, Vladimir Kozlov wrote: >>>>>>>> The change is reasonable. >>>>>>>> >>>>>>>> So why we did not see this problem before? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 3/8/13 5:20 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could I have a couple of reviews for this change please? >>>>>>>>> http://cr.openjdk.java.net/~brutisso/8001049/webrev.00/ >>>>>>>>> >>>>>>>>> I'm sending this to both the GC and the runtime teams since I >>>>>>>>> think >>>>>>>>> compressed oops is mixed responsibility for both teams. >>>>>>>>> >>>>>>>>> Background (mostly from the bug report): >>>>>>>>> >>>>>>>>> Hotspot crashes if it is run with a large initial size: >>>>>>>>> >>>>>>>>> >./java -Xms70g -version >>>>>>>>> # >>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>> Environment: >>>>>>>>> # >>>>>>>>> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=14132, >>>>>>>>> tid=140305232803584 >>>>>>>>> >>>>>>>>> The reason is that we enable UseCompressedOops but we use the >>>>>>>>> default >>>>>>>>> value for ObjectAlignmentInBytes. With a large heap size we >>>>>>>>> would have >>>>>>>>> needed to adjust the object alignment to be able to use >>>>>>>>> compressed >>>>>>>>> oops. >>>>>>>>> >>>>>>>>> However, after reviewing the code it looks like the fix is not to >>>>>>>>> try to >>>>>>>>> adjust the object alignment but rather to not enable compressed >>>>>>>>> oops for >>>>>>>>> large heaps. If someone wants to use compressed oops on a very >>>>>>>>> large >>>>>>>>> heap they need to explicitly set both UseCompressedOops and >>>>>>>>> ObjectAlignmentInBytes on the command line. As far as I can tell >>>>>>>>> this is >>>>>>>>> how it is intended to work. >>>>>>>>> >>>>>>>>> Here is the reason for the crash and the rational behind the fix: >>>>>>>>> >>>>>>>>> In Arguments::set_ergonomics_flags() we check that the max heap >>>>>>>>> size is >>>>>>>>> small enough before we enable compressed oops: >>>>>>>>> >>>>>>>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>>>>>>> #if !defined(COMPILER1) || defined(TIERED) >>>>>>>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>>>>>>> } >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> And after that we print a warning message if the heap is too >>>>>>>>> large: >>>>>>>>> >>>>>>>>> if (UseCompressedOops && >>>>>>>>> !FLAG_IS_DEFAULT(UseCompressedOops)) { >>>>>>>>> warning("Max heap size too large for Compressed Oops"); >>>>>>>>> FLAG_SET_DEFAULT(UseCompressedOops, false); >>>>>>>>> FLAG_SET_DEFAULT(UseCompressedKlassPointers, false); >>>>>>>>> } >>>>>>>>> >>>>>>>>> Now the problem is that when we don't set the max heap size on >>>>>>>>> the >>>>>>>>> command line it will be adjusted based on the initial size >>>>>>>>> (-Xms) and >>>>>>>>> this happens in Arguments::set_heap_size(), which is called >>>>>>>>> *after* >>>>>>>>> Arguments::set_ergonomics_flags() has been called. So, when we >>>>>>>>> do the >>>>>>>>> check against the max size in >>>>>>>>> Arguments::set_ergonomics_flags(), we >>>>>>>>> check against the default value for the max size. This value >>>>>>>>> fits well >>>>>>>>> with a compressed heap, so we enable compressed oops and crash >>>>>>>>> later on >>>>>>>>> when we can't address the upper part of the heap. >>>>>>>>> >>>>>>>>> The fix is to move the call to set_heap_size() to *before* the >>>>>>>>> call to >>>>>>>>> set_ergonomics_flags(). This way the check is done against the >>>>>>>>> correct >>>>>>>>> value. This has two effects: >>>>>>>>> >>>>>>>>> 1) We don't enable UseCompressedOops on heap sizes that are too >>>>>>>>> large >>>>>>>>> 2) If someone sets -XX:+UseCompressedOops on the command line but >>>>>>>>> specifies a too large heap a warning message will be logged and >>>>>>>>> UseCompressedOops will be turned off. >>>>>>>>> >>>>>>>>> I am always hesitant to rearrange the order of calls in >>>>>>>>> Arguments::parse(). But in this case it is necessary to get the >>>>>>>>> correct >>>>>>>>> behavior and I think it is safe. As far as I can tell there is no >>>>>>>>> other >>>>>>>>> code between the two methods that try to read the MaxHeapSize >>>>>>>>> value. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>> >>>>> >>> >> From stefan.karlsson at oracle.com Tue Mar 12 21:09:00 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Mar 2013 22:09:00 +0100 Subject: Review request: 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA In-Reply-To: <513DC116.4080801@oracle.com> References: <513DAC12.4050801@oracle.com> <513DC116.4080801@oracle.com> Message-ID: <513F996C.4010604@oracle.com> Thanks, Jesper. StefanK On 2013-03-11 12:33, Jesper Wilhelmsson wrote: > The change looks good. > I especially like the assert :-) > > Ship it! > /Jesper > > On 11/3/13 11:04 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8004697/webrev.00/ >> >> The JVM crashes because it accidentally frees memory in the survivor >> regions, at >> one point where it is supposed to only free freeing memory in the eden. >> >> The code in os::scan_pages(start, end, ...) in solaris_os.cpp looks >> at pages >> starting beyond 'end'. This causes >> MutableNUMASpace::LGRPSpace::scan_pages to >> free memory outside eden, when the last page starts in, but ends >> outside of eden. >> >> Testing: The JVM used to crash within in a couple of minutes. With >> the patch, >> the test has been running over the weekend without any crashes. >> >> thanks, >> StefanK From stefan.karlsson at oracle.com Tue Mar 12 21:09:17 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Mar 2013 22:09:17 +0100 Subject: Review request: 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA In-Reply-To: <513E1E1C.1060201@oracle.com> References: <513DAC12.4050801@oracle.com> <513E1E1C.1060201@oracle.com> Message-ID: <513F997D.7010200@oracle.com> Thanks, Jon. StefanK On 2013-03-11 19:10, Jon Masamitsu wrote: > Looks good. > > Jon > > On 03/11/13 03:04, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8004697/webrev.00/ >> >> The JVM crashes because it accidentally frees memory in the survivor >> regions, at one point where it is supposed to only free freeing >> memory in the eden. >> >> The code in os::scan_pages(start, end, ...) in solaris_os.cpp looks >> at pages starting beyond 'end'. This causes >> MutableNUMASpace::LGRPSpace::scan_pages to free memory outside eden, >> when the last page starts in, but ends outside of eden. >> >> Testing: The JVM used to crash within in a couple of minutes. With >> the patch, the test has been running over the weekend without any >> crashes. >> >> thanks, >> StefanK From john.cuthbertson at oracle.com Tue Mar 12 22:00:27 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 12 Mar 2013 15:00:27 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <513E4E3E.4020405@oracle.com> References: <513E4E3E.4020405@oracle.com> Message-ID: <513FA57B.8060705@oracle.com> Hi Everyone, Here's a new webrev based upon comments from Bengt and Thomas. http://cr.openjdk.java.net/~johnc/8009536/webrev.1/ This webrev includes the just the changes to resolve the hang seen by overflowing the marking stack during *serial* reference processing. As I said in my response to Bengt, this revision will produce the following assert: > [junit4:junit4] 80.722: [GC remark 80.723: [GC ref-proc80.785: [GC > concurrent-mark-reset-for-overflow] > [junit4:junit4] # To suppress the following error report, specify this > argument > [junit4:junit4] # after -XX: or in .hotspotrc: > SuppressErrorAt=/concurrentMark.cpp:809 > [junit4:junit4] # > [junit4:junit4] # A fatal error has been detected by the Java Runtime > Environment: > [junit4:junit4] # > [junit4:junit4] # Internal Error > (/export/workspaces/8009536_3/src/share/vm/gc_implementation/g1/concurrentMark.cpp:809), > pid=16314, tid=14 > [junit4:junit4] # assert(_finger == _heap_end) failed: only way to > get here > [junit4:junit4] # > [junit4:junit4] # JRE version: Java(TM) SE Runtime Environment > (8.0-b79) (build 1.8.0-ea-fastdebug-b79) > [junit4:junit4] # Java VM: Java HotSpot(TM) Server VM > (25.0-b23-internal-jvmg mixed mode solaris-x86 ) > [junit4:junit4] # Core dump written. Default location: > /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/build/analysis/uima/test/J0/core > or core.16314 > [junit4:junit4] # > [junit4:junit4] # An error report file with more information is saved as: > [junit4:junit4] # > /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/build/analysis/uima/test/J0/hs_err_pid16314.log > [junit4:junit4] # > [junit4:junit4] # If you would like to submit a bug report, please visit: > [junit4:junit4] # http://bugreport.sun.com/bugreport/crash.jsp > [junit4:junit4] # > [junit4:junit4] Current thread is 14 > [junit4:junit4] Dumping core ... when run with parallel reference processing enabled. That fix will be sent out shortly. JohnC On 3/11/2013 2:35 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review these changes? The webrev can > be found at: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/. > > First of all - many thanks to Uwe Schindler for discovering an > reporting the problem and providing very clear instructions on how to > reproduce the issue. Many thanks also Dawid Weiss for also stepping in > with a self-contained reproducer. > > I also wish to thank Bengt for his help. It was Bengt who gave me the > magic proxy formula that allowed Ivy to satisfy and download all the > dependencies for the test case. Bengt also diagnosed the problem and > gave an initial fix (which the changes in the webrev are based upon). > > Summary: > During the remark pause, the execution of the parallel RemarkTask set > the number of workers thread in the ParallelTaskTerminator and the > first and second barrier syncs. During serial reference processing, > the marking stack overflowed causing the single (VMThread) thread to > enter the overflow handling code in CMTask::do_marking_step(). This > overflow code using two WorkBarrierSyncs to synchronize the threads > before resetting the marking state for restarting marking. The barrier > syncs were waiting for the number of threads that participated in the > RemarkTask) but, since only the VM thread was executing, only a single > thread entered the barrier - resulting in the barrier indefinitely > waiting for the other (non existent) threads. > > A proposed solution was to call set_phase to reset the number of > threads in the parallel task terminator and the barriers to the number > of active threads for the reference processing. This solution ran into > a similar hang while processing the JNI references with parallel > reference processing enabled. (In parallel reference processing, the > JNI references are processed serially by the calling thread). > Resetting the phase to single-threaded before processing the JNI refs > solved the second hang but resulted in an assertion failure: only a > concurrentGC thread can enter a barrier sync and the calling thread > was the VM thread. > > Furthermore another problem was discovered. If the marking state is > reset, a subsequent call to set_phase() will assert as the global > finger has been set to start of the heap. This was a discovered by the > marking stack overflowing during the RemarkTask and parallel reference > processing calling set_phase() to reinitialize number of workers in > the parallel task terminator. It was also discovered when trying out > another proposed solution: adding a start_gc closure to reference > processing which would call set_phase() before each processing phase. > As a result the marking state is only reset by worker 0 if an overflow > occurs during the concurrent phase of marking; if an overflow occurs > during remark, reference processing is skipped, and the marking state > is reset by the VM thread. Resetting the marking state before > reference processing was a benign error (objects would be marked but > not pushed on to the stack as they were no longer below the finger; > the objects would then be traced, in the normal fashion, when marking > restarted) but it's better to safe than sorry. The other part of the > fix for this secondary problem is that the parallel reference > processing task executor now calls the terminator's reset_for_reuse() > routine instead of set_phase(). > > The resulting solution for the hang is based upon the patch sent out > by Bengt - namely we do not enter the sync barriers when > CMTask::do_marking_step() is being called serially. The difference is > that I added an extra parameter to CMTask::do_marking_step() instead > of piggy-backing on the existing parameter list. Additionally, if this > new parameter indicates serial operation, the current thread will skip > offering termination. This allows the serial drain closure to enter > the termination protocol and execute the guarantees contained therein. > > The other changes are for the secondary issues, described above, that > were discovered while out trying other possible solutions. > > Testing: > The lucene test case with serial reference processing (with and > without verification); the lucene test case with parallel reference > processing (with and without verification). > GC test suite with a mark stack size of 1K and 4K, with both serial > and parallel reference processing (with and without verification). From bengt.rutisson at oracle.com Tue Mar 12 22:10:50 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 12 Mar 2013 23:10:50 +0100 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <513F610F.1060908@oracle.com> References: <513E4E3E.4020405@oracle.com> <513F4420.8050307@oracle.com> <513F610F.1060908@oracle.com> Message-ID: <513FA7EA.3040805@oracle.com> Hi John, On 3/12/13 6:08 PM, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking at the changes. > > On 3/12/2013 8:05 AM, Bengt Rutisson wrote: >> >> Hi John, >> >> Thanks for fixing this so quickly! > > The main change is based upon your patch. It just took a little time > to evaluate and disregard the alternatives (as well as fix the > underlying problems they discovered). > >> >> I have only had a quick look at the change. I'll make sure to look >> closer tomorrow. However, I have two questions. If you have time to >> answer them it would be good. If you don't have time I hope they >> become clear when I look more in detail at the change tomorrow... >> >> First, in the constructor for G1CMDrainMarkingStackClosure() we do: >> >> 2285 _do_stealing = !_is_serial; >> 2286 _do_termination = true; > > Yes we can. I had thought of that but I thought people wouldn't like it. I think I would prefer a single _is_serial or even _is_par instance variable. >> >> Just from looking at this it seems like we could get away with only >> having one instance variable instead of three. Is that the case or >> can any of _do_stealing, _is_serial or _do_termination change during >> the life time of a G1CMDrainMarkingStackClosure instance? >> >> Second, as you describe in the text below you are actually fixing two >> issues with this patch. Would it make sense to split the changes up >> into two changesets? > > OK. That's probably a good idea as long as the second gets in fairly > soon - the Lucene tests will fail with an assertion failure when > parallel reference processing is enabled, if the overflows occur at > just the right points. I'll split them up into adding the serial path > to do_marking_step followed by the changes for the assertion failure. Great, thanks! I think we can push the changes at the same time. It is just much easier to review one thing at a time. > > New webrev soon. :) Looking forward to it! Bengt > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Wed Mar 13 00:10:25 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 12 Mar 2013 17:10:25 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Message-ID: <513FC3F1.8090609@oracle.com> Hi Everyone, Can I have a couple of volunteers look over these changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/8009940/webrev.0/ These changes were, at Bengt's request, split out from the original webrev for 8009536. In the webrev they have been applied on top of 8009536 but they are independent. The issue has been in the G1 code for a while (since I added the reference processing code a couple of years ago) - we just never hit it. Anyway the assertion is caused by calling set_phase() - which throws the assertion failure - after resetting the marking state - which resets the value of the global finger. The solution was a three pronged approach: 1. Skip reference processing if the marking stack overflowed during the actual remark task. This is safe to do as reference objects are only discovered once. So once a reference object is discovered it will remain on the discovered list until it is processed. Since, as a result of the overflow, marking is going to restart - the references will be processed after a successful remark. We could use the routine abandon_partial_discovery() and depopulate the discovered lists but the only benefit to doing this is that we may discover less references during the subsequent restart. 2. Remove the set_phase() calls when we execute a new ref processing proxy task To do this we need to call set_phase() from within weakRefsWork() and call the terminator's reset_for_reuse() routine when we execute a new ref processing task. This will remove the path that checks the assert. 3. Worker 0 only resets the marking state during the current phase of marking. During the STW remark pause there is another call to reset the marking stack (in the event of overflow) immediately after the discovered references are processed: double start = os::elapsedTime(); checkpointRootsFinalWork(); double mark_work_end = os::elapsedTime(); weakRefsWork(clear_all_soft_refs); if (has_overflown()) { // Oops. We overflowed. Restart concurrent marking. _restart_for_overflow = true; // Clear the marking state because we will be restarting // marking due to overflowing the global mark stack. reset_marking_state(); if (G1TraceMarkStackOverflow) { gclog_or_tty->print_cr("\nRemark led to restart for overflow."); } I also fixed the British spelling of initialized in a few places. Testing: The lucene tests with parallel reference processing (with and without verification). specjvm98 with parallel reference processing (with and without verification). Thanks, JohnC From mikael.gerdin at oracle.com Wed Mar 13 04:11:11 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Wed, 13 Mar 2013 04:11:11 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8008684: CMS: concurrent phase start markers should always be printed Message-ID: <20130313041116.8EBB0480D5@hg.openjdk.java.net> Changeset: 62609ffa2fc6 Author: tschatzl Date: 2013-03-12 15:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/62609ffa2fc6 8008684: CMS: concurrent phase start markers should always be printed Summary: Print the concurrent phase start markers for CMS when PrintGCDetails is enabled, not only if both PrintGCDetails and PrintGCTimeStamps are. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp From bengt.rutisson at oracle.com Wed Mar 13 05:53:36 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 13 Mar 2013 05:53:36 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20130313055341.EE670480D8@hg.openjdk.java.net> Changeset: eac371996b44 Author: brutisso Date: 2013-03-12 08:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eac371996b44 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Summary: Take the initial heap size into account when checking the heap size for compressed oops Reviewed-by: jmasa, kvn, hseigel, ctornqvi ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 993d878108d9 Author: brutisso Date: 2013-03-13 05:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/993d878108d9 Merge From leonid.mesnik at oracle.com Wed Mar 13 10:14:58 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 13 Mar 2013 14:14:58 +0400 Subject: RFR: 8009763 Add WB test for String.intern() In-Reply-To: <513F27FF.5080607@oracle.com> References: <513ED867.2070902@oracle.com> <513F27FF.5080607@oracle.com> Message-ID: <514051A2.4090800@oracle.com> Hi werbrev was updated (thank you for this) http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.1/ JPRT passed with -rtest '*-*-*-runtime/interned' Leonid On 03/12/2013 05:05 PM, Mikael Gerdin wrote: > Hi Leonid, > > On 2013-03-12 08:25, Leonid Mesnik wrote: >> Hi >> I've added a small test which: >> 1) creates java string and intern it >> 2) verify that it presents in StringTable >> 3) clear reference and call fullGC >> 4) verify that there is no such string in StringTable >> >> Here is webrev: >> http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.0/ > > Overall this looks reasonable. > > I have some comments though: > WB_IsInStringTable is defined to return a jboolean (Ljava/lang/String;)Z > but the actual function is defined to return an jint. This will > probably work but you should fix this to make it consistent. > > The function WB_fullGC should have a capital F to be consistent with > the naming of the other WB_* functions. > >> >> Tested locally and by JPRT >> > did you run jprt with -retest '*-*-*-runtime/interned' as well? > > /Mikael -- Leonid Mesnik JVM SQE From bengt.rutisson at oracle.com Wed Mar 13 10:22:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 13 Mar 2013 11:22:06 +0100 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <513FA57B.8060705@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> Message-ID: <5140534E.7050607@oracle.com> Hi John, I'm not too familiar with the do_marking_step() code, so I'm trying to get to know it while I'm looking at your webrev. So, maybe I'm completely off here, but I think there are a couple of strange things. After your change do_marking_step() takes three bools: do_stealing, do_termination and is_serial. This means that we have 8 possible states if we combine all value of these bools. I went through all calls to do_marking_step() and it seems like we make use of 4 of those states: G1CMKeepAliveAndDrainClosure::do_oop_work() do_marking_step(false, false, true) (1) CMConcurrentMarkingTask::work() do_marking_step(true, true, false) (2) CMRemarkTask::work() do_marking_step(true, true, false) (2) do_marking_step(true, true, true) (3) G1CMDrainMarkingStackClosure::do_void() do_marking_step(false, true, true) (4) do_marking_step(true, true, false) (2) I numbered the states (1) - (4). Here are all states and I marked which ones we use: stealing, termination, serial (3) stealing, !termination, serial stealing, !termination, !serial stealing, termination, !serial (2) parallel !stealing, termination, serial (4) !stealing, !termination, serial (1) serial !stealing, !termination, !serial !stealing, termination, !serial I think state (2) makes sense as the parallel case. We do stealing and termination and we are not serial. State (1) also makes sense. It is clearly the serial case. No stealing or termination. Just serial. Now, case (3) looks odd to me. We say we are serial but we want to do stealing and termination. This case comes from CMRemarkTask. It takes a is_serial argument in its constructor. We get to case (3) from ConcurrentMark::checkpointRootsFinalWork(), where we do: if (G1CollectedHeap::use_parallel_gc_threads()) { ... } else { ... CMRemarkTask remarkTask(this, active_workers, true /* is_serial*/); } To me this looks like it should lead to the pure serial case (1) instead of (3). Do you agree? In that case I think CMRemarkTask::work() needs to be changed to do: task->do_marking_step(1000000000.0 /* something very large */, !_is_serial /* do_stealing */, !_is_serial /* do_termination */, _is_serial); The other case that sticks out is (4). We don't want to do stealing, but we want to do termination even though we are serial. This comes from how we set up the g1_drain_mark_stack in ConcurrentMark::weakRefsWork(). We pass that along to the reference processing, which I think is serial (wasn't that the original problem? :) ). We also pass the g1_keep_alive which is set up to be in state (1). So, I wonder if it is correct that the g1_drain_mark_stack is in state (4). If you agree that we should be using the pure serial case here too, I think we need to change G1CMDrainMarkingStackClosure::do_void() to be: _task->do_marking_step(1000000000.0 /* something very large */, !_is_serial /* do_stealing */, !_is_serial /* do_termination */, _is_serial /* is_serial */); Again, I'm not sure about this, but if the above is correct we will be left with only two states. The parallel and the serial. In that case I think it would make sense to remove the do_stealing and do_termination arguments for do_marking_step() and just pass in the is_serial argument. Internally do_marking_step() could set up two local variable to track stealing and termination. That might be good if we see the need in the future to split these up again. Thanks, Bengt On 3/12/13 11:00 PM, John Cuthbertson wrote: > Hi Everyone, > > Here's a new webrev based upon comments from Bengt and Thomas. > > http://cr.openjdk.java.net/~johnc/8009536/webrev.1/ > > This webrev includes the just the changes to resolve the hang seen by > overflowing the marking stack during *serial* reference processing. As > I said in my response to Bengt, this revision will produce the > following assert: > >> [junit4:junit4] 80.722: [GC remark 80.723: [GC ref-proc80.785: [GC >> concurrent-mark-reset-for-overflow] >> [junit4:junit4] # To suppress the following error report, specify >> this argument >> [junit4:junit4] # after -XX: or in .hotspotrc: >> SuppressErrorAt=/concurrentMark.cpp:809 >> [junit4:junit4] # >> [junit4:junit4] # A fatal error has been detected by the Java Runtime >> Environment: >> [junit4:junit4] # >> [junit4:junit4] # Internal Error >> (/export/workspaces/8009536_3/src/share/vm/gc_implementation/g1/concurrentMark.cpp:809), >> pid=16314, tid=14 >> [junit4:junit4] # assert(_finger == _heap_end) failed: only way to >> get here >> [junit4:junit4] # >> [junit4:junit4] # JRE version: Java(TM) SE Runtime Environment >> (8.0-b79) (build 1.8.0-ea-fastdebug-b79) >> [junit4:junit4] # Java VM: Java HotSpot(TM) Server VM >> (25.0-b23-internal-jvmg mixed mode solaris-x86 ) >> [junit4:junit4] # Core dump written. Default location: >> /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/build/analysis/uima/test/J0/core >> or core.16314 >> [junit4:junit4] # >> [junit4:junit4] # An error report file with more information is saved >> as: >> [junit4:junit4] # >> /export/bugs/8009536/lucene-5.0-2013-03-05_15-37-06/build/analysis/uima/test/J0/hs_err_pid16314.log >> [junit4:junit4] # >> [junit4:junit4] # If you would like to submit a bug report, please >> visit: >> [junit4:junit4] # http://bugreport.sun.com/bugreport/crash.jsp >> [junit4:junit4] # >> [junit4:junit4] Current thread is 14 >> [junit4:junit4] Dumping core ... > > when run with parallel reference processing enabled. That fix will be > sent out shortly. > > JohnC > > On 3/11/2013 2:35 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review these changes? The webrev >> can be found at: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/. >> >> First of all - many thanks to Uwe Schindler for discovering an >> reporting the problem and providing very clear instructions on how to >> reproduce the issue. Many thanks also Dawid Weiss for also stepping >> in with a self-contained reproducer. >> >> I also wish to thank Bengt for his help. It was Bengt who gave me the >> magic proxy formula that allowed Ivy to satisfy and download all the >> dependencies for the test case. Bengt also diagnosed the problem and >> gave an initial fix (which the changes in the webrev are based upon). >> >> Summary: >> During the remark pause, the execution of the parallel RemarkTask set >> the number of workers thread in the ParallelTaskTerminator and the >> first and second barrier syncs. During serial reference processing, >> the marking stack overflowed causing the single (VMThread) thread to >> enter the overflow handling code in CMTask::do_marking_step(). This >> overflow code using two WorkBarrierSyncs to synchronize the threads >> before resetting the marking state for restarting marking. The >> barrier syncs were waiting for the number of threads that >> participated in the RemarkTask) but, since only the VM thread was >> executing, only a single thread entered the barrier - resulting in >> the barrier indefinitely waiting for the other (non existent) threads. >> >> A proposed solution was to call set_phase to reset the number of >> threads in the parallel task terminator and the barriers to the >> number of active threads for the reference processing. This solution >> ran into a similar hang while processing the JNI references with >> parallel reference processing enabled. (In parallel reference >> processing, the JNI references are processed serially by the calling >> thread). Resetting the phase to single-threaded before processing the >> JNI refs solved the second hang but resulted in an assertion failure: >> only a concurrentGC thread can enter a barrier sync and the calling >> thread was the VM thread. >> >> Furthermore another problem was discovered. If the marking state is >> reset, a subsequent call to set_phase() will assert as the global >> finger has been set to start of the heap. This was a discovered by >> the marking stack overflowing during the RemarkTask and parallel >> reference processing calling set_phase() to reinitialize number of >> workers in the parallel task terminator. It was also discovered when >> trying out another proposed solution: adding a start_gc closure to >> reference processing which would call set_phase() before each >> processing phase. As a result the marking state is only reset by >> worker 0 if an overflow occurs during the concurrent phase of >> marking; if an overflow occurs during remark, reference processing is >> skipped, and the marking state is reset by the VM thread. Resetting >> the marking state before reference processing was a benign error >> (objects would be marked but not pushed on to the stack as they were >> no longer below the finger; the objects would then be traced, in the >> normal fashion, when marking restarted) but it's better to safe than >> sorry. The other part of the fix for this secondary problem is that >> the parallel reference processing task executor now calls the >> terminator's reset_for_reuse() routine instead of set_phase(). >> >> The resulting solution for the hang is based upon the patch sent out >> by Bengt - namely we do not enter the sync barriers when >> CMTask::do_marking_step() is being called serially. The difference is >> that I added an extra parameter to CMTask::do_marking_step() instead >> of piggy-backing on the existing parameter list. Additionally, if >> this new parameter indicates serial operation, the current thread >> will skip offering termination. This allows the serial drain closure >> to enter the termination protocol and execute the guarantees >> contained therein. >> >> The other changes are for the secondary issues, described above, that >> were discovered while out trying other possible solutions. >> >> Testing: >> The lucene test case with serial reference processing (with and >> without verification); the lucene test case with parallel reference >> processing (with and without verification). >> GC test suite with a mark stack size of 1K and 4K, with both serial >> and parallel reference processing (with and without verification). > From bengt.rutisson at oracle.com Wed Mar 13 13:05:44 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 13 Mar 2013 14:05:44 +0100 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <513FC3F1.8090609@oracle.com> References: <513FC3F1.8090609@oracle.com> Message-ID: <514079A8.8060105@oracle.com> Hi John, Thanks for splitting this up into two webrevs! :) I understand that we only have to reset the marking phase in enter_first_sync_barrier() if we are during concurrent mark since we are anyway doing it in checkpointRootsFinal(). And I think you are correct about the fact that we don't have to drain the discovered references if we have hit an overflow. So, basically I think I understand the changes for 1. and 3. that you explained below. I'm struggling a bit to grasp the change motivated by 2. Are these the calls to set_phase() that triggered the assert before? Do we still need to remove them considering that we no longer reset the marking phase during remark? Also, you replaced the calls to set_phase() with calls to _cm->terminator()->reset_for_reuse(_active_workers). The comment says that this is necessary for the termination protocol in do_marking_step() to work properly. But that method also uses _first_overflow_barrier_sync and _second_overflow_barrier_sync. Don't we have to reset those too? Similarly to what set_phase() does? Finally, why does it say "// Not strictly necessary but..." in G1CMRefProcTaskExecutor::execute() ? Sorry for all the questions, but I'm really not that familiar with this code. Bengt On 3/13/13 1:10 AM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers look over these changes? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/8009940/webrev.0/ > > These changes were, at Bengt's request, split out from the original > webrev for 8009536. In the webrev they have been applied on top of > 8009536 but they are independent. The issue has been in the G1 code > for a while (since I added the reference processing code a couple of > years ago) - we just never hit it. > > Anyway the assertion is caused by calling set_phase() - which throws > the assertion failure - after resetting the marking state - which > resets the value of the global finger. > > The solution was a three pronged approach: > > 1. Skip reference processing if the marking stack overflowed during > the actual remark task. > > This is safe to do as reference objects are only discovered once. So > once a reference object is discovered it will remain on the discovered > list until it is processed. Since, as a result of the overflow, > marking is going to restart - the references will be processed after a > successful remark. We could use the routine > abandon_partial_discovery() and depopulate the discovered lists but > the only benefit to doing this is that we may discover less references > during the subsequent restart. > > 2. Remove the set_phase() calls when we execute a new ref processing > proxy task > > To do this we need to call set_phase() from within weakRefsWork() and > call the terminator's reset_for_reuse() routine when we execute a new > ref processing task. This will remove the path that checks the assert. > > 3. Worker 0 only resets the marking state during the current phase of > marking. > > During the STW remark pause there is another call to reset the marking > stack (in the event of overflow) immediately after the discovered > references are processed: > > double start = os::elapsedTime(); > > checkpointRootsFinalWork(); > > double mark_work_end = os::elapsedTime(); > > weakRefsWork(clear_all_soft_refs); > > if (has_overflown()) { > // Oops. We overflowed. Restart concurrent marking. > _restart_for_overflow = true; > // Clear the marking state because we will be restarting > // marking due to overflowing the global mark stack. > reset_marking_state(); > if (G1TraceMarkStackOverflow) { > gclog_or_tty->print_cr("\nRemark led to restart for overflow."); > } > > I also fixed the British spelling of initialized in a few places. > > Testing: > The lucene tests with parallel reference processing (with and without > verification). > specjvm98 with parallel reference processing (with and without > verification). > > Thanks, > > JohnC From thomas.schatzl at oracle.com Wed Mar 13 13:17:42 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 13 Mar 2013 14:17:42 +0100 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM Message-ID: <1363180662.2535.79.camel@cirrus> Hi all, please review the following change which improves ergonomic heap sizing. Automatic heap sizing now takes available virtual memory into account. The problem occurred when the user reduced the available virtual memory via e.g. ulimit. As ergonomics did not take virtual memory into account, using available physical memory only, the vm typically crashed at startup. This patch does not avoid all crashes due to out of virtual memory, because only heap sizing now takes available virtual memory into account now. Some GCs, and also other parts of the VM, try to reserve hundreds of MB at startup. The main change is in Arguments::allocatable_physical_memory() (which has been moved from the os class) where if an additional virtual memory limit has been imposed on the java process, the given heap size is bounded by a fraction of that limit. That fraction is determined by a new global called MaxVirtMemFraction (default value: 2). Some discussion points: - maybe make MaxVirtMemFraction at least notproduct. It does not seem to make much sense to expose that global to the end user, does it? If the user is able to change MaxVirtMemFraction, he/she may as well set an appropriate maximum heap size with the same effect. - in the OS specific implementations I kept the code duplication for the unix targets (bsd, linux, solaris) as it has been before. I think there is some effort for that going on already. - also in 32 bit implementations, the previously used heuristically found out virtual memory limits (around ~3.8GB) were kept. - for querying the virtual memory limit I used getrlimit() with RLIMIT_AS as parameter. In Solaris there is also RLIMIT_VMEM. Searching in opensolaris code showed that RLIMIT_AS is just another name for RLIMIT_VMEM. Additionally, RLIMIT_AS is the only available parameter for getrlimit() of the two in the posix spec ( http://pubs.opengroup.org/onlinepubs/009696799/functions/getrlimit.html ). This could help later when/if merging the various Unixes. What do you think? Webrev: http://cr.openjdk.java.net/~tschatzl/7112912/webrev/ CR: http://bugs.sun.com/view_bug.do?bug_id=7112912 JIRA: https://jbs.oracle.com/bugs/browse/JDK-7112912 Testing: jprt, local testing with different ulimit values Thomas From thomas.schatzl at oracle.com Wed Mar 13 17:02:35 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 13 Mar 2013 18:02:35 +0100 Subject: RFR (XS): 6733980 par compact - TraceGen1Time always shows 0.0000 seconds Message-ID: <1363194155.2547.0.camel@cirrus> Hi all, please review this change that fixes wrong output. If TraceGen1Time is enabled and parallel compact is used, the output always shows 0.00 seconds. It's a one-line change. Webrev: http://cr.openjdk.java.net/~tschatzl/6733980/webrev/ JIRA: https://jbs.oracle.com/bugs/browse/JDK-6733980 CR: http://bugs.sun.com/view_bug.do?bug_id=6733980 Test: jprt, local runs of dacapo benchmarks with -XX:+TraceGen1Time and -XX: +UseParallelOldGC and -XX:+UseParallelGC -XX:-UseParallelOldGC showing nonzero gen1 times after this fix. From john.cuthbertson at oracle.com Wed Mar 13 17:21:07 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 10:21:07 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <514079A8.8060105@oracle.com> References: <513FC3F1.8090609@oracle.com> <514079A8.8060105@oracle.com> Message-ID: <5140B583.3090309@oracle.com> Hi Bengt, Thanks for looking at the code. I'm happy to answer questions. On 3/13/2013 6:05 AM, Bengt Rutisson wrote: > > Hi John, > > Thanks for splitting this up into two webrevs! :) > > I understand that we only have to reset the marking phase in > enter_first_sync_barrier() if we are during concurrent mark since we > are anyway doing it in checkpointRootsFinal(). And I think you are > correct about the fact that we don't have to drain the discovered > references if we have hit an overflow. > > So, basically I think I understand the changes for 1. and 3. that you > explained below. > > I'm struggling a bit to grasp the change motivated by 2. Are these the > calls to set_phase() that triggered the assert before? Do we still > need to remove them considering that we no longer reset the marking > phase during remark? Yes - these are the calls that triggered the asserts. Here's the stack trace: Stack: [0xd817f000,0xd81ff000], sp=0xd81fe34c, free space=508k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xdcaeac] void VMError::report(outputStream*)+0xdec V [libjvm.so+0xdcc205] void VMError::report_and_die()+0x735 V [libjvm.so+0x6af46b] void report_vm_error(const char*,int,const char*,const char*)+0x8b V [libjvm.so+0x65e6a3] void ConcurrentMark::set_phase(unsigned,bool)+0x1a3 V [libjvm.so+0x660534] void G1CMRefProcTaskExecutor::execute(AbstractRefProcTaskExecutor::ProcessTask&)+0xc4 V [libjvm.so+0xc5275c] void ReferenceProcessor::process_discovered_reflist(DiscoveredList*,ReferencePolicy*,bool,BoolObjectClosure*,OopClosure*,VoidClosure*,AbstractRefProcTaskExecutor*)+0x25c V [libjvm.so+0xc50af6] void ReferenceProcessor::process_discovered_references(BoolObjectClosure*,OopClosure*,VoidClosure*,AbstractRefProcTaskExecutor*)+0x266 V [libjvm.so+0x660975] void ConcurrentMark::weakRefsWork(bool)+0x2d5 V [libjvm.so+0x65f593] void ConcurrentMark::checkpointRootsFinal(bool)+0x153 V [libjvm.so+0x6983e8] void CMCheckpointRootsFinalClosure::do_void()+0x18 V [libjvm.so+0xe0ecd1] void VM_CGC_Operation::doit()+0xe1 V [libjvm.so+0xe0b82d] void VM_Operation::evaluate()+0x7d V [libjvm.so+0xe0938c] void VMThread::evaluate_operation(VM_Operation*)+0x9c V [libjvm.so+0xe09960] void VMThread::loop()+0x4d0 V [libjvm.so+0xe08fc1] void VMThread::run()+0x111 V [libjvm.so+0xbb1490] java_start+0x210 C [libc.so.1+0xa73b7] _thr_setup+0x4e C [libc.so.1+0xa76a0] __moddi3+0x60 If a stack overflow occurred when executing one ref processing task, set the phase in the next would assert. > > Also, you replaced the calls to set_phase() with calls to > _cm->terminator()->reset_for_reuse(_active_workers). The comment says > that this is necessary for the termination protocol in > do_marking_step() to work properly. But that method also uses > _first_overflow_barrier_sync and _second_overflow_barrier_sync. Don't > we have to reset those too? Similarly to what set_phase() does? AFAICT we don't need to reset the first and second barrier syncs. ConcurrentMark::set_phase(active_workers,...._) initializes the _terminator with a new ParallelTaskTerminator instance with the given number of workers; the value of the _offered_termination field is zeroed. When a worker offers termination, _offered_terminatation is incremented. The only ways to reset the value of _offered_termination is to create a new instance (as set_phase does) or call reset_for_reuse(): > void ParallelTaskTerminator::reset_for_reuse() { > if (_offered_termination != 0) { > assert(_offered_termination == _n_threads, > "Terminator may still be in use"); > _offered_termination = 0; > } > } to reuse the existing terminator but with new values in the _offered_termination and _n_threads fields. Note: reset_for_reuse() is not called when the number of threads offering termination reaches the number of threads to wait for. We have to do it explicitly. Compare this with WorkGangBarrierSync. Set_phase() calls set_n_threads() for the first and second barriers. This routine sets _n_workers to give number of threads and clears _n_completed, _should_reset: > void WorkGangBarrierSync::set_n_workers(uint n_workers) { > _n_workers = n_workers; > _n_completed = 0; > _should_reset = false; > } When the last thread to enter the barrier sync does so, the value of _should_reset is set to true. When do_marking_step is called for the next ref processing task, the first to enter the barrier resets the value of _n_completed: > void WorkGangBarrierSync::enter() { > MutexLockerEx x(monitor(), Mutex::_no_safepoint_check_flag); > if (should_reset()) { > // The should_reset() was set and we are the first worker to enter > // the sync barrier. We will zero the n_completed() count which > // effectively resets the barrier. > zero_completed(); > set_should_reset(false); > } Hence we don't need to explicitly reset the barrier syncs. Make sense? After answering your question I realize I should be calling the version of reset_for_reuse() that takes no parameters. We want to change the value of _n_threads in the terminator because it could then be changed to a value different from that in the barrier syncs. > Finally, why does it say "// Not strictly necessary but..." in > G1CMRefProcTaskExecutor::execute() ? It's not necessary because the enqueue task doesn't interact with the parallel task terminator (i.e. it doesn't call do_marking_step). It just turns around and calls RefProcEnqueueTask::work(). It just increased the similarity and symmetry of the two execute() routines and adds a little bit of "just in case". Cheers, JohnC From john.cuthbertson at oracle.com Wed Mar 13 17:57:25 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 10:57:25 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <5140534E.7050607@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> Message-ID: <5140BE05.50206@oracle.com> Hi Bengt, Thanks for looking at the change again. Replies inline.... On 3/13/2013 3:22 AM, Bengt Rutisson wrote: > > > Hi John, > > I'm not too familiar with the do_marking_step() code, so I'm trying to > get to know it while I'm looking at your webrev. So, maybe I'm > completely off here, but I think there are a couple of strange things. > > After your change do_marking_step() takes three bools: do_stealing, > do_termination and is_serial. > > This means that we have 8 possible states if we combine all value of > these bools. I went through all calls to do_marking_step() and it > seems like we make use of 4 of those states: > > > G1CMKeepAliveAndDrainClosure::do_oop_work() > do_marking_step(false, false, true) (1) > > CMConcurrentMarkingTask::work() > do_marking_step(true, true, false) (2) > > CMRemarkTask::work() > do_marking_step(true, true, false) (2) > do_marking_step(true, true, true) (3) > > G1CMDrainMarkingStackClosure::do_void() > do_marking_step(false, true, true) (4) > do_marking_step(true, true, false) (2) > Yeah. Well... > > I numbered the states (1) - (4). Here are all states and I marked > which ones we use: > > stealing, termination, serial (3) > stealing, !termination, serial > stealing, !termination, !serial > stealing, termination, !serial (2) parallel > !stealing, termination, serial (4) > !stealing, !termination, serial (1) serial > !stealing, !termination, !serial > !stealing, termination, !serial > > > I think state (2) makes sense as the parallel case. We do stealing and > termination and we are not serial. State (1) also makes sense. It is > clearly the serial case. No stealing or termination. Just serial. > > Now, case (3) looks odd to me. We say we are serial but we want to do > stealing and termination. This case comes from CMRemarkTask. It takes > a is_serial argument in its constructor. We get to case (3) from > ConcurrentMark::checkpointRootsFinalWork(), where we do: > > if (G1CollectedHeap::use_parallel_gc_threads()) { > ... > } else { > ... > CMRemarkTask remarkTask(this, active_workers, true /* is_serial*/); > } > > To me this looks like it should lead to the pure serial case (1) > instead of (3). Do you agree? In that case I think > CMRemarkTask::work() needs to be changed to do: > > task->do_marking_step(1000000000.0 /* something very large */, > !_is_serial /* do_stealing */, > !_is_serial /* do_termination */, > _is_serial); > You're right here. The serial remark case should not enable stealing. It doesn't make sense. Done! > > The other case that sticks out is (4). We don't want to do stealing, > but we want to do termination even though we are serial. This comes > from how we set up the g1_drain_mark_stack in > ConcurrentMark::weakRefsWork(). We pass that along to the reference > processing, which I think is serial (wasn't that the original problem? > :) ). We also pass the g1_keep_alive which is set up to be in state > (1). So, I wonder if it is correct that the g1_drain_mark_stack is in > state (4). If you agree that we should be using the pure serial case > here too, I think we need to change > G1CMDrainMarkingStackClosure::do_void() to be: > > _task->do_marking_step(1000000000.0 /* something very large */, > !_is_serial /* do_stealing */, > !_is_serial /* do_termination */, > _is_serial /* is_serial */); > > That is what we had before and I wasn't happy with it. The serial drain closure is the last thing that get's executed as part of reference processing - when process_phaseJNI invokes the complete_gc.do_void() method. In the drain closure either serial or parallel I think we want to go through the termination protocol. We just don't want to interact with the terminator in the serial case. There's a bunch of guarantees and checks in the termination protocol and we should still go through them - even when serial. > > Again, I'm not sure about this, but if the above is correct we will be > left with only two states. The parallel and the serial. In that case I > think it would make sense to remove the do_stealing and do_termination > arguments for do_marking_step() and just pass in the is_serial > argument. Internally do_marking_step() could set up two local variable > to track stealing and termination. That might be good if we see the > need in the future to split these up again. I think we can get rid of the do_stealing parameter - it's always the negation of the is_serial parameter and I like the idea of making it a local. How about that? For example void CMTask::do_marking_step(double ms, bool do_termination, bool is_serial) { // It does not make sense to allow stealing when called serially. bool do_stealing = !is_serial; Thanks, JohnC From john.cuthbertson at oracle.com Wed Mar 13 18:12:26 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 11:12:26 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <5140B583.3090309@oracle.com> References: <513FC3F1.8090609@oracle.com> <514079A8.8060105@oracle.com> <5140B583.3090309@oracle.com> Message-ID: <5140C18A.1070408@oracle.com> Hi Everyone, Small error.... On 3/13/2013 10:21 AM, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking at the code. I'm happy to answer questions. > > On 3/13/2013 6:05 AM, Bengt Rutisson wrote: >> >> Hi John, >> >> Thanks for splitting this up into two webrevs! :) >> >> I understand that we only have to reset the marking phase in >> enter_first_sync_barrier() if we are during concurrent mark since we >> are anyway doing it in checkpointRootsFinal(). And I think you are >> correct about the fact that we don't have to drain the discovered >> references if we have hit an overflow. >> >> So, basically I think I understand the changes for 1. and 3. that you >> explained below. >> >> I'm struggling a bit to grasp the change motivated by 2. Are these >> the calls to set_phase() that triggered the assert before? Do we >> still need to remove them considering that we no longer reset the >> marking phase during remark? > > Yes - these are the calls that triggered the asserts. Here's the stack > trace: > > Stack: [0xd817f000,0xd81ff000], sp=0xd81fe34c, free space=508k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xdcaeac] void VMError::report(outputStream*)+0xdec > V [libjvm.so+0xdcc205] void VMError::report_and_die()+0x735 > V [libjvm.so+0x6af46b] void report_vm_error(const char*,int,const > char*,const char*)+0x8b > V [libjvm.so+0x65e6a3] void > ConcurrentMark::set_phase(unsigned,bool)+0x1a3 > V [libjvm.so+0x660534] void > G1CMRefProcTaskExecutor::execute(AbstractRefProcTaskExecutor::ProcessTask&)+0xc4 > V [libjvm.so+0xc5275c] void > ReferenceProcessor::process_discovered_reflist(DiscoveredList*,ReferencePolicy*,bool,BoolObjectClosure*,OopClosure*,VoidClosure*,AbstractRefProcTaskExecutor*)+0x25c > V [libjvm.so+0xc50af6] void > ReferenceProcessor::process_discovered_references(BoolObjectClosure*,OopClosure*,VoidClosure*,AbstractRefProcTaskExecutor*)+0x266 > V [libjvm.so+0x660975] void ConcurrentMark::weakRefsWork(bool)+0x2d5 > V [libjvm.so+0x65f593] void > ConcurrentMark::checkpointRootsFinal(bool)+0x153 > V [libjvm.so+0x6983e8] void CMCheckpointRootsFinalClosure::do_void()+0x18 > V [libjvm.so+0xe0ecd1] void VM_CGC_Operation::doit()+0xe1 > V [libjvm.so+0xe0b82d] void VM_Operation::evaluate()+0x7d > V [libjvm.so+0xe0938c] void > VMThread::evaluate_operation(VM_Operation*)+0x9c > V [libjvm.so+0xe09960] void VMThread::loop()+0x4d0 > V [libjvm.so+0xe08fc1] void VMThread::run()+0x111 > V [libjvm.so+0xbb1490] java_start+0x210 > C [libc.so.1+0xa73b7] _thr_setup+0x4e > C [libc.so.1+0xa76a0] __moddi3+0x60 > > If a stack overflow occurred when executing one ref processing task, > set the phase in the next would assert. > >> >> Also, you replaced the calls to set_phase() with calls to >> _cm->terminator()->reset_for_reuse(_active_workers). The comment says >> that this is necessary for the termination protocol in >> do_marking_step() to work properly. But that method also uses >> _first_overflow_barrier_sync and _second_overflow_barrier_sync. Don't >> we have to reset those too? Similarly to what set_phase() does? > > AFAICT we don't need to reset the first and second barrier syncs. > > ConcurrentMark::set_phase(active_workers,...._) initializes the > _terminator with a new ParallelTaskTerminator instance with the given > number of workers; the value of the _offered_termination field is > zeroed. When a worker offers termination, _offered_terminatation is > incremented. The only ways to reset the value of _offered_termination > is to create a new instance (as set_phase does) or call > reset_for_reuse(): > >> void ParallelTaskTerminator::reset_for_reuse() { >> if (_offered_termination != 0) { >> assert(_offered_termination == _n_threads, >> "Terminator may still be in use"); >> _offered_termination = 0; >> } >> } > > to reuse the existing terminator but with new values in the > _offered_termination and _n_threads fields. Note: reset_for_reuse() is > not called when the number of threads offering termination reaches the > number of threads to wait for. We have to do it explicitly. > > Compare this with WorkGangBarrierSync. Set_phase() calls > set_n_threads() for the first and second barriers. This routine sets > _n_workers to give number of threads and clears _n_completed, > _should_reset: > >> void WorkGangBarrierSync::set_n_workers(uint n_workers) { >> _n_workers = n_workers; >> _n_completed = 0; >> _should_reset = false; >> } > > When the last thread to enter the barrier sync does so, the value of > _should_reset is set to true. When do_marking_step is called for the > next ref processing task, the first to enter the barrier resets the > value of _n_completed: > >> void WorkGangBarrierSync::enter() { >> MutexLockerEx x(monitor(), Mutex::_no_safepoint_check_flag); >> if (should_reset()) { >> // The should_reset() was set and we are the first worker to enter >> // the sync barrier. We will zero the n_completed() count which >> // effectively resets the barrier. >> zero_completed(); >> set_should_reset(false); >> } > > Hence we don't need to explicitly reset the barrier syncs. Make sense? > > After answering your question I realize I should be calling the > version of reset_for_reuse() that takes no parameters. We want to > change the value of _n_threads in the terminator because it could then > be changed to a value different from that in the barrier syncs. The sentence above should be "We *don't* want to change the value of _n_threads...." Apologies, JohnC From john.cuthbertson at oracle.com Wed Mar 13 18:14:39 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 11:14:39 -0700 Subject: RFR (XS): 6733980 par compact - TraceGen1Time always shows 0.0000 seconds In-Reply-To: <1363194155.2547.0.camel@cirrus> References: <1363194155.2547.0.camel@cirrus> Message-ID: <5140C20F.3060009@oracle.com> Hi Thomas, This looks good to me. JohnC On 3/13/2013 10:02 AM, Thomas Schatzl wrote: > Hi all, > > please review this change that fixes wrong output. If TraceGen1Time is > enabled and parallel compact is used, the output always shows 0.00 > seconds. > > It's a one-line change. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/6733980/webrev/ > > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-6733980 > > CR: > http://bugs.sun.com/view_bug.do?bug_id=6733980 > > > Test: > jprt, local runs of dacapo benchmarks with -XX:+TraceGen1Time and -XX: > +UseParallelOldGC and -XX:+UseParallelGC -XX:-UseParallelOldGC showing > nonzero gen1 times after this fix. > > > > From jon.masamitsu at oracle.com Wed Mar 13 18:28:04 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 13 Mar 2013 11:28:04 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <513FC3F1.8090609@oracle.com> References: <513FC3F1.8090609@oracle.com> Message-ID: <5140C534.30409@oracle.com> John, No comments affecting the correctness of the change so looks good. 979 // If we're during the concurrent phase of marking, reset the marking during -> doing ? From concurrentMark.hpp // It should be called to indicate which phase we're in (concurrent // mark or remark) and how many threads are currently active. void set_phase(uint active_tasks, bool concurrent); Is there a better name that we can give to set_phase() so that we know if should only be called once per phase (if that is in fact true?)? Maybe set_phase_on_entry() or initialize_phase() or set_phase_start(). Also set_phase() seems to have much to do with the concurrency of the phase so maybe set_concurrency(), set_concurrency_on_entr(), initialize_concurrency(), set_concurrency_start(). 2403 // Not strictly necessary but... 2404 // 2405 // We need to reset the number of workers in the parallel 2406 // task terminator, before each proxy task execution, so 2407 // that the termination protocol in CMTask::do_marking_step() 2408 // knows how many workers to wait for. 2409 _cm->terminator()->reset_for_reuse(_active_workers); If you're reusing a ParallelTaskTerminator, I think it really is best to not assume that it can be reused. On 3/12/2013 5:10 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers look over these changes? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/8009940/webrev.0/ > > These changes were, at Bengt's request, split out from the original > webrev for 8009536. In the webrev they have been applied on top of > 8009536 but they are independent. The issue has been in the G1 code > for a while (since I added the reference processing code a couple of > years ago) - we just never hit it. > > Anyway the assertion is caused by calling set_phase() - which throws > the assertion failure - after resetting the marking state - which > resets the value of the global finger. Is set_phase() actually safe to call other than the assertion that fires if the global finger is reset? Jon > > The solution was a three pronged approach: > > 1. Skip reference processing if the marking stack overflowed during > the actual remark task. > > This is safe to do as reference objects are only discovered once. So > once a reference object is discovered it will remain on the discovered > list until it is processed. Since, as a result of the overflow, > marking is going to restart - the references will be processed after a > successful remark. We could use the routine > abandon_partial_discovery() and depopulate the discovered lists but > the only benefit to doing this is that we may discover less references > during the subsequent restart. > > 2. Remove the set_phase() calls when we execute a new ref processing > proxy task > > To do this we need to call set_phase() from within weakRefsWork() and > call the terminator's reset_for_reuse() routine when we execute a new > ref processing task. This will remove the path that checks the assert. > > 3. Worker 0 only resets the marking state during the current phase of > marking. > > During the STW remark pause there is another call to reset the marking > stack (in the event of overflow) immediately after the discovered > references are processed: > > double start = os::elapsedTime(); > > checkpointRootsFinalWork(); > > double mark_work_end = os::elapsedTime(); > > weakRefsWork(clear_all_soft_refs); > > if (has_overflown()) { > // Oops. We overflowed. Restart concurrent marking. > _restart_for_overflow = true; > // Clear the marking state because we will be restarting > // marking due to overflowing the global mark stack. > reset_marking_state(); > if (G1TraceMarkStackOverflow) { > gclog_or_tty->print_cr("\nRemark led to restart for overflow."); > } > > I also fixed the British spelling of initialized in a few places. > > Testing: > The lucene tests with parallel reference processing (with and without > verification). > specjvm98 with parallel reference processing (with and without > verification). > > Thanks, > > JohnC From erik.helin at oracle.com Wed Mar 13 18:35:38 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Mar 2013 19:35:38 +0100 Subject: RFR (S): 8008737: The trace event vm/gc/heap/summary is missing for CMS In-Reply-To: <5129E024.2040900@oracle.com> References: <5129E024.2040900@oracle.com> Message-ID: <5140C6FA.5030504@oracle.com> All, the previous two changes, webrev.00 and webrev.01, did not ensure that CMS collector had the heap lock when the call to capacity was being done. This did not cause any error during testing, but it could lead to strange bugs. I have therefore updated the change to take this into account. The new change, webrev.02, ensures that the heap summary data is only saved when the concurrent CMS collector has the heap lock. Since "collect_in_background" can be aborted for various reasons, the heap statistics are saved at three places for a concurrent CMS collection: 1. Initial mark 2. Final remark 3. Resizing The heap summary that will be sent for a concurrent CMS collection depend on how much progress the CMS background collector has done, the most recent one will always be sent. The same is being done for a foreground CMS collection, but then it is guaranteed that the heap summary will always be from the last save point, Resizing, since a foreground CMS collection can not be aborted. Please see the new webrev located at: http://cr.openjdk.java.net/~ehelin/8008737/webrev.02/ Thanks, Erik On 02/24/2013 10:40 AM, Erik Helin wrote: > Hi all, > > this change adds the trace event vm/gc/heap/summary to the CMS collector. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8008737/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008737 > > Testing: > JPRT > > Thanks, > Erik From jon.masamitsu at oracle.com Wed Mar 13 18:49:04 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 13 Mar 2013 11:49:04 -0700 Subject: RFR (XS): 6733980 par compact - TraceGen1Time always shows 0.0000 seconds In-Reply-To: <1363194155.2547.0.camel@cirrus> References: <1363194155.2547.0.camel@cirrus> Message-ID: <5140CA20.4040502@oracle.com> Looks good. Jon On 3/13/2013 10:02 AM, Thomas Schatzl wrote: > Hi all, > > please review this change that fixes wrong output. If TraceGen1Time is > enabled and parallel compact is used, the output always shows 0.00 > seconds. > > It's a one-line change. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/6733980/webrev/ > > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-6733980 > > CR: > http://bugs.sun.com/view_bug.do?bug_id=6733980 > > > Test: > jprt, local runs of dacapo benchmarks with -XX:+TraceGen1Time and -XX: > +UseParallelOldGC and -XX:+UseParallelGC -XX:-UseParallelOldGC showing > nonzero gen1 times after this fix. > > > > From john.cuthbertson at oracle.com Wed Mar 13 19:04:11 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 12:04:11 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <5140BE05.50206@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> <5140BE05.50206@oracle.com> Message-ID: <5140CDAB.3050400@oracle.com> Hi Everyone, Slight correction... On 3/13/2013 10:57 AM, John Cuthbertson wrote: > > I think we can get rid of the do_stealing parameter - it's always the > negation of the is_serial parameter and I like the idea of making it a > local. How about that? For example > > void CMTask::do_marking_step(double ms, bool do_termination, bool > is_serial) { > // It does not make sense to allow stealing when called serially. > bool do_stealing = !is_serial; After going through the cases enumerated by Bengt (thanks for doing that BTW), the correct conditions where stealing should be enabled are: bool do_stealing = !is_serial && do_termination; The rationale is that we should check to see if there's anything to steal if we're about to enter termination protocol (and we're not serial). In the case when do_termination is false (the keep_alive closure) we want to get back, as quickly as we can, to processing references after the intermediate drain. New webrev soon. Thanks, JohnC From tao.mao at oracle.com Wed Mar 13 19:15:20 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 13 Mar 2013 12:15:20 -0700 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <1363180662.2535.79.camel@cirrus> References: <1363180662.2535.79.camel@cirrus> Message-ID: <5140D048.6030600@oracle.com> BTW, upon completion of this CR, please also investigate a CR with similar problems (most likely, close as a duplicate) . https://jbs.oracle.com/bugs/browse/JDK-6374896 Please see inline. Tao On 3/13/13 6:17 AM, Thomas Schatzl wrote: > Hi all, > > please review the following change which improves ergonomic heap > sizing. Automatic heap sizing now takes available virtual memory into > account. > > The problem occurred when the user reduced the available virtual memory > via e.g. ulimit. As ergonomics did not take virtual memory into account, > using available physical memory only, the vm typically crashed at > startup. > > This patch does not avoid all crashes due to out of virtual memory, > because only heap sizing now takes available virtual memory into account > now. Some GCs, and also other parts of the VM, try to reserve hundreds > of MB at startup. I don't quite understand what you mean here. Does it indicate that the default value (i.e. 2) chosen for MaxVirMemFraction is a bit large? (when it has the effect of limiting the head size, the virtual memory would be small already.) > > The main change is in Arguments::allocatable_physical_memory() (which > has been moved from the os class) where if an additional virtual memory > limit has been imposed on the java process, the given heap size is > bounded by a fraction of that limit. It kind of violates parallelism here, for Arguments::allocatable_physical_memory() and os::physical_memory() are now defined in different classes while they should have the same level of abstraction. Seems better to keep allocatable_physical_memory() back in os due to its closeness to os. > > That fraction is determined by a new global called MaxVirtMemFraction > (default value: 2). follow the style 1946 product(uintx, MaxRAMFraction, 4, \ 1947 "Maximum fraction (1/n) of real memory used for maximum heap " \ 1948 "size") \ would be reasonable to phrase the definition similarly, say, 1961 product(uintx, MaxVirtMemFraction, 2, \ 1962 "*Maximum* fraction (1/n) of virtual memory used for*maximum* heap size") \ 1963 \ > > Some discussion points: > - maybe make MaxVirtMemFraction at least notproduct. It does not seem > to make much sense to expose that global to the end user, does it? If > the user is able to change MaxVirtMemFraction, he/she may as well set an > appropriate maximum heap size with the same effect. Makes sense. > - in the OS specific implementations I kept the code duplication for > the unix targets (bsd, linux, solaris) as it has been before. I think > there is some effort for that going on already. > - also in 32 bit implementations, the previously used heuristically > found out virtual memory limits (around ~3.8GB) were kept. > - for querying the virtual memory limit I used getrlimit() with > RLIMIT_AS as parameter. In Solaris there is also RLIMIT_VMEM. Searching > in opensolaris code showed that RLIMIT_AS is just another name for > RLIMIT_VMEM. Additionally, RLIMIT_AS is the only available parameter for > getrlimit() of the two in the posix spec > ( http://pubs.opengroup.org/onlinepubs/009696799/functions/getrlimit.html ). This could help later when/if merging the various Unixes. > > What do you think? > > Webrev: > http://cr.openjdk.java.net/~tschatzl/7112912/webrev/ (1) you may want to rephrase the comment or delete it 2607 // Make sure that if we have a lot of memory we cap the 32 bit 2608 // process space. The 64bit VM version of this function is a nop. 2609 initHeapSize = allocatable_physical_memory(initHeapSize); (2) I also prefer a pointer argument here. It's more readable to recognize its intention of usage. 187 static bool has_allocatable_memory_limit(julong& limit); > > CR: > http://bugs.sun.com/view_bug.do?bug_id=7112912 > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-7112912 > > Testing: > jprt, local testing with different ulimit values Did you test out all(or, most) platform combinations (solaris/bsd/linux/windows + 32/64 bit) to verify the current code can get the right size of virtual memory? > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Wed Mar 13 19:18:22 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 12:18:22 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <5140C534.30409@oracle.com> References: <513FC3F1.8090609@oracle.com> <5140C534.30409@oracle.com> Message-ID: <5140D0FE.30209@oracle.com> Hi Jon, Thank you for looking at the code changes. On 3/13/2013 11:28 AM, Jon Masamitsu wrote: > John, > > No comments affecting the correctness of the > change so looks good. > > > 979 // If we're during the concurrent phase of marking, reset the > marking > > during -> doing ? OK. Whatever communicates that the overflow is seen while the concurrent phase is active. > > From concurrentMark.hpp > > // It should be called to indicate which phase we're in (concurrent > // mark or remark) and how many threads are currently active. > void set_phase(uint active_tasks, bool concurrent); > > Is there a better name that we can give to set_phase() so > that we know if should only be called once per phase (if that > is in fact true?)? Maybe set_phase_on_entry() or > initialize_phase() or set_phase_start(). > > Also set_phase() seems to have much to do with the > concurrency of the phase so maybe set_concurrency(), > set_concurrency_on_entr(), initialize_concurrency(), > set_concurrency_start(). Actually I like set_concurrency_and_phase(...). > 2403 // Not strictly necessary but... > 2404 // > 2405 // We need to reset the number of workers in the parallel > 2406 // task terminator, before each proxy task execution, so > 2407 // that the termination protocol in CMTask::do_marking_step() > 2408 // knows how many workers to wait for. > 2409 _cm->terminator()->reset_for_reuse(_active_workers); > > If you're reusing a ParallelTaskTerminator, I think it really is best > to not assume that it can be reused. OK. Kind of prompts the change I'll suggest below. > > On 3/12/2013 5:10 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers look over these changes? The webrev >> can be found at: http://cr.openjdk.java.net/~johnc/8009940/webrev.0/ >> >> These changes were, at Bengt's request, split out from the original >> webrev for 8009536. In the webrev they have been applied on top of >> 8009536 but they are independent. The issue has been in the G1 code >> for a while (since I added the reference processing code a couple of >> years ago) - we just never hit it. >> >> Anyway the assertion is caused by calling set_phase() - which throws >> the assertion failure - after resetting the marking state - which >> resets the value of the global finger. > > Is set_phase() actually safe to call other than the assertion that fires > if the global finger is reset? set_phase() was actually safe to call (other than the assert). Even resetting the global finger is, I believe, safe. Doing so means that we would mark object but would no longer push them - as they are no longer below the finger. Objects are pushed so that they can be traced. Since marking is going to be restarted, the marked objects would be traced in the normal manner when marking reaches them. Since it's not safe to reuse a parallel task terminator (I didn't know that) my suggestion is: * break out the concurrency-related code from set_phase() into it's own routine. * call that routine within set_phase (now renamed set_concurrency_and_phase) * call the set_concurrency routine within the parallel reference processing. That should also address Bengt's concern about the inconsistency between the parallel task terminator and the WorkGangBarrierSyncs. Sound reasonable? Thanks! JohnC From jon.masamitsu at oracle.com Wed Mar 13 20:21:05 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 13 Mar 2013 13:21:05 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <5140D0FE.30209@oracle.com> References: <513FC3F1.8090609@oracle.com> <5140C534.30409@oracle.com> <5140D0FE.30209@oracle.com> Message-ID: <5140DFB1.2000202@oracle.com> On 3/13/2013 12:18 PM, John Cuthbertson wrote: > Hi Jon, > > Thank you for looking at the code changes. > > On 3/13/2013 11:28 AM, Jon Masamitsu wrote: >> John, >> >> No comments affecting the correctness of the >> change so looks good. >> >> >> 979 // If we're during the concurrent phase of marking, reset the >> marking >> >> during -> doing ? > > OK. Whatever communicates that the overflow is seen while the > concurrent phase is active. I would then use "If we're executing the concurrent phase ..." > >> >> From concurrentMark.hpp >> >> // It should be called to indicate which phase we're in (concurrent >> // mark or remark) and how many threads are currently active. >> void set_phase(uint active_tasks, bool concurrent); >> >> Is there a better name that we can give to set_phase() so >> that we know if should only be called once per phase (if that >> is in fact true?)? Maybe set_phase_on_entry() or >> initialize_phase() or set_phase_start(). >> >> Also set_phase() seems to have much to do with the >> concurrency of the phase so maybe set_concurrency(), >> set_concurrency_on_entr(), initialize_concurrency(), >> set_concurrency_start(). > > Actually I like set_concurrency_and_phase(...). OK. > >> 2403 // Not strictly necessary but... >> 2404 // >> 2405 // We need to reset the number of workers in the parallel >> 2406 // task terminator, before each proxy task execution, so >> 2407 // that the termination protocol in CMTask::do_marking_step() >> 2408 // knows how many workers to wait for. >> 2409 _cm->terminator()->reset_for_reuse(_active_workers); >> >> If you're reusing a ParallelTaskTerminator, I think it really is best >> to not assume that it can be reused. > > OK. Kind of prompts the change I'll suggest below. > >> >> On 3/12/2013 5:10 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers look over these changes? The >>> webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/8009940/webrev.0/ >>> >>> These changes were, at Bengt's request, split out from the original >>> webrev for 8009536. In the webrev they have been applied on top of >>> 8009536 but they are independent. The issue has been in the G1 code >>> for a while (since I added the reference processing code a couple of >>> years ago) - we just never hit it. >>> >>> Anyway the assertion is caused by calling set_phase() - which throws >>> the assertion failure - after resetting the marking state - which >>> resets the value of the global finger. >> >> Is set_phase() actually safe to call other than the assertion that fires >> if the global finger is reset? > > set_phase() was actually safe to call (other than the assert). Even > resetting the global finger is, I believe, safe. Doing so means that > we would mark object but would no longer push them - as they are no > longer below the finger. Objects are pushed so that they can be > traced. Since marking is going to be restarted, the marked objects > would be traced in the normal manner when marking reaches them. > > Since it's not safe to reuse a parallel task terminator (I didn't know > that) my suggestion is: Here's the more complete thought. If you're going to reuse a parallel task terminator and it has been used before, then reset_for_reuse() needs to be called on it. If it has not been used before, then it's safe to use without a call to reset_for_reuse(). If in doubt or the use of the parallel task terminator could possibly change, call reset_for_reuse(). > > * break out the concurrency-related code from set_phase() into it's > own routine. > * call that routine within set_phase (now renamed > set_concurrency_and_phase) > * call the set_concurrency routine within the parallel reference > processing. > > That should also address Bengt's concern about the inconsistency > between the parallel task terminator and the WorkGangBarrierSyncs. > > Sound reasonable? I like it. Thanks; Jon > > Thanks! > > JohnC > From bengt.rutisson at oracle.com Wed Mar 13 21:01:42 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 13 Mar 2013 22:01:42 +0100 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <5140BE05.50206@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> <5140BE05.50206@oracle.com> Message-ID: <5140E936.1020903@oracle.com> Hi John, Thanks for explaining a bit about the serial case where we still need to go through termination protocol. As you know I'll be on vacation the next two days, so I just wanted to let you know that with the changes that you outline below (the fix to CMRemarkTask and removing the do_stealing argument) I'm fine with this change. Feel free to push this if you get another review. Thanks, Bengt On 3/13/13 6:57 PM, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking at the change again. Replies inline.... > > On 3/13/2013 3:22 AM, Bengt Rutisson wrote: >> >> >> Hi John, >> >> I'm not too familiar with the do_marking_step() code, so I'm trying >> to get to know it while I'm looking at your webrev. So, maybe I'm >> completely off here, but I think there are a couple of strange things. >> >> After your change do_marking_step() takes three bools: do_stealing, >> do_termination and is_serial. >> >> This means that we have 8 possible states if we combine all value of >> these bools. I went through all calls to do_marking_step() and it >> seems like we make use of 4 of those states: >> >> >> G1CMKeepAliveAndDrainClosure::do_oop_work() >> do_marking_step(false, false, true) (1) >> >> CMConcurrentMarkingTask::work() >> do_marking_step(true, true, false) (2) >> >> CMRemarkTask::work() >> do_marking_step(true, true, false) (2) >> do_marking_step(true, true, true) (3) >> >> G1CMDrainMarkingStackClosure::do_void() >> do_marking_step(false, true, true) (4) >> do_marking_step(true, true, false) (2) >> > > Yeah. Well... > >> >> I numbered the states (1) - (4). Here are all states and I marked >> which ones we use: >> >> stealing, termination, serial (3) >> stealing, !termination, serial >> stealing, !termination, !serial >> stealing, termination, !serial (2) parallel >> !stealing, termination, serial (4) >> !stealing, !termination, serial (1) serial >> !stealing, !termination, !serial >> !stealing, termination, !serial >> >> >> I think state (2) makes sense as the parallel case. We do stealing >> and termination and we are not serial. State (1) also makes sense. It >> is clearly the serial case. No stealing or termination. Just serial. >> >> Now, case (3) looks odd to me. We say we are serial but we want to do >> stealing and termination. This case comes from CMRemarkTask. It takes >> a is_serial argument in its constructor. We get to case (3) from >> ConcurrentMark::checkpointRootsFinalWork(), where we do: >> >> if (G1CollectedHeap::use_parallel_gc_threads()) { >> ... >> } else { >> ... >> CMRemarkTask remarkTask(this, active_workers, true /* is_serial*/); >> } >> >> To me this looks like it should lead to the pure serial case (1) >> instead of (3). Do you agree? In that case I think >> CMRemarkTask::work() needs to be changed to do: >> >> task->do_marking_step(1000000000.0 /* something very large */, >> !_is_serial /* do_stealing */, >> !_is_serial /* do_termination */, >> _is_serial); >> > > You're right here. The serial remark case should not enable stealing. > It doesn't make sense. Done! > >> >> The other case that sticks out is (4). We don't want to do stealing, >> but we want to do termination even though we are serial. This comes >> from how we set up the g1_drain_mark_stack in >> ConcurrentMark::weakRefsWork(). We pass that along to the reference >> processing, which I think is serial (wasn't that the original >> problem? :) ). We also pass the g1_keep_alive which is set up to be >> in state (1). So, I wonder if it is correct that the >> g1_drain_mark_stack is in state (4). If you agree that we should be >> using the pure serial case here too, I think we need to change >> G1CMDrainMarkingStackClosure::do_void() to be: >> >> _task->do_marking_step(1000000000.0 /* something very large */, >> !_is_serial /* do_stealing */, >> !_is_serial /* do_termination */, >> _is_serial /* is_serial */); >> >> > > That is what we had before and I wasn't happy with it. The serial > drain closure is the last thing that get's executed as part of > reference processing - when process_phaseJNI invokes the > complete_gc.do_void() method. In the drain closure either serial or > parallel I think we want to go through the termination protocol. We > just don't want to interact with the terminator in the serial case. > There's a bunch of guarantees and checks in the termination protocol > and we should still go through them - even when serial. > >> >> Again, I'm not sure about this, but if the above is correct we will >> be left with only two states. The parallel and the serial. In that >> case I think it would make sense to remove the do_stealing and >> do_termination arguments for do_marking_step() and just pass in the >> is_serial argument. Internally do_marking_step() could set up two >> local variable to track stealing and termination. That might be good >> if we see the need in the future to split these up again. > > I think we can get rid of the do_stealing parameter - it's always the > negation of the is_serial parameter and I like the idea of making it a > local. How about that? For example > > void CMTask::do_marking_step(double ms, bool do_termination, bool > is_serial) { > // It does not make sense to allow stealing when called serially. > bool do_stealing = !is_serial; > > Thanks, > > JohnC From john.cuthbertson at oracle.com Wed Mar 13 21:34:56 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 13 Mar 2013 14:34:56 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <5140E936.1020903@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> <5140BE05.50206@oracle.com> <5140E936.1020903@oracle.com> Message-ID: <5140F100.30908@oracle.com> Hi Bengt, Thanks. Enjoy the long weekend! JohnC On 3/13/2013 2:01 PM, Bengt Rutisson wrote: > > Hi John, > > Thanks for explaining a bit about the serial case where we still need > to go through termination protocol. > > As you know I'll be on vacation the next two days, so I just wanted to > let you know that with the changes that you outline below (the fix to > CMRemarkTask and removing the do_stealing argument) I'm fine with this > change. Feel free to push this if you get another review. > > Thanks, > Bengt > > On 3/13/13 6:57 PM, John Cuthbertson wrote: >> Hi Bengt, >> >> Thanks for looking at the change again. Replies inline.... >> >> On 3/13/2013 3:22 AM, Bengt Rutisson wrote: >>> >>> >>> Hi John, >>> >>> I'm not too familiar with the do_marking_step() code, so I'm trying >>> to get to know it while I'm looking at your webrev. So, maybe I'm >>> completely off here, but I think there are a couple of strange things. >>> >>> After your change do_marking_step() takes three bools: do_stealing, >>> do_termination and is_serial. >>> >>> This means that we have 8 possible states if we combine all value of >>> these bools. I went through all calls to do_marking_step() and it >>> seems like we make use of 4 of those states: >>> >>> >>> G1CMKeepAliveAndDrainClosure::do_oop_work() >>> do_marking_step(false, false, true) (1) >>> >>> CMConcurrentMarkingTask::work() >>> do_marking_step(true, true, false) (2) >>> >>> CMRemarkTask::work() >>> do_marking_step(true, true, false) (2) >>> do_marking_step(true, true, true) (3) >>> >>> G1CMDrainMarkingStackClosure::do_void() >>> do_marking_step(false, true, true) (4) >>> do_marking_step(true, true, false) (2) >>> >> >> Yeah. Well... >> >>> >>> I numbered the states (1) - (4). Here are all states and I marked >>> which ones we use: >>> >>> stealing, termination, serial (3) >>> stealing, !termination, serial >>> stealing, !termination, !serial >>> stealing, termination, !serial (2) parallel >>> !stealing, termination, serial (4) >>> !stealing, !termination, serial (1) serial >>> !stealing, !termination, !serial >>> !stealing, termination, !serial >>> >>> >>> I think state (2) makes sense as the parallel case. We do stealing >>> and termination and we are not serial. State (1) also makes sense. >>> It is clearly the serial case. No stealing or termination. Just serial. >>> >>> Now, case (3) looks odd to me. We say we are serial but we want to >>> do stealing and termination. This case comes from CMRemarkTask. It >>> takes a is_serial argument in its constructor. We get to case (3) >>> from ConcurrentMark::checkpointRootsFinalWork(), where we do: >>> >>> if (G1CollectedHeap::use_parallel_gc_threads()) { >>> ... >>> } else { >>> ... >>> CMRemarkTask remarkTask(this, active_workers, true /* is_serial*/); >>> } >>> >>> To me this looks like it should lead to the pure serial case (1) >>> instead of (3). Do you agree? In that case I think >>> CMRemarkTask::work() needs to be changed to do: >>> >>> task->do_marking_step(1000000000.0 /* something very large */, >>> !_is_serial /* do_stealing */, >>> !_is_serial /* do_termination */, >>> _is_serial); >>> >> >> You're right here. The serial remark case should not enable stealing. >> It doesn't make sense. Done! >> >>> >>> The other case that sticks out is (4). We don't want to do stealing, >>> but we want to do termination even though we are serial. This comes >>> from how we set up the g1_drain_mark_stack in >>> ConcurrentMark::weakRefsWork(). We pass that along to the reference >>> processing, which I think is serial (wasn't that the original >>> problem? :) ). We also pass the g1_keep_alive which is set up to be >>> in state (1). So, I wonder if it is correct that the >>> g1_drain_mark_stack is in state (4). If you agree that we should be >>> using the pure serial case here too, I think we need to change >>> G1CMDrainMarkingStackClosure::do_void() to be: >>> >>> _task->do_marking_step(1000000000.0 /* something very large */, >>> !_is_serial /* do_stealing */, >>> !_is_serial /* do_termination */, >>> _is_serial /* is_serial */); >>> >>> >> >> That is what we had before and I wasn't happy with it. The serial >> drain closure is the last thing that get's executed as part of >> reference processing - when process_phaseJNI invokes the >> complete_gc.do_void() method. In the drain closure either serial or >> parallel I think we want to go through the termination protocol. We >> just don't want to interact with the terminator in the serial case. >> There's a bunch of guarantees and checks in the termination protocol >> and we should still go through them - even when serial. >> >>> >>> Again, I'm not sure about this, but if the above is correct we will >>> be left with only two states. The parallel and the serial. In that >>> case I think it would make sense to remove the do_stealing and >>> do_termination arguments for do_marking_step() and just pass in the >>> is_serial argument. Internally do_marking_step() could set up two >>> local variable to track stealing and termination. That might be good >>> if we see the need in the future to split these up again. >> >> I think we can get rid of the do_stealing parameter - it's always the >> negation of the is_serial parameter and I like the idea of making it >> a local. How about that? For example >> >> void CMTask::do_marking_step(double ms, bool do_termination, bool >> is_serial) { >> // It does not make sense to allow stealing when called serially. >> bool do_stealing = !is_serial; >> >> Thanks, >> >> JohnC > From erik.helin at oracle.com Wed Mar 13 21:48:52 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 13 Mar 2013 22:48:52 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <98626133-0e7f-4854-80f1-be415b711eb3@default> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> <98626133-0e7f-4854-80f1-be415b711eb3@default> Message-ID: <5140F444.20808@oracle.com> All, based on a discussion with Bengt and Christian, we decided to move the JmapLauncher into the existing testlibrary since it all tests are likely to benefit from it, not only GC tests. Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8009408/webrev.03/ Thanks, Erik On 03/12/2013 01:14 PM, Christian T?rnqvist wrote: > Hi Erik, > > The change looks good :) > > Thanks, > Christian > > -----Original Message----- > From: Erik Helin > Sent: den 11 mars 2013 16:26 > To: Staffan Larsen > Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian T?rnqvist > Subject: Re: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" > > All, > > I've updated the change quite a bit based on feedback from Bengt and Christian. > > The class JmapLauncher has moved to the newly created gc testlibrary. > This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to contain utilities that can be used by all the gc jtreg tests. If there are code that is of interest for additional tests, then code can be easily be moved from the gc testlibrary to the general testlibrary. > > I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of this new gc testlibrary. > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ > > Thanks, > Erik > > On 03/08/2013 01:34 PM, Staffan Larsen wrote: >> Looks good to me. >> >> /Staffan >> >> On 8 mar 2013, at 13:36, Erik Helin wrote: >> >>> Bengt and Staffan, >>> >>> thanks for he feedback! >>> >>> I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. >>> >>> I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? >>> >>> Please see new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >>> >>> Thanks, >>> Erik >>> >>> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>>> >>>> Erik and Staffan, >>>> >>>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>>> that returns "-d64" if necessary. You can't use this as is since you >>>> need to get "J-d64" but I think we should do something to make your >>>> solution more general. >>>> >>>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>>> or adding a separate method that returns "JDK-tools formatted" args. >>>> It seems a bit too limited to fix this only for your particular >>>> test. Would be nice to get it in to the testlibrary somehow. >>>> >>>> Bengt >>>> >>>> >>>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>>> Looks good. I wish we could abstract this away so that not every >>>>> test needs to do this work. >>>>> >>>>> /Staffan (mobile) >>>>> >>>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>>> arch) when running jmap in the test >>>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>>> >>>>>> Thanks, >>>>>> Erik >>>> >>> >> > From jon.masamitsu at oracle.com Thu Mar 14 02:23:37 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 14 Mar 2013 02:23:37 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Message-ID: <20130314022342.3903C4811F@hg.openjdk.java.net> Changeset: 82657b6a8cc0 Author: jmasa Date: 2013-03-12 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/82657b6a8cc0 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp From jon.masamitsu at oracle.com Thu Mar 14 03:53:48 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 13 Mar 2013 20:53:48 -0700 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> Message-ID: <514149CC.6000003@oracle.com> Ramki, I've replied to your coding comments below. All, I've update the webrev for all the changes so far. http://cr.openjdk.java.net/~jmasa/8008508/webrev.02/ I've also added two helper functions for compute_new_size() so that code could be shared as appropriate. Just the refactoring changes are in this webrev. http://cr.openjdk.java.net/~jmasa/8008508/webrev.02.1/ Thanks. Jon On 3/2/2013 12:42 AM, Srinivas Ramakrishna wrote: > Hi Jon -- > > I'll give a couple of code-level comments, but there's a high-level > comment at the end, which > might be worth pondering over. > > On Tue, Feb 26, 2013 at 3:47 PM, Jon Masamitsu wrote: >> I've updated the webrev for review comments (thanks, JohnCu) >> >> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ >> > concurrent MarkSweepGeneration.cpp: > > 949 // compute expansion delta needed for reaching desired free percentage > 950 if (free_percentage < desired_free_percentage) { > 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - > desired_free_percentage)); > 952 assert(desired_capacity >= capacity(), "invalid expansion size"); > 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), > MinHeapDeltaBytes); > > 954 if (expand_bytes > 0) { > > The if test at 954 (in your changed code) will always be true because > MinHeapDeltaBytes > 0 > and we are taking the max at line 953. Ok. MinHeapDeltaBytes is a product flag so it could be set to 0 but other collectors ignore that possibility so I'll take out the test. > On reading your shrinking code further below at lines 989-994, it > struck me that there's a small > existing bug in the shrink/expand code here. It's probably more of a > factor in the shrink code though > because we can live with more free space than we'd ideally want, but > not less than we ideally want, > and we certainly do not want to chatter around the desired free > percentage (hence the delta). > > Your shrinking arm looks like this:- > > 989 } else { > 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - > desired_free_percentage)); > 991 assert(desired_capacity <= capacity(), "invalid expansion size"); > 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, > MinHeapDeltaBytes); > 993 shrink_free_list_by(shrink_bytes); > 994 } > > I'd modify it to:- > > 989 } else { > 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - > desired_free_percentage)); > 991 assert(desired_capacity <= capacity(), "invalid expansion size"); > size_t shrink_bytes = capacity() - desired_capacity; > // Don't shrink unless the delta is greater than the > minimum shrink we want > 992 if (shrink_bytes >= MinHeapDeltaBytes) { > 993 shrink_free_list_by(shrink_bytes); > } > 994 } I changed the code as you suggested. Thanks for catching this. > Note the asymmetry between expansion and shrinking, where we expand by > the min if we feel we are below the desired free, but we don't shrink > even if we are above desired free unless the gap exceeds the min > delta. Seems right. > This seems to be the correct policy. (Of course none of that is moot > until shrink_free_list_by() starts doing shrinking, but probably best > to fix the policy now, so that it doesn't cause chatter later. > > concurrentMarkSweepGeneration.hpp: > > 1298 virtual void compute_new_size(); > 1299 void compute_new_size_free_list(); > > I think it would be good to add a 1-line doc comment for each of the > above methods. Added // Resize the generation after a compacting GC. The // generation can be treated as a contiguous space // after the compaction. virtual void compute_new_size(); // Resize the generation after a non-compacting // collection. void compute_new_size_free_list(); > vmStructs.cpp: > > I think you also have to adjust the fields _capacity_at_prologue and > _used_at_prologue into the superclass. I'd also move the decls up to > CardGeneration, since that's how the original code is laid out. Done > Finally, a high level comment. While I see the reason for these > mechanics, I worry a little bit > about the somewhat schizophrenic expansion/shrinkage policy, as it > swings between one policy > used when we are presumably doing well and keeping up with the application's > allocation/promotion rates and not running into concurrent mode > failure, but then suddenly switching > to a completely different expansion/shrinking policy when we do a > compaction (presumably because > we had a concurrent mode failure). I'd much rather have divorced the > two, by using a more uniform > policy specifically for CMS, perhaps predicated by whether this was > happening after a > compaction or not, but keeping it separate from the policy that might > be used for stop-world > kind of collectors (hence TenuredGeneraion). > > I'd appreciate it if you could give some thought to this final high > level comment regarding the > general policy approach taken here. (Also it is somewhat troubling to > push policy so high up > into the class hierarchy, so that every subclass must live with it; > I'd much rather the policy > were separated from the mechanics of what would be done when an > expansion or shrinkage > was needed.) > > -- ramki From thomas.schatzl at oracle.com Thu Mar 14 08:28:57 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Mar 2013 09:28:57 +0100 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM Message-ID: <1363249737.2580.6.camel@cirrus> Hi all, please have a look at the following change which tries to make heap size argument processing more intuitive. Problem as stated in the CR is that -XX:MaxHeapSize and -XX:InitialHeapSize are not communicating enough, so that the resulting behavior is not intiutive. The CR lists the different issues, grouping them in three categories: 1) -XX:MaxHeapSize=4m -XX:InitialHeapSize=8m -> Runs with a heap of 8M -XX:MaxHeapSize=4m -XX:InitialHeapSize=4m -> Will not start (Incompatible minimum and initial heap sizes specified) -XX:MaxHeapSize=8m -XX:InitialHeapSize=4m -> Will not start (Incompatible minimum and initial heap sizes specified) The problem here was that after argument processing there was no checking whether these two arguments contradicted each other. Additionally there was some code that automatically increased maxheapsize according to InitialHeapSize. The other two situations occurred because setting of InitialHeapSize did not set the internal minimum heap size (what the alternative, -Xms, did). So the collector policy used a default value of NewSize + OldSize for MaxHeapSize, which may be larger than the given InitialHeapSize values (2). 2) -XX:MaxHeapSize=4m -> Runs with a heap of 5M -XX:MaxHeapSize=3m -> Runs with a heap of 4M -XX:MaxHeapSize=2m -> Runs with a heap of 3M These situations occured for the generational collectors because the collector policy overrode maxheapsize with the sum of newsize and oldsize. If the default values of the latter were larger than the specified MaxHeapSize, it adapted MaxHeapSize to be NewSize + OldSize. -XX:InitialHeapSize=6m -> Will not start (Incompatible minimum and initial heap sizes specified) -XX:InitialHeapSize=7m -> Runs with a heap of 8.2M -XX:InitialHeapSize=8m -> Runs with a heap of 8.875M Only the first one is a bug. This is due to -XX:InitialHeapSize not setting the internal minimum heap size. I.e. same as for the cases in 1). Note that with -Xms (which is the equivalent switch) the VM started up. The second two are no bugs imo as the user did not mention a bound for the maximum heap size in the arguments, so it would be free to choose anything >= InitialHeapSize. Webrev: http://cr.openjdk.java.net/~tschatzl/8006088/webrev/ The problem with the VM starting up when InitialHeapSize > MaxHeapSize is fixed in the first hunk of collectorPolicy.cpp where the respective sanity check has been added. The change for the "incompatible minimum and initial heap size is located in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the same as -Xms and -XX:MaxHeapSize the same as -Xmx. The latter for consistency (using the same code path for -Xmx and -XX:MaxHeapSize), as at the moment it does not set any internal variables. The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize has been set on the command line, New- and OldSize are shrunk to fit. JIRA: https://jbs.oracle.com/bugs/browse/JDK-8006088 CR: http://bugs.sun.com/view_bug.do?bug_id=8006088 Testing: JPRT, manual testing of above test cases with all collectors with "java -version". Thanks, Thomas From thomas.schatzl at oracle.com Thu Mar 14 08:40:19 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Mar 2013 09:40:19 +0100 Subject: RFR (XS): 6733980 par compact - TraceGen1Time always shows 0.0000 seconds In-Reply-To: <5140CA20.4040502@oracle.com> References: <1363194155.2547.0.camel@cirrus> <5140CA20.4040502@oracle.com> Message-ID: <1363250419.2580.7.camel@cirrus> Hi Jon, On Wed, 2013-03-13 at 11:49 -0700, Jon Masamitsu wrote: > Looks good. Could you please commit the patchset at http://cr.openjdk.java.net/~tschatzl/6733980/6733980.patch ? Thanks, Thomas From mikael.gerdin at oracle.com Thu Mar 14 09:59:52 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 14 Mar 2013 10:59:52 +0100 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <513E2370.3030704@oracle.com> References: <513855CC.5030009@oracle.com> <5138FF3A.6070902@oracle.com> <513DADEE.4040302@oracle.com> <513E2370.3030704@oracle.com> Message-ID: <51419F98.3000007@oracle.com> On 2013-03-11 19:33, Jon Masamitsu wrote: > Mikael, > > This change looks good. I looked over your replies > and am OK with them. At some point we may need to > limit the space in the "last" Virtualspace so that the total > reserved is at MaxMetaspaceSize, but that is a > different change. > > Thanks. Thanks for the review Jon. I agree with you that we should revisit this at some point. I need another review on this, any takers? /Mikael > > Jon > > > On 03/11/13 03:11, Mikael Gerdin wrote: >> Jon, >> >> On 2013-03-07 21:57, Jon Masamitsu wrote: >>> >>> >>> On 03/07/13 00:54, Mikael Gerdin wrote: >>>> Hi >>>> >>>> >>>> When deciding when to reserve more metaspace memory we erroneously >>>> looked only at the "capacity" of the metaspace insted of the reserved >>>> space (which is what we ask this function when expanding). >>> >>> Using MetaspaceAux::reserved_in_bytes() means that we >>> could return false here >>> >>> 1105 if (!FLAG_IS_DEFAULT(MaxMetaspaceSize)&& >>> 1106 MetaspaceAux::reserved_in_bytes()>= MaxMetaspaceSize) { >>> 1107 return false; >>> 1108 } >>> >>> when most of the space reserved in one or two VirtualSpace's is unused. >>> With the current value of parameters, that could almost be 512kb. >> >> Yes. >> >> I guess the question is: >> Should MaxMetaspaceSize limit the amount of virtual address space >> reserved for metaspaces or should it limit the amount of committed pages? >> >> To be consistent with how the Java heap is handled my opinion is that >> we should limit the amount of reserved memory. >> >> I any case the current version is incorrect since >> MetaspaceGC::should_expand was queried to determine if we should >> reserve more virtual address space or not and the size check was >> against the amount of committed memory. >> >> /Mikael >> >>> >>> Jon >>> >>>> >>>> Additionally, we didn't check MaxMetaspaceSize against the sum of >>>> reserved(Class) + reserved(NonClass) which caused us to use more than >>>> MaxMetaspaceSize even when it was set. >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >>>> (not yet available at the time of writing this mail) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >>>> >>>> Testing: >>>> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >>>> path. From mikael.gerdin at oracle.com Thu Mar 14 10:17:37 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 14 Mar 2013 11:17:37 +0100 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <1363249737.2580.6.camel@cirrus> References: <1363249737.2580.6.camel@cirrus> Message-ID: <5141A3C1.9060500@oracle.com> Thomas, On 2013-03-14 09:28, Thomas Schatzl wrote: > > Hi all, > > please have a look at the following change which tries to make heap > size argument processing more intuitive. > > Problem as stated in the CR is that -XX:MaxHeapSize and > -XX:InitialHeapSize are not communicating enough, so that the resulting > behavior is not intiutive. > > The CR lists the different issues, grouping them in three categories: > > 1) > > -XX:MaxHeapSize=4m -XX:InitialHeapSize=8m -> Runs with a heap of 8M > -XX:MaxHeapSize=4m -XX:InitialHeapSize=4m -> Will not start > (Incompatible minimum and initial heap sizes specified) > -XX:MaxHeapSize=8m -XX:InitialHeapSize=4m -> Will not start > (Incompatible minimum and initial heap sizes specified) > > The problem here was that after argument processing there was no > checking whether these two arguments contradicted each other. > Additionally there was some code that automatically increased > maxheapsize according to InitialHeapSize. The other two situations > occurred because setting of InitialHeapSize did not set the > internal minimum heap size (what the alternative, -Xms, did). So > the collector policy used a default value of NewSize + OldSize for > MaxHeapSize, which may be larger than the given InitialHeapSize > values (2). > > 2) > -XX:MaxHeapSize=4m -> Runs with a heap of 5M > -XX:MaxHeapSize=3m -> Runs with a heap of 4M > -XX:MaxHeapSize=2m -> Runs with a heap of 3M > > These situations occured for the generational collectors because the > collector policy overrode maxheapsize with the sum of newsize and > oldsize. If the default values of the latter were larger than the > specified MaxHeapSize, it adapted MaxHeapSize to be NewSize + OldSize. > > -XX:InitialHeapSize=6m -> Will not start (Incompatible minimum and > initial heap sizes specified) > -XX:InitialHeapSize=7m -> Runs with a heap of 8.2M > -XX:InitialHeapSize=8m -> Runs with a heap of 8.875M > > Only the first one is a bug. This is due to -XX:InitialHeapSize not > setting the internal minimum heap size. I.e. same as for the cases in > 1). Note that with -Xms (which is the equivalent switch) the VM > started up. > > The second two are no bugs imo as the user did not mention a bound for > the maximum heap size in the arguments, so it would be free to choose > anything >= InitialHeapSize. > > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8006088/webrev/ > > The problem with the VM starting up when InitialHeapSize > MaxHeapSize > is fixed in the first hunk of collectorPolicy.cpp where the respective > sanity check has been added. > > The change for the "incompatible minimum and initial heap size is located > in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the > same as -Xms and -XX:MaxHeapSize the same as -Xmx. > > The latter for consistency (using the same code path for -Xmx and > -XX:MaxHeapSize), as at the moment it does not set any internal variables. > > The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp > where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize > has been set on the command line, New- and OldSize are shrunk to fit. The code looks like it does what you describe :) Since the arguments parsing code is kind of hard to follow IMO and seemingly hard to get right it might be a good idea to write a regression test for this. Just writing a short jtreg test to launch vms with these arg combinations that you described above and verify that we get the expected outcome should not be too much code with the ProcessTools test library. /Mikael > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-8006088 > > CR: > http://bugs.sun.com/view_bug.do?bug_id=8006088 > > Testing: > JPRT, manual testing of above test cases with all collectors with > "java -version". > > Thanks, > Thomas > > > > From yunda.mly at taobao.com Thu Mar 14 10:59:51 2013 From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=) Date: Thu, 14 Mar 2013 10:59:51 +0000 Subject: Why the type of GCId in gcTrace.hpp is uint? Message-ID: Hi all, I notice that in gcTrace.hpp the type of GCId is unit, but in trace.xml the type is ULONG. Could someone tell me if there?s a special reason, or it?s just a mistake? Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???(??????)?????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Mar 14 13:47:15 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Thu, 14 Mar 2013 13:47:15 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Message-ID: <20130314134719.8EFC048135@hg.openjdk.java.net> Changeset: 79af1312fc2c Author: mgerdin Date: 2013-03-14 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/79af1312fc2c 8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Summary: Call purge() on CLDG after sweep(), reorder purge() call in GenCollectedHeap Reviewed-by: jmasa, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp From mikael.gerdin at oracle.com Thu Mar 14 14:38:14 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 14 Mar 2013 15:38:14 +0100 Subject: RFR: 8009763 Add WB test for String.intern() In-Reply-To: <514051A2.4090800@oracle.com> References: <513ED867.2070902@oracle.com> <513F27FF.5080607@oracle.com> <514051A2.4090800@oracle.com> Message-ID: <5141E0D6.6000800@oracle.com> Lenoid, On 2013-03-13 11:14, Leonid Mesnik wrote: > Hi > > werbrev was updated (thank you for this) > http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.1/ > Also, I don't know why you have "StringTabe::" inside these calls: unsigned int hash = StringTable::hash_string(name, len); unsigned int index = StringTable::the_table()->hash_to_index(hash); return StringTable::the_table()->lookup(index, name, len, hash); Since you are in an instance method in StringTable you also shouldn't get the_table() singleton, but rather use the current instance. I think your new lookup() function could be static just as the other public lookup() function. Another idea is to perhaps make these two lookup:s share the same implementation: oop StringTable::lookup(Symbol* symbol) { ResourceMark rm; int length; jchar* chars = symbol->as_unicode(length); return lookup(chars, length); } oop StringTable::lookup(const jchar* chars, int length) { unsigned int hashValue = hash_string(chars, length); int index = the_table()->hash_to_index(hashValue); return the_table()->lookup(index, chars, length, hashValue); } /Mikael > > JPRT passed with -rtest '*-*-*-runtime/interned' > > Leonid > On 03/12/2013 05:05 PM, Mikael Gerdin wrote: >> Hi Leonid, >> >> On 2013-03-12 08:25, Leonid Mesnik wrote: >>> Hi >>> I've added a small test which: >>> 1) creates java string and intern it >>> 2) verify that it presents in StringTable >>> 3) clear reference and call fullGC >>> 4) verify that there is no such string in StringTable >>> >>> Here is webrev: >>> http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.0/ >> >> Overall this looks reasonable. >> >> I have some comments though: >> WB_IsInStringTable is defined to return a jboolean (Ljava/lang/String;)Z >> but the actual function is defined to return an jint. This will >> probably work but you should fix this to make it consistent. >> >> The function WB_fullGC should have a capital F to be consistent with >> the naming of the other WB_* functions. >> >>> >>> Tested locally and by JPRT >>> >> did you run jprt with -retest '*-*-*-runtime/interned' as well? >> >> /Mikael > > From jesper.wilhelmsson at oracle.com Thu Mar 14 15:29:37 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 14 Mar 2013 16:29:37 +0100 Subject: Why the type of GCId in gcTrace.hpp is uint? In-Reply-To: References: Message-ID: <5141ECE1.7000104@oracle.com> Hi Yunda, Thanks for reporting this! It is a bug indeed. I filed CR 8010090 and will fix it asap. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090 Thanks, /Jesper On 14/3/13 11:59 AM, ??(Yunda) wrote: > Hi all, > > I notice that in gcTrace.hpp > > the type of GCId is unit, but in trace.xml > > the type is ULONG. Could someone tell me if there?s a special reason, or it?s > just a mistake? > > Regards, > > Yunda > > > -------------------------------------------------------------------------------- > > This email (including any attachments) is confidential and may be legally > privileged. If you received this email in error, please delete it immediately > and do not copy it or use it for any purpose or disclose its contents to any > other person. Thank you. > > ???(??????)?????????????????????????????? > ???????????????????????????????????????? From john.cuthbertson at oracle.com Thu Mar 14 17:19:14 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 14 Mar 2013 10:19:14 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <5140E936.1020903@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> <5140BE05.50206@oracle.com> <5140E936.1020903@oracle.com> Message-ID: <51420692.10802@oracle.com> Hi Everyone, Here's the final webrev based upon Bengt's comments: http://cr.openjdk.java.net/~johnc/8009536/webrev.2/ I think I'm all set after reviews from Bengt and Thomas - I just wanted to send out the final version of the webrev in case anyone else has other comments. Thanks, JohnC On 3/13/2013 2:01 PM, Bengt Rutisson wrote: > > Hi John, > > Thanks for explaining a bit about the serial case where we still need > to go through termination protocol. > > As you know I'll be on vacation the next two days, so I just wanted to > let you know that with the changes that you outline below (the fix to > CMRemarkTask and removing the do_stealing argument) I'm fine with this > change. Feel free to push this if you get another review. > > Thanks, > Bengt > > On 3/13/13 6:57 PM, John Cuthbertson wrote: >> Hi Bengt, >> >> Thanks for looking at the change again. Replies inline.... >> >> On 3/13/2013 3:22 AM, Bengt Rutisson wrote: >>> >>> >>> Hi John, >>> >>> I'm not too familiar with the do_marking_step() code, so I'm trying >>> to get to know it while I'm looking at your webrev. So, maybe I'm >>> completely off here, but I think there are a couple of strange things. >>> >>> After your change do_marking_step() takes three bools: do_stealing, >>> do_termination and is_serial. >>> >>> This means that we have 8 possible states if we combine all value of >>> these bools. I went through all calls to do_marking_step() and it >>> seems like we make use of 4 of those states: >>> >>> >>> G1CMKeepAliveAndDrainClosure::do_oop_work() >>> do_marking_step(false, false, true) (1) >>> >>> CMConcurrentMarkingTask::work() >>> do_marking_step(true, true, false) (2) >>> >>> CMRemarkTask::work() >>> do_marking_step(true, true, false) (2) >>> do_marking_step(true, true, true) (3) >>> >>> G1CMDrainMarkingStackClosure::do_void() >>> do_marking_step(false, true, true) (4) >>> do_marking_step(true, true, false) (2) >>> >> >> Yeah. Well... >> >>> >>> I numbered the states (1) - (4). Here are all states and I marked >>> which ones we use: >>> >>> stealing, termination, serial (3) >>> stealing, !termination, serial >>> stealing, !termination, !serial >>> stealing, termination, !serial (2) parallel >>> !stealing, termination, serial (4) >>> !stealing, !termination, serial (1) serial >>> !stealing, !termination, !serial >>> !stealing, termination, !serial >>> >>> >>> I think state (2) makes sense as the parallel case. We do stealing >>> and termination and we are not serial. State (1) also makes sense. >>> It is clearly the serial case. No stealing or termination. Just serial. >>> >>> Now, case (3) looks odd to me. We say we are serial but we want to >>> do stealing and termination. This case comes from CMRemarkTask. It >>> takes a is_serial argument in its constructor. We get to case (3) >>> from ConcurrentMark::checkpointRootsFinalWork(), where we do: >>> >>> if (G1CollectedHeap::use_parallel_gc_threads()) { >>> ... >>> } else { >>> ... >>> CMRemarkTask remarkTask(this, active_workers, true /* is_serial*/); >>> } >>> >>> To me this looks like it should lead to the pure serial case (1) >>> instead of (3). Do you agree? In that case I think >>> CMRemarkTask::work() needs to be changed to do: >>> >>> task->do_marking_step(1000000000.0 /* something very large */, >>> !_is_serial /* do_stealing */, >>> !_is_serial /* do_termination */, >>> _is_serial); >>> >> >> You're right here. The serial remark case should not enable stealing. >> It doesn't make sense. Done! >> >>> >>> The other case that sticks out is (4). We don't want to do stealing, >>> but we want to do termination even though we are serial. This comes >>> from how we set up the g1_drain_mark_stack in >>> ConcurrentMark::weakRefsWork(). We pass that along to the reference >>> processing, which I think is serial (wasn't that the original >>> problem? :) ). We also pass the g1_keep_alive which is set up to be >>> in state (1). So, I wonder if it is correct that the >>> g1_drain_mark_stack is in state (4). If you agree that we should be >>> using the pure serial case here too, I think we need to change >>> G1CMDrainMarkingStackClosure::do_void() to be: >>> >>> _task->do_marking_step(1000000000.0 /* something very large */, >>> !_is_serial /* do_stealing */, >>> !_is_serial /* do_termination */, >>> _is_serial /* is_serial */); >>> >>> >> >> That is what we had before and I wasn't happy with it. The serial >> drain closure is the last thing that get's executed as part of >> reference processing - when process_phaseJNI invokes the >> complete_gc.do_void() method. In the drain closure either serial or >> parallel I think we want to go through the termination protocol. We >> just don't want to interact with the terminator in the serial case. >> There's a bunch of guarantees and checks in the termination protocol >> and we should still go through them - even when serial. >> >>> >>> Again, I'm not sure about this, but if the above is correct we will >>> be left with only two states. The parallel and the serial. In that >>> case I think it would make sense to remove the do_stealing and >>> do_termination arguments for do_marking_step() and just pass in the >>> is_serial argument. Internally do_marking_step() could set up two >>> local variable to track stealing and termination. That might be good >>> if we see the need in the future to split these up again. >> >> I think we can get rid of the do_stealing parameter - it's always the >> negation of the is_serial parameter and I like the idea of making it >> a local. How about that? For example >> >> void CMTask::do_marking_step(double ms, bool do_termination, bool >> is_serial) { >> // It does not make sense to allow stealing when called serially. >> bool do_stealing = !is_serial; >> >> Thanks, >> >> JohnC > From john.cuthbertson at oracle.com Thu Mar 14 17:23:05 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 14 Mar 2013 10:23:05 -0700 Subject: RFR(S): G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 In-Reply-To: <5140DFB1.2000202@oracle.com> References: <513FC3F1.8090609@oracle.com> <5140C534.30409@oracle.com> <5140D0FE.30209@oracle.com> <5140DFB1.2000202@oracle.com> Message-ID: <51420779.3040409@oracle.com> Hi Everyone, The new version of the webrev can be found at: http://cr.openjdk.java.net/~johnc/8009940/webrev.1/ and Jon's comments in isolation can be found at: http://cr.openjdk.java.net/~johnc/8009940/webrev.1.jons-review-comments/ Thanks, JohnC On 3/13/2013 1:21 PM, Jon Masamitsu wrote: > > On 3/13/2013 12:18 PM, John Cuthbertson wrote: >> Hi Jon, >> >> Thank you for looking at the code changes. >> >> On 3/13/2013 11:28 AM, Jon Masamitsu wrote: >>> John, >>> >>> No comments affecting the correctness of the >>> change so looks good. >>> >>> >>> 979 // If we're during the concurrent phase of marking, reset the >>> marking >>> >>> during -> doing ? >> >> OK. Whatever communicates that the overflow is seen while the >> concurrent phase is active. > > I would then use > > "If we're executing the concurrent phase ..." > >> >>> >>> From concurrentMark.hpp >>> >>> // It should be called to indicate which phase we're in (concurrent >>> // mark or remark) and how many threads are currently active. >>> void set_phase(uint active_tasks, bool concurrent); >>> >>> Is there a better name that we can give to set_phase() so >>> that we know if should only be called once per phase (if that >>> is in fact true?)? Maybe set_phase_on_entry() or >>> initialize_phase() or set_phase_start(). >>> >>> Also set_phase() seems to have much to do with the >>> concurrency of the phase so maybe set_concurrency(), >>> set_concurrency_on_entr(), initialize_concurrency(), >>> set_concurrency_start(). >> >> Actually I like set_concurrency_and_phase(...). > > OK. > >> >>> 2403 // Not strictly necessary but... >>> 2404 // >>> 2405 // We need to reset the number of workers in the parallel >>> 2406 // task terminator, before each proxy task execution, so >>> 2407 // that the termination protocol in CMTask::do_marking_step() >>> 2408 // knows how many workers to wait for. >>> 2409 _cm->terminator()->reset_for_reuse(_active_workers); >>> >>> If you're reusing a ParallelTaskTerminator, I think it really is best >>> to not assume that it can be reused. >> >> OK. Kind of prompts the change I'll suggest below. >> >>> >>> On 3/12/2013 5:10 PM, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers look over these changes? The >>>> webrev can be found at: >>>> http://cr.openjdk.java.net/~johnc/8009940/webrev.0/ >>>> >>>> These changes were, at Bengt's request, split out from the original >>>> webrev for 8009536. In the webrev they have been applied on top of >>>> 8009536 but they are independent. The issue has been in the G1 code >>>> for a while (since I added the reference processing code a couple >>>> of years ago) - we just never hit it. >>>> >>>> Anyway the assertion is caused by calling set_phase() - which >>>> throws the assertion failure - after resetting the marking state - >>>> which resets the value of the global finger. >>> >>> Is set_phase() actually safe to call other than the assertion that >>> fires >>> if the global finger is reset? >> >> set_phase() was actually safe to call (other than the assert). Even >> resetting the global finger is, I believe, safe. Doing so means that >> we would mark object but would no longer push them - as they are no >> longer below the finger. Objects are pushed so that they can be >> traced. Since marking is going to be restarted, the marked objects >> would be traced in the normal manner when marking reaches them. >> >> Since it's not safe to reuse a parallel task terminator (I didn't >> know that) my suggestion is: > > Here's the more complete thought. If you're going to reuse a parallel > task terminator and > it has been used before, then reset_for_reuse() needs to be called on > it. If it has not > been used before, then it's safe to use without a call to > reset_for_reuse(). If in doubt > or the use of the parallel task terminator could possibly change, > call reset_for_reuse(). > >> >> * break out the concurrency-related code from set_phase() into it's >> own routine. >> * call that routine within set_phase (now renamed >> set_concurrency_and_phase) >> * call the set_concurrency routine within the parallel reference >> processing. >> >> That should also address Bengt's concern about the inconsistency >> between the parallel task terminator and the WorkGangBarrierSyncs. >> >> Sound reasonable? > > I like it. Thanks; > > Jon > >> >> Thanks! >> >> JohnC >> > From thomas.schatzl at oracle.com Thu Mar 14 20:11:43 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Mar 2013 21:11:43 +0100 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <5140D048.6030600@oracle.com> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> Message-ID: <1363291903.2489.24.camel@cirrus> Hi, On Wed, 2013-03-13 at 12:15 -0700, Tao Mao wrote: > BTW, upon completion of this CR, please also investigate a CR with > similar problems (most likely, close as a duplicate) . > https://jbs.oracle.com/bugs/browse/JDK-6374896 It is most certainly a duplicate. > On 3/13/13 6:17 AM, Thomas Schatzl wrote: > > Hi all, > > > > please review the following change which improves ergonomic heap > > sizing. Automatic heap sizing now takes available virtual memory into > > account. > > > > The problem occurred when the user reduced the available virtual memory > > via e.g. ulimit. As ergonomics did not take virtual memory into account, > > using available physical memory only, the vm typically crashed at > > startup. > > > > This patch does not avoid all crashes due to out of virtual memory, > > because only heap sizing now takes available virtual memory into account > > now. Some GCs, and also other parts of the VM, try to reserve hundreds > > of MB at startup. > I don't quite understand what you mean here. Does it indicate that the > default value (i.e. 2) chosen for MaxVirMemFraction is a bit large? > (when it has the effect of limiting the head size, the virtual memory > would be small already.) No, the problem is that especially at smaller limits (~1-2G) other memory consumers (i.e. parts that reserve memory upfront) in the vm will take up the majority of the virtual memory space, exiting the VM. This not only includes GCs, but also other parts of the VM. As this patch does not try to limit the memory us of these other consumers the VM will still exit with out of memory at quite high ulimits, at least with the 64 bit VM. The related defaults for the 32 bit VM are much more economical in that respect. > > The main change is in Arguments::allocatable_physical_memory() (which > > has been moved from the os class) where if an additional virtual memory > > limit has been imposed on the java process, the given heap size is > > bounded by a fraction of that limit. > > It kind of violates parallelism here, for > Arguments::allocatable_physical_memory() and os::physical_memory() are > now defined in different classes while they should have the same level > of abstraction. Seems better to keep allocatable_physical_memory() > back in os due to its closeness to os. I think that they serve a different purpose, and are at a different level of abstraction. Os::physical_memory() like the new os::has_allocatable_physical_memory are basically functions that query the OS for information. Arguments::allocatable_physical_memory uses this information among other, applying a heuristic to get the "best" heap size in the current situation. It is quite simple quite now, but an easy extension could be to ask the GCs how much memory they'd try to allocate given the current conditions. I believe the os class is mostly a thin layer above OS functionality, so this does not fit. I renamed Arguments::allocatable_physical_memory() to "limit_by_allocatable_memory(julong)" too to decrease the confusion. Did that answer your question? > > That fraction is determined by a new global called MaxVirtMemFraction > > (default value: 2). > follow the style > 1946 product(uintx, MaxRAMFraction, 4, \ > 1947 "Maximum fraction (1/n) of real memory used for maximum heap " \ > 1948 "size") \ > would be reasonable to phrase the definition similarly, say, > 1961 product(uintx, MaxVirtMemFraction, 2, \ > 1962 "Maximum fraction (1/n) of virtual memory used for maximum heap size") \ > 1963 \ > > Done. > > Some discussion points: > > - maybe make MaxVirtMemFraction at least notproduct. It does not seem > > to make much sense to expose that global to the end user, does it? If > > the user is able to change MaxVirtMemFraction, he/she may as well set an > > appropriate maximum heap size with the same effect. > Makes sense. Done. > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/7112912/webrev/ > (1) you may want to rephrase the comment or delete it > 2607 // Make sure that if we have a lot of memory we cap the 32 bit > 2608 // process space. The 64bit VM version of this function is a nop. > 2609 initHeapSize = allocatable_physical_memory(initHeapSize); Deleted. > (2) I also prefer a pointer argument here. It's more readable to > recognize its intention of usage. > 187 static bool has_allocatable_memory_limit(julong& limit); Done. > > > > CR: > > http://bugs.sun.com/view_bug.do?bug_id=7112912 > > > > JIRA: > > https://jbs.oracle.com/bugs/browse/JDK-7112912 > > > > Testing: > > jprt, local testing with different ulimit values > Did you test out all(or, most) platform combinations > (solaris/bsd/linux/windows + 32/64 bit) to verify the current code can > get the right size of virtual memory? > > Tested: Linux 32/64 bit, OSX 64 bit, Solaris 32/64 bit, and Windows 32/64 bit (on 64 bit W2k8 server). On Unixes getrlimit is a basic function, so no problems here, and always returns the ulimit value (or "unlimited" if not set). For Windows, the used function is XP+ according to MSDN. The function to retrieve the total virtual memory is also already in use by other os class methods without any special guards. Manually is the better word. :) I will prepare a new webrev. Thanks, Thomas From nils.eliasson at oracle.com Thu Mar 14 20:42:40 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 14 Mar 2013 21:42:40 +0100 Subject: RFR(S): 8007701: Hotspot JFR Allocation Events Message-ID: <51423640.4000506@oracle.com> Hi all, I would like a review for this change that introduces two new Java Flight Recorder events. "AllocationInNewTLAB" is sent for the first object in a new TLAB and gives a reasonably cheap and reasonably fair object sampling. "AllocationOutsideTLAB" is sent for each object that gets allocated outside the TLABs. (The object doesn't fit or would cause too much wasted free space if the tlab was discarded.) These events use the allocation slow path in CollectedHeap which is used by default in the template interpreter and the C2 compiler. It is also used for all TLAB refills in the C1-compiler if the flag -XX:-FastTLABRefill is supplied. http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ http://bugs.sun.com/view_bug.do?bug_id=8007701 The event code for AllocationOutsideTLAB had to be put in CollectedHeap.cpp since tracing.hpp can't be included into CollectedHeap.inline.hpp. Thanks, Nils Eliasson From john.cuthbertson at oracle.com Fri Mar 15 00:31:53 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 14 Mar 2013 17:31:53 -0700 Subject: RFR(S): 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Message-ID: <51426BF9.2090802@oracle.com> Hi Everyone, Here's another one associated with overflowing the marking stack. The webrev can be found at: http://cr.openjdk.java.net/~johnc/8008301/webrev.0/ Summary: In this case the marking stack overflows during the actual remark task - when the individual marking tasks are draining the completed SATB buffers. As a result we exit the remark task (because of the overflow) with some legitimately unprocessed completed SATB buffers and trip the guarantee. The main part of the fix is between line 2575 and 2579 where I relax the guarantee to allow for the overflow. Additionally I've also added a heap verification for when we restart marking due to overflow. I added it as part of the debugging and I think it makes sense to leave it in. The change between lines 2408 and 2416 is to just skip reference processing. While testing I was running into the hang reported in 8009536 and added this to work around it. An equivalent change will be pushed as part of the changes for 8009940. Testing: The failing test case in a loop (with and without instrumentation and VerifyDuringGC) The GC test suite with a small mark stack size (2K, 4K) The Lucene tests for 8009536 to specifically test the verification after overflow. Thanks, JohnC From tao.mao at oracle.com Fri Mar 15 00:41:03 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 14 Mar 2013 17:41:03 -0700 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <5139022B.4070209@oracle.com> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> <5139022B.4070209@oracle.com> Message-ID: <51426E1F.5000304@oracle.com> The comment " 1172 // MaxHeapSize is aligned down in collectorPolicy" mislead here so I deleted it (because: in fact, in collectorPolicy.cpp, MaxHeapSize is aligned up). But the assertions still have some value. Please review the new webrev. http://cr.openjdk.java.net/~tamao/7196080/webrev.01/ Thanks. Tao On 3/7/13 1:10 PM, Jon Masamitsu wrote: > Tao, > > As per our discussion feel free to delete both > assertions. > > Jon > > On 03/07/13 08:13, Jon Masamitsu wrote: >> Tao, >> >> The original assertion seems a worthwhile one >> (i.e., the maximum heap size is >= to the >> initial heap size) to enforce. The CR says the problem >> that not everything has been page aligned. Is >> the latter not true? >> >> Jon >> >> On 03/06/13 14:33, Tao Mao wrote: >>> 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp >>> https://jbs.oracle.com/bugs/browse/JDK-7196080 >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/7196080/webrev.00/ >>> >>> changeset: >>> 1. inequality doesn't transfer here. >>> X >= align_down(X) >>> X >= I >>> altogether, cannot infer that align_down(X) >= I. Simple math! >>> So, I have removed the original assertion "max_heap >= >>> InitialHeapSize". >>> 2. It's reasonable to check an extra assertion "max_heap > = >>> OldSize", following the comment above the assertions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yunda.mly at taobao.com Fri Mar 15 02:36:25 2013 From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=) Date: Fri, 15 Mar 2013 02:36:25 +0000 Subject: Why the type of GCId in gcTrace.hpp is uint? In-Reply-To: <5141ECE1.7000104@oracle.com> References: <5141ECE1.7000104@oracle.com> Message-ID: Jesper, Thanks. I think you should consider that in trace.xml the type of compileID is INTEGER and the type of javalangthread is JAVALANGTHREAD. Since they all have similar meanings( as an ID), could they be a same type? Regards, Yunda > -----Original Message----- > From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com] > Sent: Thursday, March 14, 2013 11:30 PM > To: ??(Yunda) > Cc: hotspot-gc-dev openjdk.java.net (hotspot-gc-dev at openjdk.java.net); > serviceability-dev at openjdk.java.net > Subject: Re: Why the type of GCId in gcTrace.hpp is uint? > > Hi Yunda, > > Thanks for reporting this! It is a bug indeed. > I filed CR 8010090 and will fix it asap. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090 > > Thanks, > /Jesper > > > On 14/3/13 11:59 AM, ??(Yunda) wrote: > > Hi all, > > > > I notice that in gcTrace.hpp > > > are/vm/gc_implementation/shared/gcTrace.hpp> > > the type of GCId is unit, but in trace.xml > > > are/vm/gc_implementation/shared/gcTrace.hpp> > > the type is ULONG. Could someone tell me if there?s a special reason, > > or it?s just a mistake? > > > > Regards, > > > > Yunda > > > > > > ---------------------------------------------------------------------- > > ---------- > > > > This email (including any attachments) is confidential and may be > > legally privileged. If you received this email in error, please delete > > it immediately and do not copy it or use it for any purpose or > > disclose its contents to any other person. Thank you. > > > > ???(??????)?????????????????????? > ???????? > > ??????????????????????????????? > ????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???(??????)?????????????????????????????????????????????????????????????????????? From jon.masamitsu at oracle.com Fri Mar 15 08:10:47 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 15 Mar 2013 08:10:47 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 6733980: par compact - TraceGen1Time always shows 0.0000 seconds Message-ID: <20130315081049.61BDD48178@hg.openjdk.java.net> Changeset: 3c226052f7dc Author: tschatzl Date: 2013-03-14 09:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c226052f7dc 6733980: par compact - TraceGen1Time always shows 0.0000 seconds Summary: Use the correct collector to retrieve accumulated gen1 trace time Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp From jon.masamitsu at oracle.com Fri Mar 15 16:32:11 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 15 Mar 2013 09:32:11 -0700 Subject: RFR(S): 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure In-Reply-To: <51426BF9.2090802@oracle.com> References: <51426BF9.2090802@oracle.com> Message-ID: <51434D0B.6020607@oracle.com> Looks good. Jon On 3/14/2013 5:31 PM, John Cuthbertson wrote: > Hi Everyone, > > Here's another one associated with overflowing the marking stack. The > webrev can be found at: > > http://cr.openjdk.java.net/~johnc/8008301/webrev.0/ > > Summary: > In this case the marking stack overflows during the actual remark task > - when the individual marking tasks are draining the completed SATB > buffers. As a result we exit the remark task (because of the overflow) > with some legitimately unprocessed completed SATB buffers and trip the > guarantee. > > The main part of the fix is between line 2575 and 2579 where I relax > the guarantee to allow for the overflow. Additionally I've also added > a heap verification for when we restart marking due to overflow. I > added it as part of the debugging and I think it makes sense to leave > it in. > > The change between lines 2408 and 2416 is to just skip reference > processing. While testing I was running into the hang reported in > 8009536 and added this to work around it. An equivalent change will be > pushed as part of the changes for 8009940. > > Testing: > The failing test case in a loop (with and without instrumentation and > VerifyDuringGC) > The GC test suite with a small mark stack size (2K, 4K) > The Lucene tests for 8009536 to specifically test the verification > after overflow. > > Thanks, > > JohnC From jon.masamitsu at oracle.com Fri Mar 15 16:37:51 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 15 Mar 2013 09:37:51 -0700 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <51426E1F.5000304@oracle.com> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> <5139022B.4070209@oracle.com> <51426E1F.5000304@oracle.com> Message-ID: <51434E5F.8080709@oracle.com> Looks fine. Jon On 3/14/2013 5:41 PM, Tao Mao wrote: > The comment > > " 1172 // MaxHeapSize is aligned down in collectorPolicy" > > mislead here so I deleted it (because: in fact, in > collectorPolicy.cpp, MaxHeapSize is aligned up). But the assertions > still have some value. > > Please review the new webrev. > http://cr.openjdk.java.net/~tamao/7196080/webrev.01/ > > Thanks. > Tao > > On 3/7/13 1:10 PM, Jon Masamitsu wrote: >> Tao, >> >> As per our discussion feel free to delete both >> assertions. >> >> Jon >> >> On 03/07/13 08:13, Jon Masamitsu wrote: >>> Tao, >>> >>> The original assertion seems a worthwhile one >>> (i.e., the maximum heap size is >= to the >>> initial heap size) to enforce. The CR says the problem >>> that not everything has been page aligned. Is >>> the latter not true? >>> >>> Jon >>> >>> On 03/06/13 14:33, Tao Mao wrote: >>>> 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp >>>> https://jbs.oracle.com/bugs/browse/JDK-7196080 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~tamao/7196080/webrev.00/ >>>> >>>> changeset: >>>> 1. inequality doesn't transfer here. >>>> X >= align_down(X) >>>> X >= I >>>> altogether, cannot infer that align_down(X) >= I. Simple math! >>>> So, I have removed the original assertion "max_heap >= >>>> InitialHeapSize". >>>> 2. It's reasonable to check an extra assertion "max_heap > = >>>> OldSize", following the comment above the assertions. > From john.cuthbertson at oracle.com Fri Mar 15 18:54:38 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 15 Mar 2013 11:54:38 -0700 Subject: RFR(S): 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure In-Reply-To: <51434D0B.6020607@oracle.com> References: <51426BF9.2090802@oracle.com> <51434D0B.6020607@oracle.com> Message-ID: <51436E6E.7080409@oracle.com> Hi Jon, Thanks for the review. JohnC On 3/15/2013 9:32 AM, Jon Masamitsu wrote: > > Looks good. > > Jon > > On 3/14/2013 5:31 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Here's another one associated with overflowing the marking stack. The >> webrev can be found at: >> >> http://cr.openjdk.java.net/~johnc/8008301/webrev.0/ >> >> Summary: >> In this case the marking stack overflows during the actual remark >> task - when the individual marking tasks are draining the completed >> SATB buffers. As a result we exit the remark task (because of the >> overflow) with some legitimately unprocessed completed SATB buffers >> and trip the guarantee. >> >> The main part of the fix is between line 2575 and 2579 where I relax >> the guarantee to allow for the overflow. Additionally I've also added >> a heap verification for when we restart marking due to overflow. I >> added it as part of the debugging and I think it makes sense to leave >> it in. >> >> The change between lines 2408 and 2416 is to just skip reference >> processing. While testing I was running into the hang reported in >> 8009536 and added this to work around it. An equivalent change will >> be pushed as part of the changes for 8009940. >> >> Testing: >> The failing test case in a loop (with and without instrumentation and >> VerifyDuringGC) >> The GC test suite with a small mark stack size (2K, 4K) >> The Lucene tests for 8009536 to specifically test the verification >> after overflow. >> >> Thanks, >> >> JohnC > From erik.helin at oracle.com Sat Mar 16 10:38:48 2013 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 16 Mar 2013 11:38:48 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics Message-ID: <51444BB8.1050409@oracle.com> Hi all, this change adds an event, vm/gc/detailed/class_count_after_gc, that sends information about the number of instances of each class on the heap (as well as size and the name of the class). The event is sent after the marking phase for all old collections and an object will be counted as live if the GC think that the object is live (this is only tricky in the case of a concurrent collection). Webrev: http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 Testing: JPRT Thanks, Erik From thomas.schatzl at oracle.com Mon Mar 18 07:59:09 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 18 Mar 2013 08:59:09 +0100 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <1363291903.2489.24.camel@cirrus> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> Message-ID: <1363593549.2603.1.camel@cirrus> Hi all, here is a new webrev for this issue. Changes are: - merged code for os::has_allocatable_memory_limit of linux/bsd/solaris into a single method. - on 32 bit targets that method now tries to find the maximum allocatable virtual memory limit by performing a binary search. In this search, the method tries to find the largest allocatable block of memory, and returns this size as limit. It uses a binary search to do this. The old mechanism relied on some manually determined number (2*G - 2*LargePageSize) - fixed the description of MaxVirtMemFraction - rename Arguments::allocatable_physical_memory() to limit_by_allocatable_memory(). - the argument of os::has_allocatable_memory_limit() is now passed as address. - removed some obsolete comment Tests: JPRT, manual testing on linux 32/64 bit, BSD 64 bit, Windows 32/64 bit. Additional manual testing targeted at the maximum memory limit search on linux 32 bit. Webrev: http://cr.openjdk.java.net/~tschatzl/7112912/webrev.1/ CR: http://bugs.sun.com/view_bug.do?bug_id=7112912 JIRA: https://jbs.oracle.com/bugs/browse/JDK-7112912 Thanks, Thomas From bengt.rutisson at oracle.com Mon Mar 18 09:10:07 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 18 Mar 2013 10:10:07 +0100 Subject: RFR(S): 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure In-Reply-To: <51426BF9.2090802@oracle.com> References: <51426BF9.2090802@oracle.com> Message-ID: <5146D9EF.8070609@oracle.com> Hi John, Looks good. Bengt On 3/15/13 1:31 AM, John Cuthbertson wrote: > Hi Everyone, > > Here's another one associated with overflowing the marking stack. The > webrev can be found at: > > http://cr.openjdk.java.net/~johnc/8008301/webrev.0/ > > Summary: > In this case the marking stack overflows during the actual remark task > - when the individual marking tasks are draining the completed SATB > buffers. As a result we exit the remark task (because of the overflow) > with some legitimately unprocessed completed SATB buffers and trip the > guarantee. > > The main part of the fix is between line 2575 and 2579 where I relax > the guarantee to allow for the overflow. Additionally I've also added > a heap verification for when we restart marking due to overflow. I > added it as part of the debugging and I think it makes sense to leave > it in. > > The change between lines 2408 and 2416 is to just skip reference > processing. While testing I was running into the hang reported in > 8009536 and added this to work around it. An equivalent change will be > pushed as part of the changes for 8009940. > > Testing: > The failing test case in a loop (with and without instrumentation and > VerifyDuringGC) > The GC test suite with a small mark stack size (2K, 4K) > The Lucene tests for 8009536 to specifically test the verification > after overflow. > > Thanks, > > JohnC From bengt.rutisson at oracle.com Mon Mar 18 11:40:24 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 18 Mar 2013 12:40:24 +0100 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <51420692.10802@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> <5140BE05.50206@oracle.com> <5140E936.1020903@oracle.com> <51420692.10802@oracle.com> Message-ID: <5146FD28.7070609@oracle.com> Hi John, This looks good to me. Just like I thought ;) One nit if you feel like fixing it before you push: In a couple places you have this pattern: 2240 _task->do_marking_step(mark_step_duration_ms, 2241 false /* do_termination */, 2242 _is_serial /* is_serial */); I think the comment /* is_serial */ is superfluous now that we pass a variable named _is_serial instead of just true or false. Bengt On 3/14/13 6:19 PM, John Cuthbertson wrote: > Hi Everyone, > > Here's the final webrev based upon Bengt's comments: > > http://cr.openjdk.java.net/~johnc/8009536/webrev.2/ > > I think I'm all set after reviews from Bengt and Thomas - I just > wanted to send out the final version of the webrev in case anyone else > has other comments. > > Thanks, > > JohnC > > On 3/13/2013 2:01 PM, Bengt Rutisson wrote: >> >> Hi John, >> >> Thanks for explaining a bit about the serial case where we still need >> to go through termination protocol. >> >> As you know I'll be on vacation the next two days, so I just wanted >> to let you know that with the changes that you outline below (the fix >> to CMRemarkTask and removing the do_stealing argument) I'm fine with >> this change. Feel free to push this if you get another review. >> >> Thanks, >> Bengt >> >> On 3/13/13 6:57 PM, John Cuthbertson wrote: >>> Hi Bengt, >>> >>> Thanks for looking at the change again. Replies inline.... >>> >>> On 3/13/2013 3:22 AM, Bengt Rutisson wrote: >>>> >>>> >>>> Hi John, >>>> >>>> I'm not too familiar with the do_marking_step() code, so I'm trying >>>> to get to know it while I'm looking at your webrev. So, maybe I'm >>>> completely off here, but I think there are a couple of strange things. >>>> >>>> After your change do_marking_step() takes three bools: do_stealing, >>>> do_termination and is_serial. >>>> >>>> This means that we have 8 possible states if we combine all value >>>> of these bools. I went through all calls to do_marking_step() and >>>> it seems like we make use of 4 of those states: >>>> >>>> >>>> G1CMKeepAliveAndDrainClosure::do_oop_work() >>>> do_marking_step(false, false, true) (1) >>>> >>>> CMConcurrentMarkingTask::work() >>>> do_marking_step(true, true, false) (2) >>>> >>>> CMRemarkTask::work() >>>> do_marking_step(true, true, false) (2) >>>> do_marking_step(true, true, true) (3) >>>> >>>> G1CMDrainMarkingStackClosure::do_void() >>>> do_marking_step(false, true, true) (4) >>>> do_marking_step(true, true, false) (2) >>>> >>> >>> Yeah. Well... >>> >>>> >>>> I numbered the states (1) - (4). Here are all states and I marked >>>> which ones we use: >>>> >>>> stealing, termination, serial (3) >>>> stealing, !termination, serial >>>> stealing, !termination, !serial >>>> stealing, termination, !serial (2) parallel >>>> !stealing, termination, serial (4) >>>> !stealing, !termination, serial (1) serial >>>> !stealing, !termination, !serial >>>> !stealing, termination, !serial >>>> >>>> >>>> I think state (2) makes sense as the parallel case. We do stealing >>>> and termination and we are not serial. State (1) also makes sense. >>>> It is clearly the serial case. No stealing or termination. Just >>>> serial. >>>> >>>> Now, case (3) looks odd to me. We say we are serial but we want to >>>> do stealing and termination. This case comes from CMRemarkTask. It >>>> takes a is_serial argument in its constructor. We get to case (3) >>>> from ConcurrentMark::checkpointRootsFinalWork(), where we do: >>>> >>>> if (G1CollectedHeap::use_parallel_gc_threads()) { >>>> ... >>>> } else { >>>> ... >>>> CMRemarkTask remarkTask(this, active_workers, true /* >>>> is_serial*/); >>>> } >>>> >>>> To me this looks like it should lead to the pure serial case (1) >>>> instead of (3). Do you agree? In that case I think >>>> CMRemarkTask::work() needs to be changed to do: >>>> >>>> task->do_marking_step(1000000000.0 /* something very large */, >>>> !_is_serial /* do_stealing */, >>>> !_is_serial /* do_termination */, >>>> _is_serial); >>>> >>> >>> You're right here. The serial remark case should not enable >>> stealing. It doesn't make sense. Done! >>> >>>> >>>> The other case that sticks out is (4). We don't want to do >>>> stealing, but we want to do termination even though we are serial. >>>> This comes from how we set up the g1_drain_mark_stack in >>>> ConcurrentMark::weakRefsWork(). We pass that along to the reference >>>> processing, which I think is serial (wasn't that the original >>>> problem? :) ). We also pass the g1_keep_alive which is set up to be >>>> in state (1). So, I wonder if it is correct that the >>>> g1_drain_mark_stack is in state (4). If you agree that we should be >>>> using the pure serial case here too, I think we need to change >>>> G1CMDrainMarkingStackClosure::do_void() to be: >>>> >>>> _task->do_marking_step(1000000000.0 /* something very large */, >>>> !_is_serial /* do_stealing */, >>>> !_is_serial /* do_termination */, >>>> _is_serial /* is_serial */); >>>> >>>> >>> >>> That is what we had before and I wasn't happy with it. The serial >>> drain closure is the last thing that get's executed as part of >>> reference processing - when process_phaseJNI invokes the >>> complete_gc.do_void() method. In the drain closure either serial or >>> parallel I think we want to go through the termination protocol. We >>> just don't want to interact with the terminator in the serial case. >>> There's a bunch of guarantees and checks in the termination protocol >>> and we should still go through them - even when serial. >>> >>>> >>>> Again, I'm not sure about this, but if the above is correct we will >>>> be left with only two states. The parallel and the serial. In that >>>> case I think it would make sense to remove the do_stealing and >>>> do_termination arguments for do_marking_step() and just pass in the >>>> is_serial argument. Internally do_marking_step() could set up two >>>> local variable to track stealing and termination. That might be >>>> good if we see the need in the future to split these up again. >>> >>> I think we can get rid of the do_stealing parameter - it's always >>> the negation of the is_serial parameter and I like the idea of >>> making it a local. How about that? For example >>> >>> void CMTask::do_marking_step(double ms, bool do_termination, bool >>> is_serial) { >>> // It does not make sense to allow stealing when called serially. >>> bool do_stealing = !is_serial; >>> >>> Thanks, >>> >>> JohnC >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Mar 18 12:49:41 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 18 Mar 2013 13:49:41 +0100 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <51434E5F.8080709@oracle.com> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> <5139022B.4070209@oracle.com> <51426E1F.5000304@oracle.com> <51434E5F.8080709@oracle.com> Message-ID: <1363610981.2603.42.camel@cirrus> Hi all, On Fri, 2013-03-15 at 09:37 -0700, Jon Masamitsu wrote: > Looks fine. > > Jon > > On 3/14/2013 5:41 PM, Tao Mao wrote: > > The comment > > > > " 1172 // MaxHeapSize is aligned down in collectorPolicy" > > > > mislead here so I deleted it (because: in fact, in > > collectorPolicy.cpp, MaxHeapSize is aligned up). But the assertions > > still have some value. > > > both asserts will fail when using a small heap size, e.g. 1-3M. This is because default OldSize (and NewSize) are >=4(>=1M) respectively. (>= due to the use of ScaleForWordSize() on 64 bit) Additionally, in TwoGenerationPolicy::initialize_flags(), OldSize/NewSize and MaxHeapSize are intentionally synched, i.e. MaxHeapSize = OldSize + NewSize so that these asserts hold. My suggestion is to just remove them as these asserts seem to contradict TwoGenerationPolicy::initialize_flags(). Atm these asserts cause differences in what heap sizes the VM accepts when running with or without debug info when using cms. Sorry for being a bit late. Thomas From thomas.schatzl at oracle.com Mon Mar 18 12:53:03 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 18 Mar 2013 13:53:03 +0100 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <5141A3C1.9060500@oracle.com> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> Message-ID: <1363611183.2603.45.camel@cirrus> Hi all, On Thu, 2013-03-14 at 11:17 +0100, Mikael Gerdin wrote: > Thomas, > > On 2013-03-14 09:28, Thomas Schatzl wrote: > > > > Hi all, > > > > please have a look at the following change which tries to make heap > > size argument processing more intuitive. > > > > The second two are no bugs imo as the user did not mention a bound for > > the maximum heap size in the arguments, so it would be free to choose > > anything >= InitialHeapSize. > > > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8006088/webrev/ > > > > The problem with the VM starting up when InitialHeapSize > MaxHeapSize > > is fixed in the first hunk of collectorPolicy.cpp where the respective > > sanity check has been added. > > > > The change for the "incompatible minimum and initial heap size is located > > in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the > > same as -Xms and -XX:MaxHeapSize the same as -Xmx. > > > > The latter for consistency (using the same code path for -Xmx and > > -XX:MaxHeapSize), as at the moment it does not set any internal variables. > > > > The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp > > where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize > > has been set on the command line, New- and OldSize are shrunk to fit. > > The code looks like it does what you describe :) > > Since the arguments parsing code is kind of hard to follow IMO and > seemingly hard to get right it might be a good idea to write a > regression test for this. > > Just writing a short jtreg test to launch vms with these arg > combinations that you described above and verify that we get the > expected outcome should not be too much code with the ProcessTools test done, added jtreg tests. Webrev: http://cr.openjdk.java.net/~tschatzl/8006088/webrev.1/ Note that the code additionally removes two asserts that are imo invalid to do at this point. I.e. assert(max_heap >= InitialHeapSize, "Error");// or >= OldSize in 7196080 assert(max_heap >= NewSize, "Error"); The max_heap >= OldSize assert is problematic because its default value is 4M. So again, if you set MaxHeapSize to e.g. 1-3M, the assert will fail. The same applies to NewSize with a sufficiently small heap. There is the new sanity check collectorPolicy.cpp that checks whether MaxHeapSize >= InitialHeapSize also in product mode (i.e. conflicting command line params have been set). Additionally, NewSize and OldSize are adjusted to MaxHeapSize (or MaxHeapSize to NewSize + OldSize) later in the collector policy too. These asserts also cause different behavior with/without debug mode. Thomas From bengt.rutisson at oracle.com Mon Mar 18 13:12:36 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 18 Mar 2013 14:12:36 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <5140F444.20808@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> <98626133-0e7f-4854-80f1-be415b711eb3@default> <5140F444.20808@oracle.com> Message-ID: <514712C4.7090503@oracle.com> Hi Erik, Looks good. Bengt On 3/13/13 10:48 PM, Erik Helin wrote: > All, > > based on a discussion with Bengt and Christian, we decided to move the > JmapLauncher into the existing testlibrary since it all tests are > likely to benefit from it, not only GC tests. > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.03/ > > Thanks, > Erik > > On 03/12/2013 01:14 PM, Christian T?rnqvist wrote: >> Hi Erik, >> >> The change looks good :) >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Erik Helin >> Sent: den 11 mars 2013 16:26 >> To: Staffan Larsen >> Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian T?rnqvist >> Subject: Re: RFR (XS): 8009408: >> gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" >> >> All, >> >> I've updated the change quite a bit based on feedback from Bengt and >> Christian. >> >> The class JmapLauncher has moved to the newly created gc testlibrary. >> This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to >> contain utilities that can be used by all the gc jtreg tests. If >> there are code that is of interest for additional tests, then code >> can be easily be moved from the gc testlibrary to the general >> testlibrary. >> >> I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of >> this new gc testlibrary. >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ >> >> Thanks, >> Erik >> >> On 03/08/2013 01:34 PM, Staffan Larsen wrote: >>> Looks good to me. >>> >>> /Staffan >>> >>> On 8 mar 2013, at 13:36, Erik Helin wrote: >>> >>>> Bengt and Staffan, >>>> >>>> thanks for he feedback! >>>> >>>> I've updated the change to make use of the method >>>> getPlatformSpecificVMArgs() and also abstracted the jmap command >>>> generation slightly. >>>> >>>> I don't know if this new little class, JMapLauncher, should be part >>>> of the testlibrary or not, or if we should put parts of it in the >>>> testlibrary. Christian, maybe you can comment on this? >>>> >>>> Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>>>> >>>>> Erik and Staffan, >>>>> >>>>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>>>> that returns "-d64" if necessary. You can't use this as is since you >>>>> need to get "J-d64" but I think we should do something to make your >>>>> solution more general. >>>>> >>>>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>>>> or adding a separate method that returns "JDK-tools formatted" args. >>>>> It seems a bit too limited to fix this only for your particular >>>>> test. Would be nice to get it in to the testlibrary somehow. >>>>> >>>>> Bengt >>>>> >>>>> >>>>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>>>> Looks good. I wish we could abstract this away so that not every >>>>>> test needs to do this work. >>>>>> >>>>>> /Staffan (mobile) >>>>>> >>>>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>>>> arch) when running jmap in the test >>>>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>> >>>> >>> >> > From stefan.karlsson at oracle.com Mon Mar 18 13:49:48 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 18 Mar 2013 13:49:48 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 38 new changesets Message-ID: <20130318135105.C67A54820E@hg.openjdk.java.net> Changeset: 255c0a4cb4eb Author: sla Date: 2013-03-05 08:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/255c0a4cb4eb 8009287: [parfait] Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c Reviewed-by: dholmes, kvn, mikael, morris ! agent/src/os/linux/ps_core.c Changeset: 9058789475af Author: iklam Date: 2013-03-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9058789475af 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu Contributed-by: ioi.lam at oracle.com ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c Changeset: 6b803ba47588 Author: zgu Date: 2013-03-07 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6b803ba47588 8008257: NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Summary: Corrected virtual memory recording and tagging code when large pages are used Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 3efdfd6ddbf2 Author: coleenp Date: 2013-03-08 11:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3efdfd6ddbf2 8003553: NPG: metaspace objects should be zeroed in constructors Summary: Zero metadata in constructors, not in allocation (and some in constructors) Reviewed-by: jmasa, sspitsyn ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.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/methodData.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 252ad8d5f22b Author: dcubed Date: 2013-03-08 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/252ad8d5f22b Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 35ef86296a5d Author: dcubed Date: 2013-03-08 17:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/35ef86296a5d Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 5939f5953b45 Author: coleenp Date: 2013-03-13 09:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5939f5953b45 8009836: nsk/regression/b4222717 fails with empty stack trace Summary: Some zeroing was missed for bug 8003553, causing empty stack traces and Xcom crashes, add back zeroing to metablock Reviewed-by: dholmes, rbackman ! src/share/vm/memory/metablock.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/method.cpp Changeset: 96480359523a Author: coleenp Date: 2013-03-11 14:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/96480359523a 8008965: @Contended fails with classes having static fields Summary: Disable @Contended support for static fields Reviewed-by: coleenp, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp + test/runtime/8003985/Test8003985.java Changeset: d6320e955c89 Author: coleenp Date: 2013-03-13 13:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d6320e955c89 Merge Changeset: 0ede345ec7c9 Author: coleenp Date: 2013-03-13 15:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0ede345ec7c9 8009829: CDS: JDK JPRT test fails crash in Symbol::equals() Summary: -Xshare:dump was creating a Symbol in C_heap. There's an assert there that jdk jprt wasn't hitting because it was only done in product Reviewed-by: dholmes, hseigel, iklam ! src/share/vm/classfile/symbolTable.cpp Changeset: c8b31b461e1a Author: coleenp Date: 2013-03-13 17:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c8b31b461e1a 8003419: NPG: Clean up metadata created during class loading if failure Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. Reviewed-by: jmasa, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: fad90b102190 Author: jprovino Date: 2013-03-06 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fad90b102190 8008310: Some adjustments needed to minimal VM warnings and errors for unsupported command line options Summary: Changes to arguments.cpp for warnings vs. errors. Changes for CDS arguments. Reviewed-by: coleenp, cjplummer ! make/excludeSrc.make ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 47bc9800972c Author: jprovino Date: 2013-03-06 13:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/47bc9800972c 8006498: #if is wrong in the code. Summary: ASSERT and other symbols used incorrectly with #if are supposed to be defined or not. Reviewed-by: dholmes, mikael ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiTrace.hpp Changeset: 67342b960b47 Author: jprovino Date: 2013-03-06 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/67342b960b47 8008474: Add -Wundef to warning flags. Summary: Force use of undefined macros to be and error. Reviewed-by: dholmes, mikael ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: cb75b67f04fb Author: jprovino Date: 2013-03-08 12:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cb75b67f04fb Merge ! make/bsd/makefiles/gcc.make Changeset: 69ffa4ac9e53 Author: jprovino Date: 2013-03-12 00:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/69ffa4ac9e53 8009835: Only produce a warning when -Xshare:auto is explicitly requested Summary: The minimal JVM is printing a warning message for default settings when it should quitely ignore them. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 9102c4111564 Author: jprovino Date: 2013-03-14 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9102c4111564 Merge Changeset: ed53b50794d7 Author: vladidan Date: 2013-03-14 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ed53b50794d7 Merge Changeset: 0094485b46c7 Author: roland Date: 2013-03-13 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0094485b46c7 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates Summary: deoptimization doesn't set up callee frames so that they restore caller frames correctly. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp + test/compiler/8009761/Test8009761.java Changeset: 056ab43544a4 Author: neliasso Date: 2013-03-13 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/056ab43544a4 8009721: Make PhaseLive independent from regalloc Summary: Moved class definition of LRG_List from chaitin.hpp to live.hpp Reviewed-by: kvn, rbackman, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/live.hpp Changeset: 6d98efabf3ba Author: neliasso Date: 2013-03-13 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6d98efabf3ba Merge Changeset: b7c2c5b2572c Author: neliasso Date: 2013-02-13 10:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b7c2c5b2572c 8005772: Stubs report compile id -1 in phase events Summary: Use 0 to indicate id is NA, -1 for error or uninitalized Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp Changeset: 71f13276159d Author: morris Date: 2013-03-14 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/71f13276159d 8008560: [parfait] Null pointer deference in hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Summary: add null pointer check in signal handler Reviewed-by: kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: fba788946616 Author: morris Date: 2013-03-14 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fba788946616 Merge Changeset: 15401203db6b Author: stefank Date: 2013-03-15 08:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/15401203db6b Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a10dc1469c3f Author: stefank Date: 2013-03-15 04:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a10dc1469c3f Merge Changeset: f1629878512f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f1629878512f Added tag jdk8-b81 for changeset 65b797426a3b ! .hgtags Changeset: b95ad0610fef Author: asaha Date: 2012-10-26 09:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b95ad0610fef Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 77443715ec55 Author: kamg Date: 2012-11-05 17:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/77443715ec55 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: kvn, acorn ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp Changeset: b5cb079ecaa4 Author: ewendeli Date: 2013-02-03 22:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b5cb079ecaa4 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1cabf9c80e84 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cabf9c80e84 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d4a32a6f8c82 Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d4a32a6f8c82 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 11d5942ef9c7 Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/11d5942ef9c7 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ee744831dcb Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5ee744831dcb Merge Changeset: 0631ebcc45f0 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0631ebcc45f0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3db4ab0e12f4 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3db4ab0e12f4 Added tag hs25-b23 for changeset 0631ebcc45f0 ! .hgtags Changeset: 7ae04e71af90 Author: amurillo Date: 2013-03-15 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7ae04e71af90 8010105: new hotspot build - hs25-b24 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 19f9fabd94cc Author: stefank Date: 2013-03-18 09:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/19f9fabd94cc Merge ! src/share/vm/memory/metaspace.cpp From john.cuthbertson at oracle.com Mon Mar 18 16:37:03 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 18 Mar 2013 09:37:03 -0700 Subject: RFR(S): 8009536: G1: Apache Lucene hang during reference processing In-Reply-To: <5146FD28.7070609@oracle.com> References: <513E4E3E.4020405@oracle.com> <513FA57B.8060705@oracle.com> <5140534E.7050607@oracle.com> <5140BE05.50206@oracle.com> <5140E936.1020903@oracle.com> <51420692.10802@oracle.com> <5146FD28.7070609@oracle.com> Message-ID: <514742AF.70807@oracle.com> Hi Bengt, Thanks. I'll make the change as you suggest. For some reason the push job failed on MacOS. It looks exactly like the problem these changes are supposed to fix. JohnC On 3/18/2013 4:40 AM, Bengt Rutisson wrote: > > Hi John, > > This looks good to me. Just like I thought ;) > > One nit if you feel like fixing it before you push: > > In a couple places you have this pattern: > > 2240 _task->do_marking_step(mark_step_duration_ms, > 2241 false /* do_termination */, > 2242 _is_serial /* is_serial */); > > I think the comment /* is_serial */ is superfluous now that we pass a > variable named _is_serial instead of just true or false. > > Bengt > > > On 3/14/13 6:19 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Here's the final webrev based upon Bengt's comments: >> >> http://cr.openjdk.java.net/~johnc/8009536/webrev.2/ >> >> I think I'm all set after reviews from Bengt and Thomas - I just >> wanted to send out the final version of the webrev in case anyone >> else has other comments. >> >> Thanks, >> >> JohnC >> >> On 3/13/2013 2:01 PM, Bengt Rutisson wrote: >>> >>> Hi John, >>> >>> Thanks for explaining a bit about the serial case where we still >>> need to go through termination protocol. >>> >>> As you know I'll be on vacation the next two days, so I just wanted >>> to let you know that with the changes that you outline below (the >>> fix to CMRemarkTask and removing the do_stealing argument) I'm fine >>> with this change. Feel free to push this if you get another review. >>> >>> Thanks, >>> Bengt >>> >>> On 3/13/13 6:57 PM, John Cuthbertson wrote: >>>> Hi Bengt, >>>> >>>> Thanks for looking at the change again. Replies inline.... >>>> >>>> On 3/13/2013 3:22 AM, Bengt Rutisson wrote: >>>>> >>>>> >>>>> Hi John, >>>>> >>>>> I'm not too familiar with the do_marking_step() code, so I'm >>>>> trying to get to know it while I'm looking at your webrev. So, >>>>> maybe I'm completely off here, but I think there are a couple of >>>>> strange things. >>>>> >>>>> After your change do_marking_step() takes three bools: >>>>> do_stealing, do_termination and is_serial. >>>>> >>>>> This means that we have 8 possible states if we combine all value >>>>> of these bools. I went through all calls to do_marking_step() and >>>>> it seems like we make use of 4 of those states: >>>>> >>>>> >>>>> G1CMKeepAliveAndDrainClosure::do_oop_work() >>>>> do_marking_step(false, false, true) (1) >>>>> >>>>> CMConcurrentMarkingTask::work() >>>>> do_marking_step(true, true, false) (2) >>>>> >>>>> CMRemarkTask::work() >>>>> do_marking_step(true, true, false) (2) >>>>> do_marking_step(true, true, true) (3) >>>>> >>>>> G1CMDrainMarkingStackClosure::do_void() >>>>> do_marking_step(false, true, true) (4) >>>>> do_marking_step(true, true, false) (2) >>>>> >>>> >>>> Yeah. Well... >>>> >>>>> >>>>> I numbered the states (1) - (4). Here are all states and I marked >>>>> which ones we use: >>>>> >>>>> stealing, termination, serial (3) >>>>> stealing, !termination, serial >>>>> stealing, !termination, !serial >>>>> stealing, termination, !serial (2) parallel >>>>> !stealing, termination, serial (4) >>>>> !stealing, !termination, serial (1) serial >>>>> !stealing, !termination, !serial >>>>> !stealing, termination, !serial >>>>> >>>>> >>>>> I think state (2) makes sense as the parallel case. We do stealing >>>>> and termination and we are not serial. State (1) also makes sense. >>>>> It is clearly the serial case. No stealing or termination. Just >>>>> serial. >>>>> >>>>> Now, case (3) looks odd to me. We say we are serial but we want to >>>>> do stealing and termination. This case comes from CMRemarkTask. It >>>>> takes a is_serial argument in its constructor. We get to case (3) >>>>> from ConcurrentMark::checkpointRootsFinalWork(), where we do: >>>>> >>>>> if (G1CollectedHeap::use_parallel_gc_threads()) { >>>>> ... >>>>> } else { >>>>> ... >>>>> CMRemarkTask remarkTask(this, active_workers, true /* >>>>> is_serial*/); >>>>> } >>>>> >>>>> To me this looks like it should lead to the pure serial case (1) >>>>> instead of (3). Do you agree? In that case I think >>>>> CMRemarkTask::work() needs to be changed to do: >>>>> >>>>> task->do_marking_step(1000000000.0 /* something very large >>>>> */, >>>>> !_is_serial /* do_stealing */, >>>>> !_is_serial /* do_termination */, >>>>> _is_serial); >>>>> >>>> >>>> You're right here. The serial remark case should not enable >>>> stealing. It doesn't make sense. Done! >>>> >>>>> >>>>> The other case that sticks out is (4). We don't want to do >>>>> stealing, but we want to do termination even though we are serial. >>>>> This comes from how we set up the g1_drain_mark_stack in >>>>> ConcurrentMark::weakRefsWork(). We pass that along to the >>>>> reference processing, which I think is serial (wasn't that the >>>>> original problem? :) ). We also pass the g1_keep_alive which is >>>>> set up to be in state (1). So, I wonder if it is correct that the >>>>> g1_drain_mark_stack is in state (4). If you agree that we should >>>>> be using the pure serial case here too, I think we need to change >>>>> G1CMDrainMarkingStackClosure::do_void() to be: >>>>> >>>>> _task->do_marking_step(1000000000.0 /* something very large */, >>>>> !_is_serial /* do_stealing */, >>>>> !_is_serial /* do_termination */, >>>>> _is_serial /* is_serial */); >>>>> >>>>> >>>> >>>> That is what we had before and I wasn't happy with it. The serial >>>> drain closure is the last thing that get's executed as part of >>>> reference processing - when process_phaseJNI invokes the >>>> complete_gc.do_void() method. In the drain closure either serial or >>>> parallel I think we want to go through the termination protocol. We >>>> just don't want to interact with the terminator in the serial case. >>>> There's a bunch of guarantees and checks in the termination >>>> protocol and we should still go through them - even when serial. >>>> >>>>> >>>>> Again, I'm not sure about this, but if the above is correct we >>>>> will be left with only two states. The parallel and the serial. In >>>>> that case I think it would make sense to remove the do_stealing >>>>> and do_termination arguments for do_marking_step() and just pass >>>>> in the is_serial argument. Internally do_marking_step() could set >>>>> up two local variable to track stealing and termination. That >>>>> might be good if we see the need in the future to split these up >>>>> again. >>>> >>>> I think we can get rid of the do_stealing parameter - it's always >>>> the negation of the is_serial parameter and I like the idea of >>>> making it a local. How about that? For example >>>> >>>> void CMTask::do_marking_step(double ms, bool do_termination, bool >>>> is_serial) { >>>> // It does not make sense to allow stealing when called serially. >>>> bool do_stealing = !is_serial; >>>> >>>> Thanks, >>>> >>>> JohnC >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Mar 18 09:06:34 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Mar 2013 10:06:34 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <5140F444.20808@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> <98626133-0e7f-4854-80f1-be415b711eb3@default> <5140F444.20808@oracle.com> Message-ID: <49558944-52CE-4DCF-8B0C-A07457CB0C78@oracle.com> Just a thought: JmapLauncher could benefit from being more general so that it could launch other JDK tools as well - there is nothing jmap-specific in the class. /Staffan On 13 mar 2013, at 22:48, Erik Helin wrote: > All, > > based on a discussion with Bengt and Christian, we decided to move the JmapLauncher into the existing testlibrary since it all tests are likely to benefit from it, not only GC tests. > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.03/ > > Thanks, > Erik > > On 03/12/2013 01:14 PM, Christian T?rnqvist wrote: >> Hi Erik, >> >> The change looks good :) >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Erik Helin >> Sent: den 11 mars 2013 16:26 >> To: Staffan Larsen >> Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian T?rnqvist >> Subject: Re: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" >> >> All, >> >> I've updated the change quite a bit based on feedback from Bengt and Christian. >> >> The class JmapLauncher has moved to the newly created gc testlibrary. >> This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to contain utilities that can be used by all the gc jtreg tests. If there are code that is of interest for additional tests, then code can be easily be moved from the gc testlibrary to the general testlibrary. >> >> I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of this new gc testlibrary. >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ >> >> Thanks, >> Erik >> >> On 03/08/2013 01:34 PM, Staffan Larsen wrote: >>> Looks good to me. >>> >>> /Staffan >>> >>> On 8 mar 2013, at 13:36, Erik Helin wrote: >>> >>>> Bengt and Staffan, >>>> >>>> thanks for he feedback! >>>> >>>> I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. >>>> >>>> I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? >>>> >>>> Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>>>> >>>>> Erik and Staffan, >>>>> >>>>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>>>> that returns "-d64" if necessary. You can't use this as is since you >>>>> need to get "J-d64" but I think we should do something to make your >>>>> solution more general. >>>>> >>>>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>>>> or adding a separate method that returns "JDK-tools formatted" args. >>>>> It seems a bit too limited to fix this only for your particular >>>>> test. Would be nice to get it in to the testlibrary somehow. >>>>> >>>>> Bengt >>>>> >>>>> >>>>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>>>> Looks good. I wish we could abstract this away so that not every >>>>>> test needs to do this work. >>>>>> >>>>>> /Staffan (mobile) >>>>>> >>>>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>>>> arch) when running jmap in the test >>>>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>> >>>> >>> >> > From john.cuthbertson at oracle.com Mon Mar 18 18:01:31 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 18 Mar 2013 11:01:31 -0700 Subject: RFR(S): 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure In-Reply-To: <5146D9EF.8070609@oracle.com> References: <51426BF9.2090802@oracle.com> <5146D9EF.8070609@oracle.com> Message-ID: <5147567B.1000604@oracle.com> Hi Bengt, Thanks for reviewing these changes. Cheers, JohnC On 3/18/2013 2:10 AM, Bengt Rutisson wrote: > > > Hi John, > > Looks good. > > Bengt > > > On 3/15/13 1:31 AM, John Cuthbertson wrote: >> Hi Everyone, >> >> Here's another one associated with overflowing the marking stack. The >> webrev can be found at: >> >> http://cr.openjdk.java.net/~johnc/8008301/webrev.0/ >> >> Summary: >> In this case the marking stack overflows during the actual remark >> task - when the individual marking tasks are draining the completed >> SATB buffers. As a result we exit the remark task (because of the >> overflow) with some legitimately unprocessed completed SATB buffers >> and trip the guarantee. >> >> The main part of the fix is between line 2575 and 2579 where I relax >> the guarantee to allow for the overflow. Additionally I've also added >> a heap verification for when we restart marking due to overflow. I >> added it as part of the debugging and I think it makes sense to leave >> it in. >> >> The change between lines 2408 and 2416 is to just skip reference >> processing. While testing I was running into the hang reported in >> 8009536 and added this to work around it. An equivalent change will >> be pushed as part of the changes for 8009940. >> >> Testing: >> The failing test case in a loop (with and without instrumentation and >> VerifyDuringGC) >> The GC test suite with a small mark stack size (2K, 4K) >> The Lucene tests for 8009536 to specifically test the verification >> after overflow. >> >> Thanks, >> >> JohnC > From tao.mao at oracle.com Mon Mar 18 18:45:45 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 18 Mar 2013 11:45:45 -0700 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <1363610981.2603.42.camel@cirrus> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> <5139022B.4070209@oracle.com> <51426E1F.5000304@oracle.com> <51434E5F.8080709@oracle.com> <1363610981.2603.42.camel@cirrus> Message-ID: <514760D9.300@oracle.com> I checked that the logic flow you showed is correct. A new webrev is updated. http://cr.openjdk.java.net/~tamao/7196080/webrev.02/ Thanks. Tao On 3/18/13 5:49 AM, Thomas Schatzl wrote: > Hi all, > > On Fri, 2013-03-15 at 09:37 -0700, Jon Masamitsu wrote: >> Looks fine. >> >> Jon >> >> On 3/14/2013 5:41 PM, Tao Mao wrote: >>> The comment >>> >>> " 1172 // MaxHeapSize is aligned down in collectorPolicy" >>> >>> mislead here so I deleted it (because: in fact, in >>> collectorPolicy.cpp, MaxHeapSize is aligned up). But the assertions >>> still have some value. >>> > both asserts will fail when using a small heap size, e.g. 1-3M. > > This is because default OldSize (and NewSize) are>=4(>=1M) > respectively. > (>= due to the use of ScaleForWordSize() on 64 bit) > > Additionally, in TwoGenerationPolicy::initialize_flags(), > OldSize/NewSize and MaxHeapSize are intentionally synched, i.e. > MaxHeapSize = OldSize + NewSize so that these asserts hold. > > My suggestion is to just remove them as these asserts seem to contradict > TwoGenerationPolicy::initialize_flags(). > Atm these asserts cause differences in what heap sizes the VM accepts > when running with or without debug info when using cms. > > Sorry for being a bit late. > > Thomas > > From jesper.wilhelmsson at oracle.com Mon Mar 18 21:04:30 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 18 Mar 2013 22:04:30 +0100 Subject: RFR(XS): 8010227: Remove promotion failed from young collection event Message-ID: <5147815E.20601@oracle.com> Could I have a couple of reviews for this really small change? Bug 8010227: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010227 The young garbage collection tracing event has a boolean to indicate if a promotion failed has occurred or not. This information is also available in its own event so the variable is duplicating the information. It was introduced for convenience to make it easy to see if a collection got promotion failed or not when looking at the GC events. However, the existence of this variable complicates the implementation of the evacuation failed event for G1, so we have decided to remove it. Webrev: http://cr.openjdk.java.net/~jwilhelm/8010227/webrev/ Thanks, /Jesper From john.cuthbertson at oracle.com Tue Mar 19 01:21:09 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 19 Mar 2013 01:21:09 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing Message-ID: <20130319012113.3D86148231@hg.openjdk.java.net> Changeset: fa08949fe0cb Author: johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp From david.holmes at oracle.com Tue Mar 19 01:31:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 11:31:52 +1000 Subject: RFR(XS): 8010227: Remove promotion failed from young collection event In-Reply-To: <5147815E.20601@oracle.com> References: <5147815E.20601@oracle.com> Message-ID: <5147C008.80408@oracle.com> This deletion looks fine to me. David On 19/03/2013 7:04 AM, Jesper Wilhelmsson wrote: > Could I have a couple of reviews for this really small change? > > Bug 8010227: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010227 > > The young garbage collection tracing event has a boolean to indicate if > a promotion failed has occurred or not. This information is also > available in its own event so the variable is duplicating the > information. It was introduced for convenience to make it easy to see if > a collection got promotion failed or not when looking at the GC events. > However, the existence of this variable complicates the implementation > of the evacuation failed event for G1, so we have decided to remove it. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8010227/webrev/ > > Thanks, > /Jesper From daniel.daugherty at oracle.com Tue Mar 19 02:48:56 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Mar 2013 20:48:56 -0600 Subject: Committed should not larger than max_size in ContiguousSpacePool while using ParNew with UseAdaptiveSizePolicy In-Reply-To: <18C57CA0D63174418D00CFAB14D96F6602C85C@CNHZ-EXMAIL-07.ali.com> References: <18C57CA0D63174418D00CFAB14D96F6602C85C@CNHZ-EXMAIL-07.ali.com> Message-ID: <5147D218.9060402@oracle.com> Hongxi, I'm redirecting this message to the HotSpot GC OpenJDK alias and the Serviceability OpenJDK alias. JMX is owned by the Serviceability team and you've also got some GC questions here... Dan P.S. Bcc'ed the Runtime OpenJDK so you folks know that this message has been redirected... On 3/18/13 7:59 PM, ??(hongxi) wrote: > > Hi all? > > Sorry if here is not the right place to submit this small fix. > > Days ago, some of our systems occur this exception: > > 2013-01-22 16:59:07,351 ERROR protocol.MBeanServerMessageHandler {141} > - handle message error objectName=com.alibaba.dragoon:type=GC > > javax.management.RuntimeErrorException: java.lang.InternalError: > Memory Pool not found > > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:858) > > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869) > > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:670) > > at > com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) > > at > com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.getAttributeInternal(MBeanServerMessageHandler.java:242) > > at > com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.handle(MBeanServerMessageHandler.java:113) > > at > com.alibaba.dragoon.common.protocol.MessageHandlerAdapter.handle(MessageHandlerAdapter.java:53) > > at > com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessageIntenal(DragoonSession.java:204) > > at > com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessage(DragoonSession.java:178) > > at > com.alibaba.dragoon.common.protocol.transport.socket.SocketSessionImpl$1.run(SocketSessionImpl.java:211) > > Caused by: java.lang.InternalError: Memory Pool not found > > at sun.management.MemoryPoolImpl.getUsage0(Native Method) > > at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:77) > > at com.alibaba.dragoon.client.jmx.GC.getEdenSpaceUsed(GC.java:185) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:597) > > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) > > at > com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) > > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) > > at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) > > at > com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) > > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) > > ... 7 more > > The jvm argument is as bellow? > > /usr/java/bin/java -server -Xmx5g -Xms5g -Xmn512m -XX:PermSize=128m > -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC > -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection > > -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly > -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCompressedOops > -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy > > -Dcom.sun.management.jmxremote.port=1100 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Djava.rmi.server.hostname=localhost > > -Dhummock.output.logs=/home/admin/output/logs -Djava.awt.headless=true > -Djava.net.preferIPv4Stack=true > > At last, we found it?s possible a jvm bug, when UseAdaptiveSizePolicy > + ParNew, if the eden is expanded the max size of eden?s > ContiguousSpacePool will not be updated, perhaps the commited is > larger than max_size. Though at last I know UseAdaptiveSizePolicy has > some problems with CMS and it has been disabled in the latest jdk7u, I > think I should submit a patch to fix this small bug. My patch is in > the attachment. > > Regrads > > hongxi > > > ------------------------------------------------------------------------ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or > disclose its contents to any other person. Thank you. > > ???(??????)???????????????????????? > ????????????????????????????? ????? > ???????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Mar 19 06:53:26 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 19 Mar 2013 07:53:26 +0100 Subject: Committed should not larger than max_size in ContiguousSpacePool while using ParNew with UseAdaptiveSizePolicy In-Reply-To: <5147D218.9060402@oracle.com> References: <18C57CA0D63174418D00CFAB14D96F6602C85C@CNHZ-EXMAIL-07.ali.com> <5147D218.9060402@oracle.com> Message-ID: <51480B66.9010704@oracle.com> Hi Hongxi Thanks for supplying the patch. What Java version are you using? I think that using adaptive sizing with ParNew has never worked very well. In fact this feature has been disabled in the main branch about a year ago (I think it went in to 7u4). See: 7112413 : JVM Crash, possibly GC-related http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112413 So, I would not recommend using -XX:+UseAdaptiveSizePolicy with -XX:+UseConcMarkSweepGC. The only supported GC for adaptive size policy is the parallel GC. Even with your patch I think you will see crashes if you continue running with the command line you supplied. I have only looked briefly at your patch, but I think that it may be hiding a problem more than fixing it. I think we should in fact have max size set up properly. If capacity turns out to be larger than max size we have a real problem. Just hiding this by updating the max size seems a bit scary to me. Bengt On 3/19/13 3:48 AM, Daniel D. Daugherty wrote: > Hongxi, > > I'm redirecting this message to the HotSpot GC OpenJDK alias > and the Serviceability OpenJDK alias. JMX is owned by the > Serviceability team and you've also got some GC questions > here... > > Dan > > P.S. > Bcc'ed the Runtime OpenJDK so you folks know that this message > has been redirected... > > On 3/18/13 7:59 PM, ??(hongxi) wrote: >> >> Hi all? >> >> Sorry if here is not the right place to submit this small fix. >> >> Days ago, some of our systems occur this exception: >> >> 2013-01-22 16:59:07,351 ERROR protocol.MBeanServerMessageHandler >> {141} - handle message error objectName=com.alibaba.dragoon:type=GC >> >> javax.management.RuntimeErrorException: java.lang.InternalError: >> Memory Pool not found >> >> at >> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:858) >> >> at >> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869) >> >> at >> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:670) >> >> at >> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) >> >> at >> com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.getAttributeInternal(MBeanServerMessageHandler.java:242) >> >> at >> com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.handle(MBeanServerMessageHandler.java:113) >> >> at >> com.alibaba.dragoon.common.protocol.MessageHandlerAdapter.handle(MessageHandlerAdapter.java:53) >> >> at >> com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessageIntenal(DragoonSession.java:204) >> >> at >> com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessage(DragoonSession.java:178) >> >> at >> com.alibaba.dragoon.common.protocol.transport.socket.SocketSessionImpl$1.run(SocketSessionImpl.java:211) >> >> Caused by: java.lang.InternalError: Memory Pool not found >> >> at sun.management.MemoryPoolImpl.getUsage0(Native Method) >> >> at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:77) >> >> at com.alibaba.dragoon.client.jmx.GC.getEdenSpaceUsed(GC.java:185) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> >> at java.lang.reflect.Method.invoke(Method.java:597) >> >> at >> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) >> >> at >> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) >> >> at >> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) >> >> at >> com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) >> >> at >> com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) >> >> at >> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) >> >> ... 7 more >> >> The jvm argument is as bellow? >> >> /usr/java/bin/java -server -Xmx5g -Xms5g -Xmn512m -XX:PermSize=128m >> -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC >> -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection >> >> -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly >> -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCompressedOops >> -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy >> >> -Dcom.sun.management.jmxremote.port=1100 >> -Dcom.sun.management.jmxremote.ssl=false >> -Dcom.sun.management.jmxremote.authenticate=false >> -Djava.rmi.server.hostname=localhost >> >> -Dhummock.output.logs=/home/admin/output/logs >> -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true >> >> At last, we found it?s possible a jvm bug, when UseAdaptiveSizePolicy >> + ParNew, if the eden is expanded the max size of eden?s >> ContiguousSpacePool will not be updated, perhaps the commited is >> larger than max_size. Though at last I know UseAdaptiveSizePolicy has >> some problems with CMS and it has been disabled in the latest jdk7u, >> I think I should submit a patch to fix this small bug. My patch is in >> the attachment. >> >> Regrads >> >> hongxi >> >> >> ------------------------------------------------------------------------ >> >> This email (including any attachments) is confidential and may be >> legally privileged. If you received this email in error, please >> delete it immediately and do not copy it or use it for any purpose or >> disclose its contents to any other person. Thank you. >> >> ???(??????)???????????????????????? >> ??????????????????????????? ?? ???? >> ????????????? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hongxi.sy at taobao.com Tue Mar 19 07:27:35 2013 From: hongxi.sy at taobao.com (=?gb2312?B?uunO9Shob25neGkp?=) Date: Tue, 19 Mar 2013 07:27:35 +0000 Subject: =?gb2312?B?tPC4tDogQ29tbWl0dGVkIHNob3VsZCBub3QgbGFyZ2VyIHRoYW4gbWF4X3Np?= =?gb2312?B?emUgaW4gQ29udGlndW91c1NwYWNlUG9vbCB3aGlsZSB1c2luZyBQYXJOZXcg?= =?gb2312?Q?with_UseAdaptiveSizePolicy?= In-Reply-To: <51480B66.9010704@oracle.com> References: <18C57CA0D63174418D00CFAB14D96F6602C85C@CNHZ-EXMAIL-07.ali.com> <5147D218.9060402@oracle.com> <51480B66.9010704@oracle.com> Message-ID: <18C57CA0D63174418D00CFAB14D96F6602C907@CNHZ-EXMAIL-07.ali.com> Our java version is 6u32 ,an old version. Actually The patch can only fix the exception list in the last email. Now our system has closed UseAdaptiveSizePolicy while using CMS, it?s runs happily. Regards hongxi ???: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] ????: 2013?3?19? 14:53 ???: daniel.daugherty at oracle.com ??: ??(hongxi); serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net ??: Re: Committed should not larger than max_size in ContiguousSpacePool while using ParNew with UseAdaptiveSizePolicy Hi Hongxi Thanks for supplying the patch. What Java version are you using? I think that using adaptive sizing with ParNew has never worked very well. In fact this feature has been disabled in the main branch about a year ago (I think it went in to 7u4). See: 7112413 : JVM Crash, possibly GC-related http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112413 So, I would not recommend using -XX:+UseAdaptiveSizePolicy with -XX:+UseConcMarkSweepGC. The only supported GC for adaptive size policy is the parallel GC. Even with your patch I think you will see crashes if you continue running with the command line you supplied. I have only looked briefly at your patch, but I think that it may be hiding a problem more than fixing it. I think we should in fact have max size set up properly. If capacity turns out to be larger than max size we have a real problem. Just hiding this by updating the max size seems a bit scary to me. Bengt On 3/19/13 3:48 AM, Daniel D. Daugherty wrote: Hongxi, I'm redirecting this message to the HotSpot GC OpenJDK alias and the Serviceability OpenJDK alias. JMX is owned by the Serviceability team and you've also got some GC questions here... Dan P.S. Bcc'ed the Runtime OpenJDK so you folks know that this message has been redirected... On 3/18/13 7:59 PM, ??(hongxi) wrote: Hi all? Sorry if here is not the right place to submit this small fix. Days ago, some of our systems occur this exception: 2013-01-22 16:59:07,351 ERROR protocol.MBeanServerMessageHandler {141} - handle message error objectName=com.alibaba.dragoon:type=GC javax.management.RuntimeErrorException: java.lang.InternalError: Memory Pool not found at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:858) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:670) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638) at com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.getAttributeInternal(MBeanServerMessageHandler.java:242) at com.alibaba.dragoon.common.protocol.MBeanServerMessageHandler.handle(MBeanServerMessageHandler.java:113) at com.alibaba.dragoon.common.protocol.MessageHandlerAdapter.handle(MessageHandlerAdapter.java:53) at com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessageIntenal(DragoonSession.java:204) at com.alibaba.dragoon.common.protocol.DragoonSession.receiveMessage(DragoonSession.java:178) at com.alibaba.dragoon.common.protocol.transport.socket.SocketSessionImpl$1.run(SocketSessionImpl.java:211) Caused by: java.lang.InternalError: Memory Pool not found at sun.management.MemoryPoolImpl.getUsage0(Native Method) at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:77) at com.alibaba.dragoon.client.jmx.GC.getEdenSpaceUsed(GC.java:185) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:65) at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:216) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666) ... 7 more The jvm argument is as bellow? /usr/java/bin/java -server -Xmx5g -Xms5g -Xmn512m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCompressedOops -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy -Dcom.sun.management.jmxremote.port=1100 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=localhost -Dhummock.output.logs=/home/admin/output/logs -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true At last, we found it?s possible a jvm bug, when UseAdaptiveSizePolicy + ParNew, if the eden is expanded the max size of eden?s ContiguousSpacePool will not be updated, perhaps the commited is larger than max_size. Though at last I know UseAdaptiveSizePolicy has some problems with CMS and it has been disabled in the latest jdk7u, I think I should submit a patch to fix this small bug. My patch is in the attachment. Regrads hongxi ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???(??????)??????????????????????????????????????????????????? ?? ????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???(??????)?????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Mar 19 09:51:03 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 19 Mar 2013 10:51:03 +0100 Subject: RFR: 8008917 CMS: Concurrent mode failure tracing event In-Reply-To: <513F6AB7.7080401@oracle.com> References: <5130E68A.4040806@oracle.com> <51378071.2060107@oracle.com> <513F509E.3010808@oracle.com> <513F6AB7.7080401@oracle.com> Message-ID: <51483507.6050508@oracle.com> Hi Kevin, Me and Erik looked at this and we think it looks good. One minor thing would be to wrap the lines inside "if (first_state > Idling) {" in a separate method to make it more readable. Thanks, Bengt and Erik On 3/12/13 6:49 PM, Jesper Wilhelmsson wrote: > Looks good! > Ship it! > /Jesper > > > On 12/3/13 4:58 PM, Kevin Walls wrote: >> Hi, >> >> This is the updated hsx24 webrev with a more generic name: >> >> http://cr.openjdk.java.net/~kevinw/8008917/hsx24.01/webrev/ >> >> it builds upon the change for 8009723, so a second failure message is >> removed >> when compared to the parent, as that change isn't in hsx24 yet (only >> latest, so >> a backport of that is required before pushing this). >> >> Thanks >> Kevin >> >> >> Jesper Wilhelmsson wrote: >>> Looks good! >>> >>> Since we want to implement this event for G1 as well, maybe we >>> should remove >>> the "CMS" from the event name and path? >>> >>> Thanks, >>> /Jesper >>> >>> On 1/3/13 6:34 PM, Kevin Walls wrote: >>>> Hi, >>>> >>>> I'd like some reviews on this CMS Concurrent Mode Failure event: >>>> >>>> http://cr.openjdk.java.net/~kevinw/8008917/hotspot/ >>>> >>>> The event doesn't actually carry any new information, but it is a >>>> warning we >>>> need to capture. >>>> >>>> This is against hsx24, I'll prepare the same, or reviewed, changes >>>> against very >>>> latest hotspot also. >>>> >>>> Thanks >>>> Kevin >>>> >> From bengt.rutisson at oracle.com Tue Mar 19 09:53:13 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 19 Mar 2013 10:53:13 +0100 Subject: RFR(XS): 8010227: Remove promotion failed from young collection event In-Reply-To: <5147815E.20601@oracle.com> References: <5147815E.20601@oracle.com> Message-ID: <51483589.5080407@oracle.com> Hi Jesper, I think you can remove the YoungGCInfo class all together. Other than that it looks good. Bengt On 3/18/13 10:04 PM, Jesper Wilhelmsson wrote: > Could I have a couple of reviews for this really small change? > > Bug 8010227: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010227 > > The young garbage collection tracing event has a boolean to indicate > if a promotion failed has occurred or not. This information is also > available in its own event so the variable is duplicating the > information. It was introduced for convenience to make it easy to see > if a collection got promotion failed or not when looking at the GC > events. However, the existence of this variable complicates the > implementation of the evacuation failed event for G1, so we have > decided to remove it. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8010227/webrev/ > > Thanks, > /Jesper -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Tue Mar 19 10:31:50 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 19 Mar 2013 10:31:50 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Message-ID: <20130319103154.BCFA44824C@hg.openjdk.java.net> Changeset: e864cc14ca75 Author: johnc Date: 2013-03-19 00:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e864cc14ca75 8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Summary: Skip reference processing if the global marking stack overflows during remark. Refactor and rename set_phase(); move code that sets the concurrency level into its own routine. Do not call set_phase() from within parallel reference processing; use the concurrency level routine instead. The marking state should only set reset by CMTask[0] during the concurrent phase of the marking cycle; if an overflow occurs at any stage during the remark, the marking state will be reset after reference processing. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp From jesper.wilhelmsson at oracle.com Tue Mar 19 12:13:58 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Mar 2013 13:13:58 +0100 Subject: RFR(XS): 8010227: Remove promotion failed from young collection event In-Reply-To: <51483589.5080407@oracle.com> References: <5147815E.20601@oracle.com> <51483589.5080407@oracle.com> Message-ID: <51485686.2050505@oracle.com> Yes, I'll do that. Thanks! /Jesper On 19/3/13 10:53 AM, Bengt Rutisson wrote: > > Hi Jesper, > > I think you can remove the YoungGCInfo class all together. Other than that it > looks good. > > Bengt > > On 3/18/13 10:04 PM, Jesper Wilhelmsson wrote: >> Could I have a couple of reviews for this really small change? >> >> Bug 8010227: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010227 >> >> The young garbage collection tracing event has a boolean to indicate if a >> promotion failed has occurred or not. This information is also available in >> its own event so the variable is duplicating the information. It was >> introduced for convenience to make it easy to see if a collection got >> promotion failed or not when looking at the GC events. However, the existence >> of this variable complicates the implementation of the evacuation failed event >> for G1, so we have decided to remove it. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010227/webrev/ >> >> Thanks, >> /Jesper > From jesper.wilhelmsson at oracle.com Tue Mar 19 12:15:03 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Mar 2013 13:15:03 +0100 Subject: RFR(XS): 8010227: Remove promotion failed from young collection event In-Reply-To: <5147C008.80408@oracle.com> References: <5147815E.20601@oracle.com> <5147C008.80408@oracle.com> Message-ID: <514856C7.4090201@oracle.com> Thanks for looking at it! /Jesper On 19/3/13 2:31 AM, David Holmes wrote: > This deletion looks fine to me. > > David > > On 19/03/2013 7:04 AM, Jesper Wilhelmsson wrote: >> Could I have a couple of reviews for this really small change? >> >> Bug 8010227: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010227 >> >> The young garbage collection tracing event has a boolean to indicate if >> a promotion failed has occurred or not. This information is also >> available in its own event so the variable is duplicating the >> information. It was introduced for convenience to make it easy to see if >> a collection got promotion failed or not when looking at the GC events. >> However, the existence of this variable complicates the implementation >> of the evacuation failed event for G1, so we have decided to remove it. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010227/webrev/ >> >> Thanks, >> /Jesper From erik.helin at oracle.com Tue Mar 19 13:20:00 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 19 Mar 2013 14:20:00 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer Message-ID: <51486600.8050608@oracle.com> Hi all, the method PSParallelCompact::marking_phase takes a GCTracer* as argument. This is not needed since what is passed is just the address of the instance GCTracer, marking_phase can just use the instance GCTracer directly instead. This change removes the argument and uses the instance GCTracer instead. Webrev: http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 Thanks, Erik From stefan.karlsson at oracle.com Tue Mar 19 13:33:18 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 19 Mar 2013 14:33:18 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <51486600.8050608@oracle.com> References: <51486600.8050608@oracle.com> Message-ID: <5148691E.6020100@oracle.com> Looks good. StefanK On 03/19/2013 02:20 PM, Erik Helin wrote: > Hi all, > > the method PSParallelCompact::marking_phase takes a GCTracer* as > argument. This is not needed since what is passed is just the address > of the instance GCTracer, marking_phase can just use the instance > GCTracer directly instead. > > This change removes the argument and uses the instance GCTracer instead. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 > > Thanks, > Erik From mikael.gerdin at oracle.com Tue Mar 19 13:54:38 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Mar 2013 14:54:38 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <51486600.8050608@oracle.com> References: <51486600.8050608@oracle.com> Message-ID: <51486E1E.8020601@oracle.com> Erik, On 2013-03-19 14:20, Erik Helin wrote: > Hi all, > > the method PSParallelCompact::marking_phase takes a GCTracer* as > argument. This is not needed since what is passed is just the address of > the instance GCTracer, marking_phase can just use the instance GCTracer > directly instead. > > This change removes the argument and uses the instance GCTracer instead. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ I don't see any change to the caller of PSParallelCompact::marking_phase in your webrev, am I missing something? /Mikael > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 > > Thanks, > Erik From erik.helin at oracle.com Tue Mar 19 14:26:53 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 19 Mar 2013 15:26:53 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <51486E1E.8020601@oracle.com> References: <51486600.8050608@oracle.com> <51486E1E.8020601@oracle.com> Message-ID: <514875AD.4070703@oracle.com> Mikael, On 03/19/2013 02:54 PM, Mikael Gerdin wrote: > Erik, > > On 2013-03-19 14:20, Erik Helin wrote: >> Hi all, >> >> the method PSParallelCompact::marking_phase takes a GCTracer* as >> argument. This is not needed since what is passed is just the address of >> the instance GCTracer, marking_phase can just use the instance GCTracer >> directly instead. >> >> This change removes the argument and uses the instance GCTracer instead. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ > > I don't see any change to the caller of PSParallelCompact::marking_phase > in your webrev, am I missing something? No you are not, I am clearly missing something :) Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8010289/webrev.01/ Thanks, Erik > /Mikael > >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 >> >> Thanks, >> Erik From mikael.gerdin at oracle.com Tue Mar 19 15:20:49 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Mar 2013 16:20:49 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <514875AD.4070703@oracle.com> References: <51486600.8050608@oracle.com> <51486E1E.8020601@oracle.com> <514875AD.4070703@oracle.com> Message-ID: <51488251.6050100@oracle.com> Erik, On 2013-03-19 15:26, Erik Helin wrote: > Mikael, > > On 03/19/2013 02:54 PM, Mikael Gerdin wrote: >> Erik, >> >> On 2013-03-19 14:20, Erik Helin wrote: >>> Hi all, >>> >>> the method PSParallelCompact::marking_phase takes a GCTracer* as >>> argument. This is not needed since what is passed is just the address of >>> the instance GCTracer, marking_phase can just use the instance GCTracer >>> directly instead. >>> >>> This change removes the argument and uses the instance GCTracer instead. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ >> >> I don't see any change to the caller of PSParallelCompact::marking_phase >> in your webrev, am I missing something? > > No you are not, I am clearly missing something :) > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8010289/webrev.01/ Looks good, ship it! /m > > Thanks, > Erik > >> /Mikael >> >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 >>> >>> Thanks, >>> Erik > From vladimir.kozlov at oracle.com Tue Mar 19 17:18:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Mar 2013 10:18:18 -0700 Subject: RFR(XS) 8008677: [parfait] Null pointer deference in hotspot/src/share/vm/memory/collectorPolicy.cpp In-Reply-To: <51487950.4050507@oracle.com> References: <51487950.4050507@oracle.com> Message-ID: <51489DDA.9080207@oracle.com> Let GC group review this. Vladimir On 3/19/13 7:42 AM, Morris Meyer wrote: > Folks, > > Could I get a review of this small change for this parfait issue? Per > the workflow this has been through JPRT. > > Thanks in advance! > > --morris > > WEBREV - http://cr.openjdk.java.net/~morris/8008677.01 > BUG - https://jbs.oracle.com/bugs/browse/JDK-8008677 > > From John.Coomes at oracle.com Tue Mar 19 17:45:33 2013 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 19 Mar 2013 10:45:33 -0700 Subject: RFR(XS) 8008677: [parfait] Null pointer deference in hotspot/src/share/vm/memory/collectorPolicy.cpp In-Reply-To: <51489DDA.9080207@oracle.com> References: <51487950.4050507@oracle.com> <51489DDA.9080207@oracle.com> Message-ID: <20808.42045.741551.269273@oracle.com> Vladimir Kozlov (vladimir.kozlov at oracle.com) wrote: > Let GC group review this. Thanks for sending this our way, Vladimir. Morris, there are a number of other places where parfait complains about using the result of get_gen() without checking for null. I'm going to fix them a different way - by changing get_gen() instead of changing all the callers. So I'd like to close 8008677 as a dup of JDK-8006173 [parfait] null pointer dereferences related to get_gen() (Note all the other dups of that bug.) -John > On 3/19/13 7:42 AM, Morris Meyer wrote: > > Folks, > > > > Could I get a review of this small change for this parfait issue? Per > > the workflow this has been through JPRT. > > > > Thanks in advance! > > > > --morris > > > > WEBREV - http://cr.openjdk.java.net/~morris/8008677.01 > > BUG - https://jbs.oracle.com/bugs/browse/JDK-8008677 > > > > From john.cuthbertson at oracle.com Tue Mar 19 18:43:31 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 19 Mar 2013 11:43:31 -0700 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <51486600.8050608@oracle.com> References: <51486600.8050608@oracle.com> Message-ID: <5148B1D3.7010001@oracle.com> Hi Erik, This looks good to me. JohnC On 3/19/2013 6:20 AM, Erik Helin wrote: > Hi all, > > the method PSParallelCompact::marking_phase takes a GCTracer* as > argument. This is not needed since what is passed is just the address > of the instance GCTracer, marking_phase can just use the instance > GCTracer directly instead. > > This change removes the argument and uses the instance GCTracer instead. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 > > Thanks, > Erik From john.cuthbertson at oracle.com Tue Mar 19 20:50:50 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 19 Mar 2013 20:50:50 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Message-ID: <20130319205055.B7F3248269@hg.openjdk.java.net> Changeset: 1179172e9ec9 Author: johnc Date: 2013-03-19 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1179172e9ec9 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Summary: If the marking stack overflows while the marking tasks are draining the SATB buffers, remark will exit with some SATB buffers left unprocessed. Relax the guarantee to allow for overflow. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp From leonid.mesnik at oracle.com Wed Mar 20 11:41:04 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 20 Mar 2013 15:41:04 +0400 Subject: RFR: 8009763 Add WB test for String.intern() In-Reply-To: <5141E0D6.6000800@oracle.com> References: <513ED867.2070902@oracle.com> <513F27FF.5080607@oracle.com> <514051A2.4090800@oracle.com> <5141E0D6.6000800@oracle.com> Message-ID: <5149A050.1040301@oracle.com> Hi Here is next attempt: http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.2/ The StringTable::lookup methods were updated. Leonid On 03/14/2013 06:38 PM, Mikael Gerdin wrote: > Lenoid, > > On 2013-03-13 11:14, Leonid Mesnik wrote: >> Hi >> >> werbrev was updated (thank you for this) >> http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.1/ >> > > Also, I don't know why you have "StringTabe::" inside these calls: > > unsigned int hash = StringTable::hash_string(name, len); > unsigned int index = StringTable::the_table()->hash_to_index(hash); > return StringTable::the_table()->lookup(index, name, len, hash); > > Since you are in an instance method in StringTable you also shouldn't > get the_table() singleton, but rather use the current instance. > > > I think your new lookup() function could be static just as the other > public lookup() function. > > Another idea is to perhaps make these two lookup:s share the same > implementation: > > oop StringTable::lookup(Symbol* symbol) { > ResourceMark rm; > int length; > jchar* chars = symbol->as_unicode(length); > return lookup(chars, length); > } > > oop StringTable::lookup(const jchar* chars, int length) { > unsigned int hashValue = hash_string(chars, length); > int index = the_table()->hash_to_index(hashValue); > return the_table()->lookup(index, chars, length, hashValue); > } > > /Mikael > >> >> JPRT passed with -rtest '*-*-*-runtime/interned' >> >> Leonid >> On 03/12/2013 05:05 PM, Mikael Gerdin wrote: >>> Hi Leonid, >>> >>> On 2013-03-12 08:25, Leonid Mesnik wrote: >>>> Hi >>>> I've added a small test which: >>>> 1) creates java string and intern it >>>> 2) verify that it presents in StringTable >>>> 3) clear reference and call fullGC >>>> 4) verify that there is no such string in StringTable >>>> >>>> Here is webrev: >>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.0/ >>> >>> Overall this looks reasonable. >>> >>> I have some comments though: >>> WB_IsInStringTable is defined to return a jboolean >>> (Ljava/lang/String;)Z >>> but the actual function is defined to return an jint. This will >>> probably work but you should fix this to make it consistent. >>> >>> The function WB_fullGC should have a capital F to be consistent with >>> the naming of the other WB_* functions. >>> >>>> >>>> Tested locally and by JPRT >>>> >>> did you run jprt with -retest '*-*-*-runtime/interned' as well? >>> >>> /Mikael >> >> -- Leonid Mesnik JVM SQE From leonid.mesnik at oracle.com Wed Mar 20 12:16:27 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 20 Mar 2013 16:16:27 +0400 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure Message-ID: <5149A89B.9020001@oracle.com> Hi Could you please review fix for 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure. I've completely rewritten test in java without major changes it test logic. I remove CMS so test could be run when CMS is not supported. Also I changed max memory to 128M to reduce memory load and increase number of GC log entries. Here is the link: http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ -- Leonid Mesnik JVM SQE From erik.helin at oracle.com Wed Mar 20 13:10:09 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 20 Mar 2013 14:10:09 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <5148691E.6020100@oracle.com> References: <51486600.8050608@oracle.com> <5148691E.6020100@oracle.com> Message-ID: <5149B531.7080805@oracle.com> Thanks! On 03/19/2013 02:33 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 03/19/2013 02:20 PM, Erik Helin wrote: >> Hi all, >> >> the method PSParallelCompact::marking_phase takes a GCTracer* as >> argument. This is not needed since what is passed is just the address >> of the instance GCTracer, marking_phase can just use the instance >> GCTracer directly instead. >> >> This change removes the argument and uses the instance GCTracer instead. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 >> >> Thanks, >> Erik > From erik.helin at oracle.com Wed Mar 20 13:10:19 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 20 Mar 2013 14:10:19 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <51488251.6050100@oracle.com> References: <51486600.8050608@oracle.com> <51486E1E.8020601@oracle.com> <514875AD.4070703@oracle.com> <51488251.6050100@oracle.com> Message-ID: <5149B53B.3090801@oracle.com> Thanks! On 03/19/2013 04:20 PM, Mikael Gerdin wrote: > Erik, > > On 2013-03-19 15:26, Erik Helin wrote: >> Mikael, >> >> On 03/19/2013 02:54 PM, Mikael Gerdin wrote: >>> Erik, >>> >>> On 2013-03-19 14:20, Erik Helin wrote: >>>> Hi all, >>>> >>>> the method PSParallelCompact::marking_phase takes a GCTracer* as >>>> argument. This is not needed since what is passed is just the >>>> address of >>>> the instance GCTracer, marking_phase can just use the instance GCTracer >>>> directly instead. >>>> >>>> This change removes the argument and uses the instance GCTracer >>>> instead. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ >>> >>> I don't see any change to the caller of PSParallelCompact::marking_phase >>> in your webrev, am I missing something? >> >> No you are not, I am clearly missing something :) >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8010289/webrev.01/ > > Looks good, ship it! > /m > >> >> Thanks, >> Erik >> >>> /Mikael >>> >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 >>>> >>>> Thanks, >>>> Erik >> From erik.helin at oracle.com Wed Mar 20 13:10:34 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 20 Mar 2013 14:10:34 +0100 Subject: RFR (XXS): 8010289: PSParallelCompact::marking_phase should use instance GCTracer In-Reply-To: <5148B1D3.7010001@oracle.com> References: <51486600.8050608@oracle.com> <5148B1D3.7010001@oracle.com> Message-ID: <5149B54A.5080102@oracle.com> Thank you John! Erik On 03/19/2013 07:43 PM, John Cuthbertson wrote: > Hi Erik, > > This looks good to me. > > JohnC > > On 3/19/2013 6:20 AM, Erik Helin wrote: >> Hi all, >> >> the method PSParallelCompact::marking_phase takes a GCTracer* as >> argument. This is not needed since what is passed is just the address >> of the instance GCTracer, marking_phase can just use the instance >> GCTracer directly instead. >> >> This change removes the argument and uses the instance GCTracer instead. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8010289/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010289 >> >> Thanks, >> Erik > From nils.eliasson at oracle.com Wed Mar 20 15:24:47 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 20 Mar 2013 16:24:47 +0100 Subject: RFR(S): 8007701: Hotspot trace Allocation Events In-Reply-To: <51423640.4000506@oracle.com> References: <51423640.4000506@oracle.com> Message-ID: <5149D4BF.8000704@oracle.com> Thanks for your review Erik, Updated the webrev with your suggestions - Moved alloction events to GCTrace - Renamed class event field to "class" http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/ http://bugs.sun.com/view_bug.do?bug_id=8007701 //Nils Eliasson On 2013-03-14 21:42, Nils Eliasson wrote: > Hi all, > > I would like a review for this change that introduces two new tracing > events. > > "AllocationInNewTLAB" is sent for the first object in a new TLAB and > gives a reasonably cheap and reasonably fair object sampling. > "AllocationOutsideTLAB" is sent for each object that gets allocated > outside the TLABs. (The object doesn't fit or would cause too much > wasted free space if the tlab was discarded.) > > These events use the allocation slow path in CollectedHeap which is > used by default in the template interpreter and the C2 compiler. It is > also used for all TLAB refills in the C1-compiler if the flag > -XX:-FastTLABRefill is supplied. > > http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ > http://bugs.sun.com/view_bug.do?bug_id=8007701 > > The event code for AllocationOutsideTLAB had to be put in > CollectedHeap.cpp since tracing.hpp can't be included into > CollectedHeap.inline.hpp. > > Thanks, > Nils Eliasson From john.cuthbertson at oracle.com Wed Mar 20 16:30:58 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 20 Mar 2013 09:30:58 -0700 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <513855CC.5030009@oracle.com> References: <513855CC.5030009@oracle.com> Message-ID: <5149E442.1030005@oracle.com> Hi Mikael, Your change looks good to me. Cheers, JohnC On 3/7/2013 12:54 AM, Mikael Gerdin wrote: > Hi > > > When deciding when to reserve more metaspace memory we erroneously > looked only at the "capacity" of the metaspace insted of the reserved > space (which is what we ask this function when expanding). > > Additionally, we didn't check MaxMetaspaceSize against the sum of > reserved(Class) + reserved(NonClass) which caused us to use more than > MaxMetaspaceSize even when it was set. > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 > (not yet available at the time of writing this mail) > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 > > Testing: > JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code > path. From ysr1729 at gmail.com Wed Mar 20 19:49:46 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 20 Mar 2013 12:49:46 -0700 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <5149E442.1030005@oracle.com> References: <513855CC.5030009@oracle.com> <5149E442.1030005@oracle.com> Message-ID: One somewhat weakly related question (pardon the abuse of this thread, but I figured it might be easy to get a quick response since we are on the topic of NPG :-) : In what release of HS (HSXX.X-BXX) did NPG get enabled? thanks! -- ramki On Wed, Mar 20, 2013 at 9:30 AM, John Cuthbertson wrote: > Hi Mikael, > > Your change looks good to me. > > Cheers, > > JohnC > > > On 3/7/2013 12:54 AM, Mikael Gerdin wrote: >> >> Hi >> >> >> When deciding when to reserve more metaspace memory we erroneously looked >> only at the "capacity" of the metaspace insted of the reserved space (which >> is what we ask this function when expanding). >> >> Additionally, we didn't check MaxMetaspaceSize against the sum of >> reserved(Class) + reserved(NonClass) which caused us to use more than >> MaxMetaspaceSize even when it was set. >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >> (not yet available at the time of writing this mail) >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >> >> Testing: >> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >> path. > > From yumin.qi at oracle.com Wed Mar 20 21:27:24 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 20 Mar 2013 14:27:24 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime Message-ID: <514A29BC.7040105@oracle.com> Hi, can I have your code review of a small change? 2178143: VM crashes if the number of bound CPUs changed during runtime. Situation: Customer first configure only one CPU online and turn others offline to run java application, after java program started, bring more CPUs back online. Since VM started on a single CPU, os::is_MP() will return false, but after more CPUs available, OS will schedule the app run on multiple CPUs, this caused SEGV in various places where data consistency was broken. The solution is supply a flag to assume it is running on MP, so lock is forced to be called. http://cr.openjdk.java.net/~minqi/2178143/ Thanks Yumin From daniel.daugherty at oracle.com Wed Mar 20 22:46:46 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Mar 2013 16:46:46 -0600 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A29BC.7040105@oracle.com> References: <514A29BC.7040105@oracle.com> Message-ID: <514A3C56.30309@oracle.com> On 3/20/13 3:27 PM, Yumin Qi wrote: > Hi, can I have your code review of a small change? > > 2178143: VM crashes if the number of bound CPUs changed during runtime. > > Situation: Customer first configure only one CPU online and turn > others offline to run java application, after java program started, > bring more CPUs back online. Since VM started on a single CPU, > os::is_MP() will return false, but after more CPUs available, OS will > schedule the app run on multiple CPUs, this caused SEGV in various > places where data consistency was broken. The solution is supply a > flag to assume it is running on MP, so lock is forced to be called. > > http://cr.openjdk.java.net/~minqi/2178143/ The comments in the bug report indicate the possibility of using the new NumberOfProcessors value as a hint for number of GC threads with some sort of upper cap (32). I don't see that change here so I'm guessing that may come via some other changeset... src/share/vm/runtime/arguments.cpp 3253 // NumberOfProcessors is a flag used to assume underlying architecture is MP Instead of "assume" how about "hint that the" or "indicate that the". Might have to break the comment on two lines. 3257 "NumberOfProcessors should be greater that 1", NULL); typo: 'that 1' -> 'than 1' src/share/vm/runtime/globals.hpp 461 "Assume number of processors") \ How about: "Hint about number of processors (must be greater than 1)" The above text is used by one of the special options for printing info about the command line options. src/share/vm/runtime/os.hpp No comments. Dan > > Thanks > Yumin From yumin.qi at oracle.com Wed Mar 20 23:35:07 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 20 Mar 2013 16:35:07 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A3C56.30309@oracle.com> References: <514A29BC.7040105@oracle.com> <514A3C56.30309@oracle.com> Message-ID: <514A47AB.3000207@oracle.com> Hi, Dan On 3/20/2013 3:46 PM, Daniel D. Daugherty wrote: > On 3/20/13 3:27 PM, Yumin Qi wrote: >> Hi, can I have your code review of a small change? >> >> 2178143: VM crashes if the number of bound CPUs changed during runtime. >> >> Situation: Customer first configure only one CPU online and turn >> others offline to run java application, after java program started, >> bring more CPUs back online. Since VM started on a single CPU, >> os::is_MP() will return false, but after more CPUs available, OS will >> schedule the app run on multiple CPUs, this caused SEGV in various >> places where data consistency was broken. The solution is supply a >> flag to assume it is running on MP, so lock is forced to be called. >> >> http://cr.openjdk.java.net/~minqi/2178143/ > > The comments in the bug report indicate the possibility of using > the new NumberOfProcessors value as a hint for number of GC threads > with some sort of upper cap (32). I don't see that change here so > I'm guessing that may come via some other changeset... > The first version included change for ParallelGCThreads but removed after talked to Jon, he suggest not to set ParallelGCThreads = NumberOfProcessors since it will affect a lot of places where default ParallelGCThreads checked. In fact now the only usage of this flag is make is_MP() return true. We could use a boolean flag, but I keep the current name in case in future changes rely on the number for GC threads (this also the answer to Harold's question). > src/share/vm/runtime/arguments.cpp > > 3253 // NumberOfProcessors is a flag used to assume underlying > architecture is MP > > Instead of "assume" how about "hint that the" or "indicate that the". > Might have to break the comment on two lines. Good, will change. > > 3257 "NumberOfProcessors should be greater that 1", NULL); > > typo: 'that 1' -> 'than 1' > Thanks. > src/share/vm/runtime/globals.hpp > > 461 "Assume number of > processors") \ > > How about: > > "Hint about number of processors (must be greater than 1)" > > The above text is used by one of the special options for printing > info about the command line options. > Will change. Thanks Yumin From jesper.wilhelmsson at oracle.com Wed Mar 20 23:46:59 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Mar 2013 00:46:59 +0100 Subject: RFR: Adding evacuation failed tracing event Message-ID: <514A4A73.6080704@oracle.com> Hi, I'm looking for a couple of reviews for this change. The change is to add evacuation failed tracing events to G1. Since the evacuation failed is very similar to a regular promotion failed in other young GCs, these events share most of the code. I have split the change into two parts: 1) JDK-8009992: Prepare tracing of promotion failed for integration of evacuation failed Webrev: http://cr.openjdk.java.net/~jwilhelm/8009992/webrev/ This part refactors the promotion failed code to use a generic copy failed class which is used as the base for the promotion failed handling. 2) JDK-8008916: G1: Evacuation failed tracing event Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/ This part adds the new event for G1 evacuation failed. Thanks, /Jesper From ysr1729 at gmail.com Thu Mar 21 00:03:16 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 20 Mar 2013 17:03:16 -0700 Subject: NPG: when? Message-ID: [Apologies for abusing an existing thread :-/ I changed the subject line] Is there an answer? Or was it a slow osmotic drift towards NPG, so no clear boundary can be defined? In that case, the question might be modified to: in which JDK/HSX release was the former Perm Gen removed from the JVM? If no one recalls, I'll commence some archeology, pick-axe and all. A related hsx mercurial question: I see tags for hsx versions/builds such as hs23-b02 or hs24-b04 (for example), but none for the "dot" releases such as "hs23.5-b02" or "hs24.2-b06". Are those dot tags not possible because the dot releases are branches off of the non-dot parent along with cherry-picked cangesets from the main trunk, or in addition to those in the main trunk? I suppose there are no public hsx "dot" repos, right? thanks! -- ramki On Wed, Mar 20, 2013 at 12:49 PM, Srinivas Ramakrishna wrote: > One somewhat weakly related question (pardon the abuse of this thread, > but I figured it might be easy to get a quick response since we are on > the topic of NPG :-) : In what release of HS (HSXX.X-BXX) did NPG get > enabled? > > thanks! > -- ramki > ... >>> ... metaspace memory ... >>> ... metaspace ... ... >>> MaxMetaspaceSize ... >>> ... >>> ... -XX:MaxMetaspaceSize ... From jon.masamitsu at oracle.com Thu Mar 21 00:14:54 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 20 Mar 2013 17:14:54 -0700 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: References: <513855CC.5030009@oracle.com> <5149E442.1030005@oracle.com> Message-ID: <514A50FE.3070004@oracle.com> We switched the hotspot release to hsx25 (from hsx24) when NPG was integrated so hs25.b02. There was some problem with b01 that I think was unrelated to NPG. Jon On 3/20/2013 12:49 PM, Srinivas Ramakrishna wrote: > One somewhat weakly related question (pardon the abuse of this thread, > but I figured it might be easy to get a quick response since we are on > the topic of NPG :-) : In what release of HS (HSXX.X-BXX) did NPG get > enabled? > > thanks! > -- ramki > > On Wed, Mar 20, 2013 at 9:30 AM, John Cuthbertson > wrote: >> Hi Mikael, >> >> Your change looks good to me. >> >> Cheers, >> >> JohnC >> >> >> On 3/7/2013 12:54 AM, Mikael Gerdin wrote: >>> Hi >>> >>> >>> When deciding when to reserve more metaspace memory we erroneously looked >>> only at the "capacity" of the metaspace insted of the reserved space (which >>> is what we ask this function when expanding). >>> >>> Additionally, we didn't check MaxMetaspaceSize against the sum of >>> reserved(Class) + reserved(NonClass) which caused us to use more than >>> MaxMetaspaceSize even when it was set. >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >>> (not yet available at the time of writing this mail) >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >>> >>> Testing: >>> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >>> path. >> From ysr1729 at gmail.com Thu Mar 21 00:18:06 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 20 Mar 2013 17:18:06 -0700 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <514A50FE.3070004@oracle.com> References: <513855CC.5030009@oracle.com> <5149E442.1030005@oracle.com> <514A50FE.3070004@oracle.com> Message-ID: Great, thanks Jon! And just as your email arrived I found yr old email announcement: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006679.html thx for the nice detail there as well! -- ramki On Wed, Mar 20, 2013 at 5:14 PM, Jon Masamitsu wrote: > We switched the hotspot release to hsx25 (from hsx24) when NPG was > integrated so > hs25.b02. There was some problem with b01 that I think was unrelated to > NPG. > > Jon > > > On 3/20/2013 12:49 PM, Srinivas Ramakrishna wrote: >> >> One somewhat weakly related question (pardon the abuse of this thread, >> but I figured it might be easy to get a quick response since we are on >> the topic of NPG :-) : In what release of HS (HSXX.X-BXX) did NPG get >> enabled? >> >> thanks! >> -- ramki >> >> On Wed, Mar 20, 2013 at 9:30 AM, John Cuthbertson >> wrote: >>> >>> Hi Mikael, >>> >>> Your change looks good to me. >>> >>> Cheers, >>> >>> JohnC >>> >>> >>> On 3/7/2013 12:54 AM, Mikael Gerdin wrote: >>>> >>>> Hi >>>> >>>> >>>> When deciding when to reserve more metaspace memory we erroneously >>>> looked >>>> only at the "capacity" of the metaspace insted of the reserved space >>>> (which >>>> is what we ask this function when expanding). >>>> >>>> Additionally, we didn't check MaxMetaspaceSize against the sum of >>>> reserved(Class) + reserved(NonClass) which caused us to use more than >>>> MaxMetaspaceSize even when it was set. >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >>>> (not yet available at the time of writing this mail) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >>>> >>>> Testing: >>>> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >>>> path. >>> >>> > From jon.masamitsu at oracle.com Thu Mar 21 00:28:58 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 20 Mar 2013 17:28:58 -0700 Subject: NPG: when? In-Reply-To: References: Message-ID: <514A544A.8010104@oracle.com> On 3/20/2013 5:03 PM, Srinivas Ramakrishna wrote: > [Apologies for abusing an existing thread :-/ I changed the subject line] > > Is there an answer? Or was it a slow osmotic drift towards NPG, so no > clear boundary can be defined? > > In that case, the question might be modified to: in which JDK/HSX > release was the former Perm Gen removed from the JVM? If no one > recalls, I'll commence some archeology, pick-axe and all. jdk8 b58, hsx25.b02 When NPG happened, the PermSize flags started giving warnings java -XX:PermSize=32m -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b57) Java HotSpot(TM) Server VM (build 24.0-b22, mixed mode) java -XX:PermSize=32m -version Java HotSpot(TM) Server VM warning: ignoring option PermSize=32m; support was removed in 8.0 java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b58) Java HotSpot(TM) Server VM (build 25.0-b02, mixed mode) > > A related hsx mercurial question: I see tags for hsx versions/builds > such as hs23-b02 or hs24-b04 (for example), but none for the "dot" > releases such as "hs23.5-b02" or "hs24.2-b06". Are those dot tags not > possible because the dot releases are branches off of the non-dot > parent along with cherry-picked cangesets from the main trunk, or in > addition to those in the main trunk? I suppose there are no public hsx > "dot" repos, right? Sorry I don't know enough to answer this one definitively. Jon On Wed, Mar 20, 2013 at 12:49 PM, Srinivas Ramakrishna wrote: >> One somewhat weakly related question (pardon the abuse of this thread, >> but I figured it might be easy to get a quick response since we are on >> the topic of NPG :-) : In what release of HS (HSXX.X-BXX) did NPG get >> enabled? >> >> thanks! >> -- ramki >> > ... >>>> ... metaspace memory ... >>>> ... metaspace ... > ... >>>> MaxMetaspaceSize ... >>>> > ... >>>> ... -XX:MaxMetaspaceSize ... From ysr1729 at gmail.com Thu Mar 21 00:35:42 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 20 Mar 2013 17:35:42 -0700 Subject: NPG: when? In-Reply-To: <514A544A.8010104@oracle.com> References: <514A544A.8010104@oracle.com> Message-ID: Thanks a ton Jon, for this additional detail as well (in addition to your previous answer in the other thread)! -- ramki On Wed, Mar 20, 2013 at 5:28 PM, Jon Masamitsu wrote: > > On 3/20/2013 5:03 PM, Srinivas Ramakrishna wrote: >> >> [Apologies for abusing an existing thread :-/ I changed the subject line] >> >> Is there an answer? Or was it a slow osmotic drift towards NPG, so no >> clear boundary can be defined? >> >> In that case, the question might be modified to: in which JDK/HSX >> release was the former Perm Gen removed from the JVM? If no one >> recalls, I'll commence some archeology, pick-axe and all. > > > jdk8 b58, hsx25.b02 > > When NPG happened, the PermSize flags started giving warnings > > > java -XX:PermSize=32m -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b57) > Java HotSpot(TM) Server VM (build 24.0-b22, mixed mode) > > java -XX:PermSize=32m -version > Java HotSpot(TM) Server VM warning: ignoring option PermSize=32m; support > was removed in 8.0 > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b58) > Java HotSpot(TM) Server VM (build 25.0-b02, mixed mode) > > > > > >> >> A related hsx mercurial question: I see tags for hsx versions/builds >> such as hs23-b02 or hs24-b04 (for example), but none for the "dot" >> releases such as "hs23.5-b02" or "hs24.2-b06". Are those dot tags not >> possible because the dot releases are branches off of the non-dot >> parent along with cherry-picked cangesets from the main trunk, or in >> addition to those in the main trunk? I suppose there are no public hsx >> "dot" repos, right? > > > > Sorry I don't know enough to answer this one definitively. > > Jon > > > On Wed, Mar 20, 2013 at 12:49 PM, Srinivas Ramakrishna > wrote: >>> >>> One somewhat weakly related question (pardon the abuse of this thread, >>> but I figured it might be easy to get a quick response since we are on >>> the topic of NPG :-) : In what release of HS (HSXX.X-BXX) did NPG get >>> enabled? >>> >>> thanks! >>> -- ramki >>> >> ... >>>>> >>>>> ... metaspace memory ... >>>>> ... metaspace ... >> >> ... >>>>> >>>>> MaxMetaspaceSize ... >>>>> >> ... >>>>> >>>>> ... -XX:MaxMetaspaceSize ... > > From david.holmes at oracle.com Thu Mar 21 01:02:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Mar 2013 11:02:50 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A29BC.7040105@oracle.com> References: <514A29BC.7040105@oracle.com> Message-ID: <514A5C3A.4040401@oracle.com> On 21/03/2013 7:27 AM, Yumin Qi wrote: > Hi, can I have your code review of a small change? Not really small conceptually. :) I don't think this form of the fix addresses the underlying issue as discussed in the bug report. If the variable was renamed MinimumNumberOfProcessors, or MinimumAssumedProcessors, then simply using it to turn on is_MP would be okay. Such a flag would suit the initial problem perfectly. Of course any value >2 would be semantically indistinct, so this really acts as a boolean flag - AssumeMP. The more general NumberOfProcessors approach, which I'm still unsure of, should to me control what is reported for available-processors. That way it would affect everything in the VM, libraries and application code that configures itself based on the number of available processors. The main usecase for that, in my opinion, would be for apps running on large systems but you want to constrain it to using a subset of the physical CPUs (without having to configure processor sets). That is a different kind of problem and a different kind of flag. Using NumberOfProcessors but not having it control anything except is_MP just seems wrong - and using it to replace available_processors is not a complex change. The VM is not designed for dynamic adaptation of threads/pools so if the number of processors does change dynamically neither of the above options are going to provide solutions to the potential performance problems that will be encountered (too many or too few threads). Any apps that starts on single core (as reported by the OS) is going to be under-provisioned. David ----- > 2178143: VM crashes if the number of bound CPUs changed during runtime. > > Situation: Customer first configure only one CPU online and turn others > offline to run java application, after java program started, bring more > CPUs back online. Since VM started on a single CPU, os::is_MP() will > return false, but after more CPUs available, OS will schedule the app > run on multiple CPUs, this caused SEGV in various places where data > consistency was broken. The solution is supply a flag to assume it is > running on MP, so lock is forced to be called. > > http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin From david.holmes at oracle.com Thu Mar 21 01:35:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Mar 2013 11:35:04 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A5C3A.4040401@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> Message-ID: <514A63C8.3060809@oracle.com> Correction: we have two API's concerning the processor count: one static and one dynamic. We actually use the dynamic version in a number of places including Runtime.availableProcessors() - so libraries and apps can act dynamically (but most won't eg default ForkJoinPool will be sized based on active processor count at VM initialization time). That makes the "NumberOfProcessors" version even more complex/problematic. Does it mean the static count or the dynamic count? Might different use cases want different answers to that? I think there is no clear answer for how a general "NumberOfProcessors" variable might be used, and I don't expect to have one in the short to mid term for JDK 8. To that end I suggest simply changing this to AssumeMP and use it to only affect is_MP. That is not incompatible with adding NumberOfProcessors later on, if general desirable semantics can be worked out. But there is still a question, as raised in the CR as to what the default for this should be. It is argued in the CR that in the pervasive multi-core world, we should AssumeMP, and allow it to be disabled by apps that are truly run on uni-processors and which would get a performance hit otherwise. Though we might want to only do that with SE rather than Embedded. David On 21/03/2013 11:02 AM, David Holmes wrote: > On 21/03/2013 7:27 AM, Yumin Qi wrote: >> Hi, can I have your code review of a small change? > > Not really small conceptually. :) > > I don't think this form of the fix addresses the underlying issue as > discussed in the bug report. If the variable was renamed > MinimumNumberOfProcessors, or MinimumAssumedProcessors, then simply > using it to turn on is_MP would be okay. Such a flag would suit the > initial problem perfectly. Of course any value >2 would be semantically > indistinct, so this really acts as a boolean flag - AssumeMP. > > The more general NumberOfProcessors approach, which I'm still unsure of, > should to me control what is reported for available-processors. That way > it would affect everything in the VM, libraries and application code > that configures itself based on the number of available processors. The > main usecase for that, in my opinion, would be for apps running on large > systems but you want to constrain it to using a subset of the physical > CPUs (without having to configure processor sets). That is a different > kind of problem and a different kind of flag. Using NumberOfProcessors > but not having it control anything except is_MP just seems wrong - and > using it to replace available_processors is not a complex change. > > The VM is not designed for dynamic adaptation of threads/pools so if the > number of processors does change dynamically neither of the above > options are going to provide solutions to the potential performance > problems that will be encountered (too many or too few threads). Any > apps that starts on single core (as reported by the OS) is going to be > under-provisioned. > > David > ----- > >> 2178143: VM crashes if the number of bound CPUs changed during runtime. >> >> Situation: Customer first configure only one CPU online and turn others >> offline to run java application, after java program started, bring more >> CPUs back online. Since VM started on a single CPU, os::is_MP() will >> return false, but after more CPUs available, OS will schedule the app >> run on multiple CPUs, this caused SEGV in various places where data >> consistency was broken. The solution is supply a flag to assume it is >> running on MP, so lock is forced to be called. >> >> http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin From jon.masamitsu at oracle.com Thu Mar 21 01:37:20 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 20 Mar 2013 18:37:20 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A47AB.3000207@oracle.com> References: <514A29BC.7040105@oracle.com> <514A3C56.30309@oracle.com> <514A47AB.3000207@oracle.com> Message-ID: <514A6450.9090505@oracle.com> On 3/20/2013 4:35 PM, Yumin Qi wrote: > Hi, Dan > > On 3/20/2013 3:46 PM, Daniel D. Daugherty wrote: >> On 3/20/13 3:27 PM, Yumin Qi wrote: >>> Hi, can I have your code review of a small change? >>> >>> 2178143: VM crashes if the number of bound CPUs changed during >>> runtime. >>> >>> Situation: Customer first configure only one CPU online and turn >>> others offline to run java application, after java program started, >>> bring more CPUs back online. Since VM started on a single CPU, >>> os::is_MP() will return false, but after more CPUs available, OS >>> will schedule the app run on multiple CPUs, this caused SEGV in >>> various places where data consistency was broken. The solution is >>> supply a flag to assume it is running on MP, so lock is forced to be >>> called. >>> >>> http://cr.openjdk.java.net/~minqi/2178143/ >> >> The comments in the bug report indicate the possibility of using >> the new NumberOfProcessors value as a hint for number of GC threads >> with some sort of upper cap (32). I don't see that change here so >> I'm guessing that may come via some other changeset... >> > The first version included change for ParallelGCThreads but removed > after talked to Jon, he suggest not to set ParallelGCThreads = > NumberOfProcessors since it will affect a lot of places where default > ParallelGCThreads checked. In fact now the only usage of this flag is > make is_MP() return true. We could use a boolean flag, but I keep the > current name in case in future changes rely on the number for GC > threads (this also the answer to Harold's question). Setting ParallelGCThreads to NumberOfProcessors in argument.cpp will have ripple effects that I cannot foresee. There are lots of places where GC code looks a ParallelGCThreads and adjusts it or makes some decision base on it. Some other path needs to be trod to affect the number of GC workers. I suggested available_processor_count() as a safer path. Jon >> src/share/vm/runtime/arguments.cpp >> >> 3253 // NumberOfProcessors is a flag used to assume underlying >> architecture is MP >> >> Instead of "assume" how about "hint that the" or "indicate that >> the". >> Might have to break the comment on two lines. > Good, will change. >> >> 3257 "NumberOfProcessors should be greater that 1", NULL); >> >> typo: 'that 1' -> 'than 1' >> > Thanks. >> src/share/vm/runtime/globals.hpp >> >> 461 "Assume number of >> processors") \ >> >> How about: >> >> "Hint about number of processors (must be greater than 1)" >> >> The above text is used by one of the special options for printing >> info about the command line options. >> > Will change. > > > Thanks > Yumin > From yumin.qi at oracle.com Thu Mar 21 04:37:05 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 20 Mar 2013 21:37:05 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A5C3A.4040401@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> Message-ID: <514A8E71.10105@oracle.com> Hi, David On 3/20/2013 6:02 PM, David Holmes wrote: > On 21/03/2013 7:27 AM, Yumin Qi wrote: >> Hi, can I have your code review of a small change? > > Not really small conceptually. :) > > I don't think this form of the fix addresses the underlying issue as > discussed in the bug report. If the variable was renamed > MinimumNumberOfProcessors, or MinimumAssumedProcessors, then simply > using it to turn on is_MP would be okay. Such a flag would suit the > initial problem perfectly. Of course any value >2 would be > semantically indistinct, so this really acts as a boolean flag - > AssumeMP. > > The more general NumberOfProcessors approach, which I'm still unsure > of, should to me control what is reported for available-processors. > That way it would affect everything in the VM, libraries and > application code that configures itself based on the number of > available processors. The main usecase for that, in my opinion, would > be for apps running on large systems but you want to constrain it to > using a subset of the physical CPUs (without having to configure > processor sets). That is a different kind of problem and a different > kind of flag. Using NumberOfProcessors but not having it control > anything except is_MP just seems wrong - and using it to replace > available_processors is not a complex change. > > The VM is not designed for dynamic adaptation of threads/pools so if > the number of processors does change dynamically neither of the above > options are going to provide solutions to the potential performance > problems that will be encountered (too many or too few threads). Any > apps that starts on single core (as reported by the OS) is going to be > under-provisioned. > > David > ----- > I think this is only a workaround and not a solution for the specific use case, or there is no perfect solution for it. If customers decided to use this flag, they should be aware that they are ready not to consider performance at first. For using number of available processors, we need to add code to get that number, not the one in hotspot os::active_processor_count() which will return the number of live processors. So do you think I could just use a flag -XX:+AssumeMP work around this problem? Since GC threads will not be based on this assumption, I agree (Harold pointed this out either) that one flag is simpler. In fact, the code for is_MP() is obsolete for today's computers, all with multi-cores (even for cell chips) so I think better solution is remove call to is_MP() in all places in hotspot. I will prepare another webrev with -XX:+AssumeMP for next codereview. For number of GC Threads: unsigned int Abstract_VM_Version::nof_parallel_worker_threads( unsigned int num, unsigned int den, unsigned int switch_pt) { if (FLAG_IS_DEFAULT(ParallelGCThreads)) { assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not 0"); // For very large machines, there are diminishing returns // for large numbers of worker threads. Instead of // hogging the whole system, use a fraction of the workers for every // processor after the first 8. For example, on a 72 cpu machine // and a chosen fraction of 5/8 // use 8 + (72 - 8) * (5/8) == 48 worker threads. unsigned int ncpus = (unsigned int) os::active_processor_count(); return (ncpus <= switch_pt) ? ncpus : (switch_pt + ((ncpus - switch_pt) * num) / den); } else { return ParallelGCThreads; } } the call to this function is unsigned int Abstract_VM_Version::calc_parallel_worker_threads() { return nof_parallel_worker_threads(5, 8, 8); } We can see that, if active_processor_count is 1, it will return 1, and the VM will run with single GC thread. So the better choices maybe: 1) get processor count not active processor count for ParallelGCThreads, that is up to decision from GC team. 2) Recommend usage is -XX:+AssumeMP -XX:ParallelGCThreads= Thanks Yumin >> 2178143: VM crashes if the number of bound CPUs changed during runtime. >> >> Situation: Customer first configure only one CPU online and turn others >> offline to run java application, after java program started, bring more >> CPUs back online. Since VM started on a single CPU, os::is_MP() will >> return false, but after more CPUs available, OS will schedule the app >> run on multiple CPUs, this caused SEGV in various places where data >> consistency was broken. The solution is supply a flag to assume it is >> running on MP, so lock is forced to be called. >> >> http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin From david.holmes at oracle.com Thu Mar 21 05:28:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Mar 2013 15:28:29 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A8E71.10105@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> <514A8E71.10105@oracle.com> Message-ID: <514A9A7D.9070505@oracle.com> Hi Yumin, On 21/03/2013 2:37 PM, Yumin Qi wrote: > I think this is only a workaround and not a solution for the specific > use case, or there is no perfect solution for it. If customers decided > to use this flag, they should be aware that they are ready not to > consider performance at first. For using number of available > processors, we need to add code to get that number, not the one in > hotspot os::active_processor_count() which will return the number of > live processors. So do you think I could just use a flag -XX:+AssumeMP > work around this problem? Since GC threads will not be based on this > assumption, I agree (Harold pointed this out either) that one flag is > simpler. In fact, the code for is_MP() is obsolete for today's > computers, all with multi-cores (even for cell chips) so I think better > solution is remove call to is_MP() in all places in hotspot. I will > prepare another webrev with -XX:+AssumeMP for next codereview. As per my follow up email I think AssumeMP is the way to go for now. We just need to decide whether we think the default should be true or false. Removing is_MP() altogether is more problematic because of the range of platforms this has to work. A build time solution would define is_MP() as a constant for those platforms that want that, and then the is_MP calls will not appear in the generated code - while still allowing other platforms to only insert MP code when needed. But that disallows any runtime configuration for those platforms we assume are always MP. > For number of GC Threads: > unsigned int Abstract_VM_Version::nof_parallel_worker_threads( > unsigned int num, > unsigned int den, > unsigned int > switch_pt) { > if (FLAG_IS_DEFAULT(ParallelGCThreads)) { > assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not 0"); > // For very large machines, there are diminishing returns > // for large numbers of worker threads. Instead of > // hogging the whole system, use a fraction of the workers for every > // processor after the first 8. For example, on a 72 cpu machine > // and a chosen fraction of 5/8 > // use 8 + (72 - 8) * (5/8) == 48 worker threads. > unsigned int ncpus = (unsigned int) os::active_processor_count(); > return (ncpus <= switch_pt) ? > ncpus : > (switch_pt + ((ncpus - switch_pt) * num) / den); > } else { > return ParallelGCThreads; > } > } > > the call to this function is > unsigned int Abstract_VM_Version::calc_parallel_worker_threads() { > return nof_parallel_worker_threads(5, 8, 8); > } > > We can see that, if active_processor_count is 1, it will return 1, and > the VM will run with single GC thread. So the better choices maybe: > > 1) get processor count not active processor count for ParallelGCThreads, > that is up to decision from GC team. Given this occurs at VM startup there may not be any difference. It depends on the OS and any "container" facility (like Solaris zones) as to what number of processors will be seen to "exist" versus what are seen to be "available". But this is a GC ergonomics issue distinct from the is_MP problem. > 2) Recommend usage is > > -XX:+AssumeMP -XX:ParallelGCThreads= It is hard to know whether the people launching the VM will have the necessary knowledge as to what to put here. David ----- > Thanks > Yumin > >>> 2178143: VM crashes if the number of bound CPUs changed during runtime. >>> >>> Situation: Customer first configure only one CPU online and turn others >>> offline to run java application, after java program started, bring more >>> CPUs back online. Since VM started on a single CPU, os::is_MP() will >>> return false, but after more CPUs available, OS will schedule the app >>> run on multiple CPUs, this caused SEGV in various places where data >>> consistency was broken. The solution is supply a flag to assume it is >>> running on MP, so lock is forced to be called. >>> >>> http://cr.openjdk.java.net/~minqi/2178143/ >>> >>> Thanks >>> Yumin > From mikael.gerdin at oracle.com Thu Mar 21 07:52:55 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 21 Mar 2013 08:52:55 +0100 Subject: Review request (S) JDK-8004241 NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option In-Reply-To: <5149E442.1030005@oracle.com> References: <513855CC.5030009@oracle.com> <5149E442.1030005@oracle.com> Message-ID: <514ABC57.2080807@oracle.com> John, On 03/20/2013 05:30 PM, John Cuthbertson wrote: > Hi Mikael, > > Your change looks good to me. Thanks for taking a look at this. I'm all set to push this change now. /Mikael > > Cheers, > > JohnC > > On 3/7/2013 12:54 AM, Mikael Gerdin wrote: >> Hi >> >> >> When deciding when to reserve more metaspace memory we erroneously >> looked only at the "capacity" of the metaspace insted of the reserved >> space (which is what we ask this function when expanding). >> >> Additionally, we didn't check MaxMetaspaceSize against the sum of >> reserved(Class) + reserved(NonClass) which caused us to use more than >> MaxMetaspaceSize even when it was set. >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004241 >> (not yet available at the time of writing this mail) >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8004241/webrev.0 >> >> Testing: >> JPRT with -XX:MaxMetaspaceSize set for all tests to exercise the code >> path. > From thomas.schatzl at oracle.com Thu Mar 21 08:44:26 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 21 Mar 2013 09:44:26 +0100 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <514760D9.300@oracle.com> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> <5139022B.4070209@oracle.com> <51426E1F.5000304@oracle.com> <51434E5F.8080709@oracle.com> <1363610981.2603.42.camel@cirrus> <514760D9.300@oracle.com> Message-ID: <1363855466.2658.15.camel@cirrus> Hi, On Mon, 2013-03-18 at 11:45 -0700, Tao Mao wrote: > I checked that the logic flow you showed is correct. A new webrev is > updated. > http://cr.openjdk.java.net/~tamao/7196080/webrev.02/ Looks okay ;) Note that you still need two real reviewers. Thanks, Thomas From dmitry.samersoff at oracle.com Thu Mar 21 09:16:13 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 21 Mar 2013 13:16:13 +0400 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A9A7D.9070505@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> <514A8E71.10105@oracle.com> <514A9A7D.9070505@oracle.com> Message-ID: <514ACFDD.1080302@oracle.com> Yumin, My few cents. 1. I think MP/SP and number of active CPUs is a different problems, so we should have separate boolean AssumeMP flag and integer NumberOfProcessors flag. Where NumberOfProcessors > 1 set AssumeMP = True, but NumberOfProcessors < 2 *doesn't set* AssumeMP = False. 2. As a long term, IMHO, we should go to always being MP. If the cost of it is too high for some platform, make it compile time platform depended decision. -Dmitry On 2013-03-21 09:28, David Holmes wrote: > Hi Yumin, > > On 21/03/2013 2:37 PM, Yumin Qi wrote: > >> I think this is only a workaround and not a solution for the specific >> use case, or there is no perfect solution for it. If customers decided >> to use this flag, they should be aware that they are ready not to >> consider performance at first. For using number of available >> processors, we need to add code to get that number, not the one in >> hotspot os::active_processor_count() which will return the number of >> live processors. So do you think I could just use a flag -XX:+AssumeMP >> work around this problem? Since GC threads will not be based on this >> assumption, I agree (Harold pointed this out either) that one flag is >> simpler. In fact, the code for is_MP() is obsolete for today's >> computers, all with multi-cores (even for cell chips) so I think better >> solution is remove call to is_MP() in all places in hotspot. I will >> prepare another webrev with -XX:+AssumeMP for next codereview. > > As per my follow up email I think AssumeMP is the way to go for now. We > just need to decide whether we think the default should be true or false. > > Removing is_MP() altogether is more problematic because of the range of > platforms this has to work. A build time solution would define is_MP() > as a constant for those platforms that want that, and then the is_MP > calls will not appear in the generated code - while still allowing other > platforms to only insert MP code when needed. But that disallows any > runtime configuration for those platforms we assume are always MP. > >> For number of GC Threads: >> unsigned int Abstract_VM_Version::nof_parallel_worker_threads( >> unsigned int num, >> unsigned int den, >> unsigned int >> switch_pt) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { >> assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not >> 0"); >> // For very large machines, there are diminishing returns >> // for large numbers of worker threads. Instead of >> // hogging the whole system, use a fraction of the workers for every >> // processor after the first 8. For example, on a 72 cpu machine >> // and a chosen fraction of 5/8 >> // use 8 + (72 - 8) * (5/8) == 48 worker threads. >> unsigned int ncpus = (unsigned int) os::active_processor_count(); >> return (ncpus <= switch_pt) ? >> ncpus : >> (switch_pt + ((ncpus - switch_pt) * num) / den); >> } else { >> return ParallelGCThreads; >> } >> } >> >> the call to this function is >> unsigned int Abstract_VM_Version::calc_parallel_worker_threads() { >> return nof_parallel_worker_threads(5, 8, 8); >> } >> >> We can see that, if active_processor_count is 1, it will return 1, and >> the VM will run with single GC thread. So the better choices maybe: >> >> 1) get processor count not active processor count for ParallelGCThreads, >> that is up to decision from GC team. > > Given this occurs at VM startup there may not be any difference. It > depends on the OS and any "container" facility (like Solaris zones) as > to what number of processors will be seen to "exist" versus what are > seen to be "available". > > But this is a GC ergonomics issue distinct from the is_MP problem. > >> 2) Recommend usage is >> >> -XX:+AssumeMP -XX:ParallelGCThreads= > > It is hard to know whether the people launching the VM will have the > necessary knowledge as to what to put here. > > David > ----- > >> Thanks >> Yumin >> >>>> 2178143: VM crashes if the number of bound CPUs changed during >>>> runtime. >>>> >>>> Situation: Customer first configure only one CPU online and turn others >>>> offline to run java application, after java program started, bring more >>>> CPUs back online. Since VM started on a single CPU, os::is_MP() will >>>> return false, but after more CPUs available, OS will schedule the app >>>> run on multiple CPUs, this caused SEGV in various places where data >>>> consistency was broken. The solution is supply a flag to assume it is >>>> running on MP, so lock is forced to be called. >>>> >>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>> >>>> Thanks >>>> Yumin >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From mikael.gerdin at oracle.com Thu Mar 21 11:40:14 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Thu, 21 Mar 2013 11:40:14 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Message-ID: <20130321114025.0DAE8482E3@hg.openjdk.java.net> Changeset: 7f0cb32dd233 Author: mgerdin Date: 2013-03-21 09:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7f0cb32dd233 8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Summary: Enforce MaxMetaspaceSize for both metaspace parts, check MaxMetaspaceSize against "reserved", not "capacity" Reviewed-by: jmasa, johnc ! src/share/vm/memory/metaspace.cpp From karen.kinnear at oracle.com Thu Mar 21 13:54:11 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 21 Mar 2013 09:54:11 -0400 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A8E71.10105@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> <514A8E71.10105@oracle.com> Message-ID: <3DC21326-1500-4315-8C8A-2D345E191016@oracle.com> Yumin, I really like the suggestion from David and from Harold that we simplify this fix to just be a boolean - isMP, and limit the scope of the change to isMP. It won't change the number of processors, and won't tune everything in the libraries etc. according to actual cpus or processors sets. The original goal was to allow folks to get the MP locking even if there is only one processor when the vm starts up. Let's scale back to that if you don't mind. thanks, Karen On Mar 21, 2013, at 12:37 AM, Yumin Qi wrote: > Hi, David > > On 3/20/2013 6:02 PM, David Holmes wrote: >> On 21/03/2013 7:27 AM, Yumin Qi wrote: >>> Hi, can I have your code review of a small change? >> >> Not really small conceptually. :) >> >> I don't think this form of the fix addresses the underlying issue as discussed in the bug report. If the variable was renamed MinimumNumberOfProcessors, or MinimumAssumedProcessors, then simply using it to turn on is_MP would be okay. Such a flag would suit the initial problem perfectly. Of course any value >2 would be semantically indistinct, so this really acts as a boolean flag - AssumeMP. >> >> The more general NumberOfProcessors approach, which I'm still unsure of, should to me control what is reported for available-processors. That way it would affect everything in the VM, libraries and application code that configures itself based on the number of available processors. The main usecase for that, in my opinion, would be for apps running on large systems but you want to constrain it to using a subset of the physical CPUs (without having to configure processor sets). That is a different kind of problem and a different kind of flag. Using NumberOfProcessors but not having it control anything except is_MP just seems wrong - and using it to replace available_processors is not a complex change. >> >> The VM is not designed for dynamic adaptation of threads/pools so if the number of processors does change dynamically neither of the above options are going to provide solutions to the potential performance problems that will be encountered (too many or too few threads). Any apps that starts on single core (as reported by the OS) is going to be under-provisioned. >> >> David >> ----- >> > I think this is only a workaround and not a solution for the specific use case, or there is no perfect solution for it. If customers decided to use this flag, they should be aware that they are ready not to consider performance at first. For using number of available processors, we need to add code to get that number, not the one in hotspot os::active_processor_count() which will return the number of live processors. So do you think I could just use a flag -XX:+AssumeMP work around this problem? Since GC threads will not be based on this assumption, I agree (Harold pointed this out either) that one flag is simpler. In fact, the code for is_MP() is obsolete for today's computers, all with multi-cores (even for cell chips) so I think better solution is remove call to is_MP() in all places in hotspot. I will prepare another webrev with -XX:+AssumeMP for next codereview. > > For number of GC Threads: > unsigned int Abstract_VM_Version::nof_parallel_worker_threads( > unsigned int num, > unsigned int den, > unsigned int switch_pt) { > if (FLAG_IS_DEFAULT(ParallelGCThreads)) { > assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not 0"); > // For very large machines, there are diminishing returns > // for large numbers of worker threads. Instead of > // hogging the whole system, use a fraction of the workers for every > // processor after the first 8. For example, on a 72 cpu machine > // and a chosen fraction of 5/8 > // use 8 + (72 - 8) * (5/8) == 48 worker threads. > unsigned int ncpus = (unsigned int) os::active_processor_count(); > return (ncpus <= switch_pt) ? > ncpus : > (switch_pt + ((ncpus - switch_pt) * num) / den); > } else { > return ParallelGCThreads; > } > } > > the call to this function is > unsigned int Abstract_VM_Version::calc_parallel_worker_threads() { > return nof_parallel_worker_threads(5, 8, 8); > } > > We can see that, if active_processor_count is 1, it will return 1, and the VM will run with single GC thread. So the better choices maybe: > > 1) get processor count not active processor count for ParallelGCThreads, that is up to decision from GC team. > 2) Recommend usage is > > -XX:+AssumeMP -XX:ParallelGCThreads= > > Thanks > Yumin > >>> 2178143: VM crashes if the number of bound CPUs changed during runtime. >>> >>> Situation: Customer first configure only one CPU online and turn others >>> offline to run java application, after java program started, bring more >>> CPUs back online. Since VM started on a single CPU, os::is_MP() will >>> return false, but after more CPUs available, OS will schedule the app >>> run on multiple CPUs, this caused SEGV in various places where data >>> consistency was broken. The solution is supply a flag to assume it is >>> running on MP, so lock is forced to be called. >>> >>> http://cr.openjdk.java.net/~minqi/2178143/ >>> >>> Thanks >>> Yumin > From jon.masamitsu at oracle.com Thu Mar 21 15:43:55 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 21 Mar 2013 08:43:55 -0700 Subject: RFR: 8000754: NPG: Implement a MemoryPool MXBean for Metaspace In-Reply-To: <512E3D5E.6010200@oracle.com> References: <5124AD41.2060307@oracle.com> <5124C4C0.9060607@oracle.com> <5124FFBA.90004@oracle.com> <512E3D5E.6010200@oracle.com> Message-ID: <514B2ABB.9060505@oracle.com> Erik, All the changes look good. I've cleared up some of my own confusion about the capacity calculations and any lingering performance concerns will be dealt with separately. Ship it. Jon On 02/27/13 09:07, Erik Helin wrote: > Jon, > > On 02/20/2013 05:54 PM, Jon Masamitsu wrote: >> >> On 2/20/2013 4:42 AM, Stefan Karlsson wrote: >>> Hi Erik, >>> >>> This fix seems reasonable to me. >>> >>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/src/share/vm/services/memoryPool.cpp.udiff.html >>> >>> >>> >>> +MemoryUsage MetaspacePoolBase::get_memory_usage() { >>> + size_t used = MetaspaceAux::used_in_bytes(_md_type); >>> + size_t committed = MetaspaceAux::capacity_in_bytes(_md_type); >>> + return MemoryUsage(initial_size(), used, committed, max_size()); >>> +} >>> >>> I'm not sure if capacity is the right value to use for committed, so >>> you'll need to verify that with Jon. >> >> In general we only commit memory when we allocate a chunk for that >> memory so this is mostly correct. The exception is that the >> allocation of >> a chunk smaller than a page can will cause more than the chunk size to >> be committed. I think this is the right value to use modulo a page >> size. > > I have changed the code to: > > size_t committed = > align_size_down_(MetaspaceAux::capacity_in_bytes(_md_type), > os::vm_page_size()); > > Is that what you meant? > > A new webrev can be found at: > http://cr.openjdk.java.net/~ehelin/8000754/webrev.02/ > > Thanks, > Erik > >> Jon >>> >>> thanks, >>> StefanK >>> >>> On 02/20/2013 12:02 PM, Erik Helin wrote: >>>> Hi, >>>> >>>> this change implements a new MemoryManagerMXBean, MetaspaceManager, as >>>> well as two new MemoryPoolMXBeans: Metaspace and Class Metaspace. I >>>> have >>>> also written a tests that tests the new beans. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000754 >>>> >>>> Testing: >>>> JPRT >>>> New jtreg test >>>> >>>> Thanks, >>>> Erik >>> >> > From erik.helin at oracle.com Thu Mar 21 15:47:23 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 21 Mar 2013 16:47:23 +0100 Subject: RFR: 8000754: NPG: Implement a MemoryPool MXBean for Metaspace In-Reply-To: <514B2ABB.9060505@oracle.com> References: <5124AD41.2060307@oracle.com> <5124C4C0.9060607@oracle.com> <5124FFBA.90004@oracle.com> <512E3D5E.6010200@oracle.com> <514B2ABB.9060505@oracle.com> Message-ID: <514B2B8B.3080003@oracle.com> Thanks! Erik On 03/21/2013 04:43 PM, Jon Masamitsu wrote: > Erik, > > All the changes look good. I've cleared up > some of my own confusion about the capacity > calculations and any lingering performance > concerns will be dealt with separately. > Ship it. > > Jon > > On 02/27/13 09:07, Erik Helin wrote: >> Jon, >> >> On 02/20/2013 05:54 PM, Jon Masamitsu wrote: >>> >>> On 2/20/2013 4:42 AM, Stefan Karlsson wrote: >>>> Hi Erik, >>>> >>>> This fix seems reasonable to me. >>>> >>>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/src/share/vm/services/memoryPool.cpp.udiff.html >>>> >>>> >>>> >>>> +MemoryUsage MetaspacePoolBase::get_memory_usage() { >>>> + size_t used = MetaspaceAux::used_in_bytes(_md_type); >>>> + size_t committed = MetaspaceAux::capacity_in_bytes(_md_type); >>>> + return MemoryUsage(initial_size(), used, committed, max_size()); >>>> +} >>>> >>>> I'm not sure if capacity is the right value to use for committed, so >>>> you'll need to verify that with Jon. >>> >>> In general we only commit memory when we allocate a chunk for that >>> memory so this is mostly correct. The exception is that the >>> allocation of >>> a chunk smaller than a page can will cause more than the chunk size to >>> be committed. I think this is the right value to use modulo a page >>> size. >> >> I have changed the code to: >> >> size_t committed = >> align_size_down_(MetaspaceAux::capacity_in_bytes(_md_type), >> os::vm_page_size()); >> >> Is that what you meant? >> >> A new webrev can be found at: >> http://cr.openjdk.java.net/~ehelin/8000754/webrev.02/ >> >> Thanks, >> Erik >> >>> Jon >>>> >>>> thanks, >>>> StefanK >>>> >>>> On 02/20/2013 12:02 PM, Erik Helin wrote: >>>>> Hi, >>>>> >>>>> this change implements a new MemoryManagerMXBean, MetaspaceManager, as >>>>> well as two new MemoryPoolMXBeans: Metaspace and Class Metaspace. I >>>>> have >>>>> also written a tests that tests the new beans. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000754 >>>>> >>>>> Testing: >>>>> JPRT >>>>> New jtreg test >>>>> >>>>> Thanks, >>>>> Erik >>>> >>> >> From yumin.qi at oracle.com Thu Mar 21 15:56:14 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 21 Mar 2013 08:56:14 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <3DC21326-1500-4315-8C8A-2D345E191016@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> <514A8E71.10105@oracle.com> <3DC21326-1500-4315-8C8A-2D345E191016@oracle.com> Message-ID: <514B2D9E.6000804@oracle.com> Karen, The problem may not look like the is_MP problem, I rechecked the code: // Interface for detecting multiprocessor system static inline bool is_MP() { assert(_processor_count > 0, "invalid processor count"); return _processor_count > 1; } The _processor_count is calculated in initialization: 1) BSD: if (sysctl(mib, 2, &cpu_val, &len, NULL, 0) != -1 && cpu_val >= 1) { assert(len == sizeof(cpu_val), "unexpected data size"); set_processor_count(cpu_val); } else { set_processor_count(1); // fallback } 2) Linux: set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); if (processor_count() == 1) { pid_t pid = os::Linux::gettid(); char fname[32]; jio_snprintf(fname, sizeof(fname), "/proc/%d", pid); FILE *fp = fopen(fname, "r"); if (fp == NULL) { unsafe_chroot_detected = true; } else { fclose(fp); } } 3) Solaris: void os::Solaris::initialize_system_info() { set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); _processors_online = sysconf (_SC_NPROCESSORS_ONLN); _physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE); } sysconf(_SC_NPROCESSORS_CONF) will return number of CPUs not the number of online. That is, it does not relate to user configuration of cpus online/offline. It always returns the real number of processors. If the system equipped with multiple processors, is_MP() will always be true or it will be false for a single CPU. Any how, we will not escape from this call. Am I right here? If so, the problem is not caused by is_MP(), must be somewhere else. BTW, it should use processor_count() function to instead of _processor_count. Let compiler to do the optimization. Thanks Yumin On 3/21/2013 6:54 AM, Karen Kinnear wrote: > Yumin, > > I really like the suggestion from David and from Harold that we simplify this fix to just be a boolean - isMP, and limit the scope of > the change to isMP. It won't change the number of processors, and won't tune everything in the libraries etc. according to actual cpus or > processors sets. The original goal was to allow folks to get the MP locking even if there is only one processor when the vm starts up. > Let's scale back to that if you don't mind. > > thanks, > Karen > > On Mar 21, 2013, at 12:37 AM, Yumin Qi wrote: > >> Hi, David >> >> On 3/20/2013 6:02 PM, David Holmes wrote: >>> On 21/03/2013 7:27 AM, Yumin Qi wrote: >>>> Hi, can I have your code review of a small change? >>> Not really small conceptually. :) >>> >>> I don't think this form of the fix addresses the underlying issue as discussed in the bug report. If the variable was renamed MinimumNumberOfProcessors, or MinimumAssumedProcessors, then simply using it to turn on is_MP would be okay. Such a flag would suit the initial problem perfectly. Of course any value >2 would be semantically indistinct, so this really acts as a boolean flag - AssumeMP. >>> >>> The more general NumberOfProcessors approach, which I'm still unsure of, should to me control what is reported for available-processors. That way it would affect everything in the VM, libraries and application code that configures itself based on the number of available processors. The main usecase for that, in my opinion, would be for apps running on large systems but you want to constrain it to using a subset of the physical CPUs (without having to configure processor sets). That is a different kind of problem and a different kind of flag. Using NumberOfProcessors but not having it control anything except is_MP just seems wrong - and using it to replace available_processors is not a complex change. >>> >>> The VM is not designed for dynamic adaptation of threads/pools so if the number of processors does change dynamically neither of the above options are going to provide solutions to the potential performance problems that will be encountered (too many or too few threads). Any apps that starts on single core (as reported by the OS) is going to be under-provisioned. >>> >>> David >>> ----- >>> >> I think this is only a workaround and not a solution for the specific use case, or there is no perfect solution for it. If customers decided to use this flag, they should be aware that they are ready not to consider performance at first. For using number of available processors, we need to add code to get that number, not the one in hotspot os::active_processor_count() which will return the number of live processors. So do you think I could just use a flag -XX:+AssumeMP work around this problem? Since GC threads will not be based on this assumption, I agree (Harold pointed this out either) that one flag is simpler. In fact, the code for is_MP() is obsolete for today's computers, all with multi-cores (even for cell chips) so I think better solution is remove call to is_MP() in all places in hotspot. I will prepare another webrev with -XX:+AssumeMP for next codereview. >> >> For number of GC Threads: >> unsigned int Abstract_VM_Version::nof_parallel_worker_threads( >> unsigned int num, >> unsigned int den, >> unsigned int switch_pt) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { >> assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not 0"); >> // For very large machines, there are diminishing returns >> // for large numbers of worker threads. Instead of >> // hogging the whole system, use a fraction of the workers for every >> // processor after the first 8. For example, on a 72 cpu machine >> // and a chosen fraction of 5/8 >> // use 8 + (72 - 8) * (5/8) == 48 worker threads. >> unsigned int ncpus = (unsigned int) os::active_processor_count(); >> return (ncpus <= switch_pt) ? >> ncpus : >> (switch_pt + ((ncpus - switch_pt) * num) / den); >> } else { >> return ParallelGCThreads; >> } >> } >> >> the call to this function is >> unsigned int Abstract_VM_Version::calc_parallel_worker_threads() { >> return nof_parallel_worker_threads(5, 8, 8); >> } >> >> We can see that, if active_processor_count is 1, it will return 1, and the VM will run with single GC thread. So the better choices maybe: >> >> 1) get processor count not active processor count for ParallelGCThreads, that is up to decision from GC team. >> 2) Recommend usage is >> >> -XX:+AssumeMP -XX:ParallelGCThreads= >> >> Thanks >> Yumin >> >>>> 2178143: VM crashes if the number of bound CPUs changed during runtime. >>>> >>>> Situation: Customer first configure only one CPU online and turn others >>>> offline to run java application, after java program started, bring more >>>> CPUs back online. Since VM started on a single CPU, os::is_MP() will >>>> return false, but after more CPUs available, OS will schedule the app >>>> run on multiple CPUs, this caused SEGV in various places where data >>>> consistency was broken. The solution is supply a flag to assume it is >>>> running on MP, so lock is forced to be called. >>>> >>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>> >>>> Thanks >>>> Yumin From mikael.gerdin at oracle.com Thu Mar 21 16:24:47 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 21 Mar 2013 17:24:47 +0100 Subject: RFR (S) 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine Message-ID: <514B344F.9080307@oracle.com> Hi Please review the following change: When running a stress test that is repeatedly blocking GC from triggering through the normal path we may get stuck in the allocation path and stay in the allocation loop forever. In this case the problem seems to be that if some threads are repeatedly entering and leaving JNI critical regions and thereby stressing the GC_Locker an allocating thread may get stuck in the allocation loop and never realize that the pending allocation is impossible due to heap usage. My suggested fix is to limit the amount of times we try to start GCs and then simply give up and return NULL and fail the allocation, thereby causing the caller to throw an OOME. Note that every time the counter is incremented because we return from GC_Locker::stall_until_clear() the thread unlocking the GC_Locker has actually triggered a GC. So we're not giving up without a fight. Public bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014552 JIRA: https://jbs.oracle.com/bugs/browse/JDK-7014552 Webrev: http://cr.openjdk.java.net/~mgerdin/7014552/webrev.0/ Thanks /Mikael From tao.mao at oracle.com Thu Mar 21 17:39:44 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 21 Mar 2013 10:39:44 -0700 Subject: Request for review: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp In-Reply-To: <1363857731.2658.16.camel@cirrus> References: <5137C2EB.9090907@oracle.com> <5137C43A.2040709@oracle.com> <5138BC9D.1010702@oracle.com> <5139022B.4070209@oracle.com> <51426E1F.5000304@oracle.com> <51434E5F.8080709@oracle.com> <1363610981.2603.42.camel@cirrus> <514760D9.300@oracle.com> <1363855466.2658.15.camel@cirrus> <514ACF33.6060400@oracle.com> <1363857731.2658.16.camel@cirrus> Message-ID: <514B45E0.1010306@oracle.com> Thank you, Thomas. I'll push it today. Tao On 3/21/2013 2:22 AM, Thomas Schatzl wrote: > Hi, > > On Thu, 2013-03-21 at 10:13 +0100, Jesper Wilhelmsson wrote: >> Thomas, >> >> JFYI, >> Each change needs two reviewers, but only one of them have to be an official >> Reviewer, so your review counts as one. > Thanks for the information, didn't know. > > Thomas > > From david.holmes at oracle.com Thu Mar 21 21:05:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Mar 2013 07:05:51 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514B2D9E.6000804@oracle.com> References: <514A29BC.7040105@oracle.com> <514A5C3A.4040401@oracle.com> <514A8E71.10105@oracle.com> <3DC21326-1500-4315-8C8A-2D345E191016@oracle.com> <514B2D9E.6000804@oracle.com> Message-ID: <514B762F.8070102@oracle.com> Yumin, The problem is environments where the number of configured CPUs changes not the online CPUs. Try using Solaris zones and dynamically changing the number of CPUs for the zone. If you start with one CPU then the VM stores 1 in _processor_count and forever thereafter is_MP() returns false. But the number of CPUs available can be increased and so we crash due to missing memory barriers etc. David On 22/03/2013 1:56 AM, Yumin Qi wrote: > Karen, > > The problem may not look like the is_MP problem, I rechecked the code: > > // Interface for detecting multiprocessor system > static inline bool is_MP() { > assert(_processor_count > 0, "invalid processor count"); > return _processor_count > 1; > } > > The _processor_count is calculated in initialization: > > 1) BSD: > if (sysctl(mib, 2, &cpu_val, &len, NULL, 0) != -1 && cpu_val >= 1) { > assert(len == sizeof(cpu_val), "unexpected data size"); > set_processor_count(cpu_val); > } > else { > set_processor_count(1); // fallback > } > > 2) Linux: > set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); > if (processor_count() == 1) { > pid_t pid = os::Linux::gettid(); > char fname[32]; > jio_snprintf(fname, sizeof(fname), "/proc/%d", pid); > FILE *fp = fopen(fname, "r"); > if (fp == NULL) { > unsafe_chroot_detected = true; > } else { > fclose(fp); > } > } > > 3) Solaris: > void os::Solaris::initialize_system_info() { > set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); > _processors_online = sysconf (_SC_NPROCESSORS_ONLN); > _physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * > (julong)sysconf(_SC_PAGESIZE); > } > > sysconf(_SC_NPROCESSORS_CONF) will return number of CPUs not the number > of online. > > That is, it does not relate to user configuration of cpus > online/offline. It always returns the real number of processors. If the > system equipped with multiple processors, is_MP() will always be true or > it will be false for a single CPU. Any how, we will not escape from this > call. Am I right here? If so, the problem is not caused by is_MP(), must > be somewhere else. > > BTW, it should use processor_count() function to instead of > _processor_count. Let compiler to do the optimization. > > Thanks > Yumin > > > > > On 3/21/2013 6:54 AM, Karen Kinnear wrote: >> Yumin, >> >> I really like the suggestion from David and from Harold that we >> simplify this fix to just be a boolean - isMP, and limit the scope of >> the change to isMP. It won't change the number of processors, and >> won't tune everything in the libraries etc. according to actual cpus or >> processors sets. The original goal was to allow folks to get the MP >> locking even if there is only one processor when the vm starts up. >> Let's scale back to that if you don't mind. >> >> thanks, >> Karen >> >> On Mar 21, 2013, at 12:37 AM, Yumin Qi wrote: >> >>> Hi, David >>> >>> On 3/20/2013 6:02 PM, David Holmes wrote: >>>> On 21/03/2013 7:27 AM, Yumin Qi wrote: >>>>> Hi, can I have your code review of a small change? >>>> Not really small conceptually. :) >>>> >>>> I don't think this form of the fix addresses the underlying issue as >>>> discussed in the bug report. If the variable was renamed >>>> MinimumNumberOfProcessors, or MinimumAssumedProcessors, then simply >>>> using it to turn on is_MP would be okay. Such a flag would suit the >>>> initial problem perfectly. Of course any value >2 would be >>>> semantically indistinct, so this really acts as a boolean flag - >>>> AssumeMP. >>>> >>>> The more general NumberOfProcessors approach, which I'm still unsure >>>> of, should to me control what is reported for available-processors. >>>> That way it would affect everything in the VM, libraries and >>>> application code that configures itself based on the number of >>>> available processors. The main usecase for that, in my opinion, >>>> would be for apps running on large systems but you want to constrain >>>> it to using a subset of the physical CPUs (without having to >>>> configure processor sets). That is a different kind of problem and a >>>> different kind of flag. Using NumberOfProcessors but not having it >>>> control anything except is_MP just seems wrong - and using it to >>>> replace available_processors is not a complex change. >>>> >>>> The VM is not designed for dynamic adaptation of threads/pools so if >>>> the number of processors does change dynamically neither of the >>>> above options are going to provide solutions to the potential >>>> performance problems that will be encountered (too many or too few >>>> threads). Any apps that starts on single core (as reported by the >>>> OS) is going to be under-provisioned. >>>> >>>> David >>>> ----- >>>> >>> I think this is only a workaround and not a solution for the specific >>> use case, or there is no perfect solution for it. If customers >>> decided to use this flag, they should be aware that they are ready >>> not to consider performance at first. For using number of available >>> processors, we need to add code to get that number, not the one in >>> hotspot os::active_processor_count() which will return the number of >>> live processors. So do you think I could just use a flag >>> -XX:+AssumeMP work around this problem? Since GC threads will not be >>> based on this assumption, I agree (Harold pointed this out either) >>> that one flag is simpler. In fact, the code for is_MP() is obsolete >>> for today's computers, all with multi-cores (even for cell chips) so >>> I think better solution is remove call to is_MP() in all places in >>> hotspot. I will prepare another webrev with -XX:+AssumeMP for next >>> codereview. >>> >>> For number of GC Threads: >>> unsigned int Abstract_VM_Version::nof_parallel_worker_threads( >>> unsigned int num, >>> unsigned int den, >>> unsigned int >>> switch_pt) { >>> if (FLAG_IS_DEFAULT(ParallelGCThreads)) { >>> assert(ParallelGCThreads == 0, "Default ParallelGCThreads is not >>> 0"); >>> // For very large machines, there are diminishing returns >>> // for large numbers of worker threads. Instead of >>> // hogging the whole system, use a fraction of the workers for every >>> // processor after the first 8. For example, on a 72 cpu machine >>> // and a chosen fraction of 5/8 >>> // use 8 + (72 - 8) * (5/8) == 48 worker threads. >>> unsigned int ncpus = (unsigned int) os::active_processor_count(); >>> return (ncpus <= switch_pt) ? >>> ncpus : >>> (switch_pt + ((ncpus - switch_pt) * num) / den); >>> } else { >>> return ParallelGCThreads; >>> } >>> } >>> >>> the call to this function is >>> unsigned int Abstract_VM_Version::calc_parallel_worker_threads() { >>> return nof_parallel_worker_threads(5, 8, 8); >>> } >>> >>> We can see that, if active_processor_count is 1, it will return 1, >>> and the VM will run with single GC thread. So the better choices maybe: >>> >>> 1) get processor count not active processor count for >>> ParallelGCThreads, that is up to decision from GC team. >>> 2) Recommend usage is >>> >>> -XX:+AssumeMP -XX:ParallelGCThreads= >>> >>> Thanks >>> Yumin >>> >>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>> runtime. >>>>> >>>>> Situation: Customer first configure only one CPU online and turn >>>>> others >>>>> offline to run java application, after java program started, bring >>>>> more >>>>> CPUs back online. Since VM started on a single CPU, os::is_MP() will >>>>> return false, but after more CPUs available, OS will schedule the app >>>>> run on multiple CPUs, this caused SEGV in various places where data >>>>> consistency was broken. The solution is supply a flag to assume it is >>>>> running on MP, so lock is forced to be called. >>>>> >>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>> >>>>> Thanks >>>>> Yumin > From tao.mao at oracle.com Thu Mar 21 22:09:16 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 21 Mar 2013 15:09:16 -0700 Subject: Request for review: 8010506 Typos and errors in gc-related flags in globals.hpp Message-ID: <514B850C.7050709@oracle.com> 8010506 Typos and errors in gc-related flags in globals.hpp https://jbs.oracle.com/bugs/browse/JDK-8010506 webrev: http://cr.openjdk.java.net/~tamao/8010506/webrev.00/ Changeset: NewRatio should defined as product(uintx, NewRatio, 2, \ "Ratio of old/new generation sizes") \ instead of product(uintx, NewRatio, 2, \ "Ratio of new/old generation sizes") \ PLUS other typos found by Jesper. From john.cuthbertson at oracle.com Thu Mar 21 22:28:38 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 21 Mar 2013 15:28:38 -0700 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification Message-ID: <514B8996.8030909@oracle.com> Hi Everyone, I'm looking for a couple of reviews for the fix for these crashes. The webrev can be found at: http://cr.openjdk.java.net/~johnc/8010463/webrev.0/ Summary: During JVM start up, with TLABs disabled, the JVM performs three separate verifications. The first is in universe2_init(), the second is in init_globals(), and the final one is in Threads::create_vm(). With TLABs enabled only one verification is performed during start up - the one in Threads::create_vm(). These verifications are invoked by the main thread. The problem here was that the G1 verification code was expecting to be invoked by the VMThread, at a safepoint. When TLABs are disabled the verification code was executed by main thread, triggering the assert. Relaxing the assert (to allow for execution during VM start up) is, unfortunately, not a good solution. There are parts of the root scanning code which assume the JVM is at a safepoint or has completed initialization. For example Threads::oops_do() assumes that the VMThread exists; CodeCache::oops_do() assumes that the CodeCache_lock is being held (or the JVM is at a safepoint); verifying G1's region sets assumes that the Heap_lock is being held (or the JVM is at a safepoint); etc. When TLABs are enabled the verification from Threads::create_vm() skips verifying parts of the heap. The solution is to skip those parts of the verification even if TLABs are disabled. With just the changes in g1CollectedHeap.cpp, we would see the following: With -UseTLABS: > ----> universe2_init > [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, > remset) syms strs zone dict cldg metaspace chunks hand C-heap code cache ] > <---- universe2_init > ---->init::verify > [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, > remset) syms strs zone dict cldg metaspace chunks hand C-heap code cache ] > <----init::verify > --->create_vm:verify > [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, > remset) syms strs zone dict cldg metaspace chunks hand C-heap code cache ] > <---create_vm:verify With +UseTLABS: > ----> universe2_init > <---- universe2_init > ---->init::verify > <----init::verify > --->create_vm:verify > [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, > remset) syms strs zone dict cldg metaspace chunks hand C-heap code cache ] > <---create_vm:verify Why do we perform two additional verifications when TLABs are disabled? I've removed these in this fix. If someone can provide a reasonable justification, I'll add them back. Additionally I've moved the verification code in Threads::create_vm() to after the VMThread is created. That way, as a future enhancement, the verification could be wrapped inside a VMOperation. I've also included a regression test. Testing: The failing test case with G1 with and without TLABs enabled. The regression test with all the collectors. A jprt run (with -UseTLABS -XX:+VerifyBeforeGC) is in the queue. Thanks, JohnC From tao.mao at oracle.com Thu Mar 21 22:42:15 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 21 Mar 2013 15:42:15 -0700 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <1363593549.2603.1.camel@cirrus> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> <1363593549.2603.1.camel@cirrus> Message-ID: <514B8CC7.7060607@oracle.com> On 3/18/13 12:59 AM, Thomas Schatzl wrote: > Hi all, > > here is a new webrev for this issue. Changes are: > > - merged code for os::has_allocatable_memory_limit of linux/bsd/solaris > into a single method. So, where is the merged routine now? > - on 32 bit targets that method now tries to find the maximum > allocatable virtual memory limit by performing a binary search. In this > search, the method tries to find the largest allocatable block of > memory, and returns this size as limit. > It uses a binary search to do this. The old mechanism relied on some > manually determined number (2*G - 2*LargePageSize) > - fixed the description of MaxVirtMemFraction > - rename Arguments::allocatable_physical_memory() to > limit_by_allocatable_memory(). > - the argument of os::has_allocatable_memory_limit() is now passed as > address. > - removed some obsolete comment > > Tests: JPRT, manual testing on linux 32/64 bit, BSD 64 bit, Windows > 32/64 bit. Additional manual testing targeted at the maximum memory > limit search on linux 32 bit. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/7112912/webrev.1/ > > CR: > http://bugs.sun.com/view_bug.do?bug_id=7112912 > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-7112912 > > Thanks, > Thomas > > > From john.cuthbertson at oracle.com Thu Mar 21 23:16:01 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 21 Mar 2013 16:16:01 -0700 Subject: RFR: Adding evacuation failed tracing event In-Reply-To: <514A4A73.6080704@oracle.com> References: <514A4A73.6080704@oracle.com> Message-ID: <514B94B1.2060503@oracle.com> Hi Jesper, I've only looked at the first set of changes. I'll look at the second set later tonight or tomorrow. On 3/20/2013 4:46 PM, Jesper Wilhelmsson wrote: > Hi, > > I'm looking for a couple of reviews for this change. > > The change is to add evacuation failed tracing events to G1. Since the > evacuation failed is very similar to a regular promotion failed in > other young GCs, these events share most of the code. > > I have split the change into two parts: > > > 1) JDK-8009992: Prepare tracing of promotion failed for integration of > evacuation failed > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8009992/webrev/ > > This part refactors the promotion failed code to use a generic copy > failed class which is used as the base for the promotion failed handling. Looks good. Just one nit: || _src/share/vm/gc_implementation/shared/gcTraceSend.cpp_ > 95 static TraceStructCopyFailed to_trace_struct(const CopyFailedInfo& cf_info) { > 96 TraceStructCopyFailed failed_info; > 97 failed_info.set_objectCount(cf_info.failed_count()); > 98 failed_info.set_firstSize(cf_info.first_size()); > 99 failed_info.set_smallestSize(cf_info.smallest_size()); > 100 failed_info.set_totalSize(cf_info.total_size()); > 101 failed_info.set_thread(cf_info.thread()->thread_id()); > 102 return failed_info; > 103 } > 104 > 105 void YoungGCTracer::send_promotion_failed_event(const PromotionFailedInfo& pf_info) const { > 106 EventPromotionFailed e; > 107 if (e.should_commit()) { > 108 e.set_gcId(_shared_gc_info.id()); > 109 e.set_data(to_trace_struct(pf_info)); > 110 e.commit(); > 111 } > 112 } Won't this result in executing the copy constructors of TraceStructCopyFailed multiple times? (One in the return from to_trace_struct() and one in set_data().) Would it not be more efficient to return the address of the struct in the EventPromotionFailed, i.e. to_trace_struct(e.data_addr(), pf_info); where to_trace_struct() is: void to_trace_struct(TraceStructCopyFailed* dest_data, const CopyFailedInfo& cf_info) { dest_data->set_objectCount(cf_info.failed_count()); ... } Other than that. It looks OK to me. Now on to the other one. JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Thu Mar 21 23:23:26 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 21 Mar 2013 16:23:26 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() Message-ID: <514B966E.4060706@oracle.com> A simple changeset. Need a reviewer! 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() https://jbs.oracle.com/bugs/browse/JDK-8010518 webrev: http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ changeset: Cleanup suggested by Bengt. From bengt.rutisson at oracle.com Fri Mar 22 04:18:59 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 22 Mar 2013 05:18:59 +0100 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514B966E.4060706@oracle.com> References: <514B966E.4060706@oracle.com> Message-ID: <514BDBB3.7060005@oracle.com> Hi Tao, The change looks good. The bug report is a little sparse on information - it basically just contains the title. I think it could be worth adding a line about why we want to do this and maybe also comment on why you update the message for MaxGCMinorPauseMillis. Something like: "When Arguments::check_deprecated_gcs() was added the check for the use of the deprecated flag CMSIncrementalMode was included there. Later the Arguments::check_deprecated_gc_flags() method was added. Since the CMSIncrementalMode is just a flag it seems more logical to check it in Arguments::check_deprecated_gc_flags() than in Arguments::check_deprecated_gcs()." You can probably come up with a short comment on the MaxGCMinorPauseMillis message update. This was not suggested by me, so I'll let you figure something out ;) Bengt On 3/22/13 12:23 AM, Tao Mao wrote: > A simple changeset. Need a reviewer! > > 8010518 Move deprecating CMSIncrementalMode from > Arguments::check_deprecated_gcs() to > Arguments::check_deprecated_gc_flags() > https://jbs.oracle.com/bugs/browse/JDK-8010518 > > webrev: > http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ > > changeset: > Cleanup suggested by Bengt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Fri Mar 22 06:41:58 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 22 Mar 2013 07:41:58 +0100 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <514B8CC7.7060607@oracle.com> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> <1363593549.2603.1.camel@cirrus> <514B8CC7.7060607@oracle.com> Message-ID: <1363934518.2463.48.camel@cirrus> On Thu, 2013-03-21 at 15:42 -0700, Tao Mao wrote: > > On 3/18/13 12:59 AM, Thomas Schatzl wrote: > > Hi all, > > > > here is a new webrev for this issue. Changes are: > > > > - merged code for os::has_allocatable_memory_limit of linux/bsd/solaris > > into a single method. > So, where is the merged routine now? Simply put into os_posix.cpp. (http://cr.openjdk.java.net/~tschatzl/7112912/webrev.1/src/os/posix/vm/os_posix.cpp.udiff.html) This is similar to other OS methods shared by all Unix OSes, so that it is found during compilation in all these OSes. Ie. this follows current standards in that respect. As mentioned, the OS class is currently being refactored where inheritance instead of #include is used to share functionality with all OSes. At least I think this is the currently agreed upon approach by the runtime team as far as I could understand. Thanks, Thomas From bengt.rutisson at oracle.com Fri Mar 22 06:48:44 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 22 Mar 2013 07:48:44 +0100 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <514B8996.8030909@oracle.com> References: <514B8996.8030909@oracle.com> Message-ID: <514BFECC.8070206@oracle.com> Hi John, Your changes look good to me. I think your motivation for removing the verification from universe2_init() and init_globals() is fine. Actually I wonder why they were there in the first place, but they do seem intentionally put in there. However, I'm fine with removing them. About the test. Great that you write a regression test for this! :) The @summary says that the test uses -XX:+VerifyDuringGC but the command line is actually using -XX:+VerifyBeforeGC (which is correct, I think). Also, would it make sense to have a separate test that specifies -XX:+UseG1GC and checks the output that we expect to see? One question that is not strictly related to your change: The code to do the verification in Threads::create_vm() is: 3449 if (VerifyBeforeGC && 3450 Universe::heap()->total_collections() >= VerifyGCStartAt) { 3451 Universe::heap()->prepare_for_verify(); 3452 Universe::verify(); // make sure we're starting with a clean slate 3453 } This is what it looked like before your change as well. But to me this looks kind of odd. First, we re-use the flag VerifyBeforeGC even though we are not about to do a GC. I can live with that, but it is kind of strange. Then we have the check against VerifyGCStartAt. By default this is 0 so we will do the verification. But why do we do this check? There is no chance that we have been able to do any GC yet, right? So, checking against Universe::heap()->total_collections() seems unnecessary. We should either check VerifyGCStartAt == 0 or not include that flag at all (best choice in my opinion). Thanks, Bengt On 3/21/13 11:28 PM, John Cuthbertson wrote: > Hi Everyone, > > I'm looking for a couple of reviews for the fix for these crashes. The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/8010463/webrev.0/ > > Summary: > During JVM start up, with TLABs disabled, the JVM performs three > separate verifications. The first is in universe2_init(), the second > is in init_globals(), and the final one is in Threads::create_vm(). > With TLABs enabled only one verification is performed during start up > - the one in Threads::create_vm(). These verifications are invoked by > the main thread. > > The problem here was that the G1 verification code was expecting to be > invoked by the VMThread, at a safepoint. When TLABs are disabled the > verification code was executed by main thread, triggering the assert. > Relaxing the assert (to allow for execution during VM start up) is, > unfortunately, not a good solution. There are parts of the root > scanning code which assume the JVM is at a safepoint or has completed > initialization. For example Threads::oops_do() assumes that the > VMThread exists; CodeCache::oops_do() assumes that the CodeCache_lock > is being held (or the JVM is at a safepoint); verifying G1's region > sets assumes that the Heap_lock is being held (or the JVM is at a > safepoint); etc. > > When TLABs are enabled the verification from Threads::create_vm() > skips verifying parts of the heap. The solution is to skip those parts > of the verification even if TLABs are disabled. With just the changes > in g1CollectedHeap.cpp, we would see the following: > > With -UseTLABS: > >> ----> universe2_init >> [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, >> remset) syms strs zone dict cldg metaspace chunks hand C-heap code >> cache ] >> <---- universe2_init >> ---->init::verify >> [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, >> remset) syms strs zone dict cldg metaspace chunks hand C-heap code >> cache ] >> <----init::verify >> --->create_vm:verify >> [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, >> remset) syms strs zone dict cldg metaspace chunks hand C-heap code >> cache ] >> <---create_vm:verify > > With +UseTLABS: > >> ----> universe2_init >> <---- universe2_init >> ---->init::verify >> <----init::verify >> --->create_vm:verify >> [Verifying threads (SKIPPING roots, heapRegionSets, heapRegions, >> remset) syms strs zone dict cldg metaspace chunks hand C-heap code >> cache ] >> <---create_vm:verify > > Why do we perform two additional verifications when TLABs are > disabled? I've removed these in this fix. If someone can provide a > reasonable justification, I'll add them back. > > Additionally I've moved the verification code in Threads::create_vm() > to after the VMThread is created. That way, as a future enhancement, > the verification could be wrapped inside a VMOperation. > > I've also included a regression test. > > Testing: > The failing test case with G1 with and without TLABs enabled. > The regression test with all the collectors. > A jprt run (with -UseTLABS -XX:+VerifyBeforeGC) is in the queue. > > Thanks, > > JohnC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Fri Mar 22 07:06:58 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 22 Mar 2013 11:06:58 +0400 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure In-Reply-To: <5149A89B.9020001@oracle.com> References: <5149A89B.9020001@oracle.com> Message-ID: <514C0312.6000203@oracle.com> Could anyone please review this small test fix. Leonid On 03/20/2013 04:16 PM, Leonid Mesnik wrote: > Hi > > Could you please review fix for 8009808 TEST-BUG : test case is using > bash style tests. Default shell for jtreg is bourne. thus failure. > > I've completely rewritten test in java without major changes it test > logic. > I remove CMS so test could be run when CMS is not supported. Also I > changed max memory to 128M to reduce memory load and increase number > of GC log entries. > > Here is the link: > http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ > > -- Leonid Mesnik JVM SQE From leonid.mesnik at oracle.com Fri Mar 22 07:07:26 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 22 Mar 2013 00:07:26 -0700 (PDT) Subject: RFR: 8009763 Add WB test for String.intern() In-Reply-To: <5149A050.1040301@oracle.com> References: <513ED867.2070902@oracle.com> <513F27FF.5080607@oracle.com> <514051A2.4090800@oracle.com> <5141E0D6.6000800@oracle.com> <5149A050.1040301@oracle.com> Message-ID: <514C032E.1030306@oracle.com> Are there any other comments? Leonid On 03/20/2013 03:41 PM, Leonid Mesnik wrote: > Hi > > Here is next attempt: > http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.2/ > > > The StringTable::lookup methods were updated. > > Leonid > On 03/14/2013 06:38 PM, Mikael Gerdin wrote: >> Lenoid, >> >> On 2013-03-13 11:14, Leonid Mesnik wrote: >>> Hi >>> >>> werbrev was updated (thank you for this) >>> http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.1/ >>> >> >> Also, I don't know why you have "StringTabe::" inside these calls: >> >> unsigned int hash = StringTable::hash_string(name, len); >> unsigned int index = StringTable::the_table()->hash_to_index(hash); >> return StringTable::the_table()->lookup(index, name, len, hash); >> >> Since you are in an instance method in StringTable you also shouldn't >> get the_table() singleton, but rather use the current instance. >> >> >> I think your new lookup() function could be static just as the other >> public lookup() function. >> >> Another idea is to perhaps make these two lookup:s share the same >> implementation: >> >> oop StringTable::lookup(Symbol* symbol) { >> ResourceMark rm; >> int length; >> jchar* chars = symbol->as_unicode(length); >> return lookup(chars, length); >> } >> >> oop StringTable::lookup(const jchar* chars, int length) { >> unsigned int hashValue = hash_string(chars, length); >> int index = the_table()->hash_to_index(hashValue); >> return the_table()->lookup(index, chars, length, hashValue); >> } >> >> /Mikael >> >>> >>> JPRT passed with -rtest '*-*-*-runtime/interned' >>> >>> Leonid >>> On 03/12/2013 05:05 PM, Mikael Gerdin wrote: >>>> Hi Leonid, >>>> >>>> On 2013-03-12 08:25, Leonid Mesnik wrote: >>>>> Hi >>>>> I've added a small test which: >>>>> 1) creates java string and intern it >>>>> 2) verify that it presents in StringTable >>>>> 3) clear reference and call fullGC >>>>> 4) verify that there is no such string in StringTable >>>>> >>>>> Here is webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/webrev.0/ >>>> >>>> Overall this looks reasonable. >>>> >>>> I have some comments though: >>>> WB_IsInStringTable is defined to return a jboolean >>>> (Ljava/lang/String;)Z >>>> but the actual function is defined to return an jint. This will >>>> probably work but you should fix this to make it consistent. >>>> >>>> The function WB_fullGC should have a capital F to be consistent with >>>> the naming of the other WB_* functions. >>>> >>>>> >>>>> Tested locally and by JPRT >>>>> >>>> did you run jprt with -retest '*-*-*-runtime/interned' as well? >>>> >>>> /Mikael >>> >>> > > -- Leonid Mesnik JVM SQE From john.coomes at oracle.com Fri Mar 22 07:28:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 07:28:35 +0000 Subject: hg: hsx/hotspot-gc: 22 new changesets Message-ID: <20130322072836.3803048322@hg.openjdk.java.net> Changeset: 52741ab7c601 Author: erikj Date: 2013-03-06 10:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/52741ab7c601 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 235854886494 Author: katleman Date: 2013-03-11 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/235854886494 Merge Changeset: 145dbc56f931 Author: tbell Date: 2013-03-12 22:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/145dbc56f931 8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Reviewed-by: katleman ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 0dc28db6525f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0dc28db6525f Added tag jdk8-b81 for changeset 145dbc56f931 ! .hgtags Changeset: ecc8fda8f187 Author: darcy Date: 2013-02-19 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/ecc8fda8f187 8008435: Fix new build to include jdk.Supported in ct.sym Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: eca3bce3d151 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/eca3bce3d151 Merge Changeset: c641268c4532 Author: mduigou Date: 2013-02-20 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/c641268c4532 8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com Reviewed-by: darcy ! make/scripts/webrev.ksh Changeset: b70196e01c53 Author: lana Date: 2013-02-21 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b70196e01c53 Merge Changeset: 5b0b6ef58dbf Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/5b0b6ef58dbf 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! Makefile ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/sanity-rules.gmk ! make/scripts/hgforest.sh Changeset: e065107437b9 Author: alanb Date: 2013-02-26 14:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/e065107437b9 8008978: nashorn-rules.gmk missing Reviewed-by: alanb Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com + make/nashorn-rules.gmk Changeset: cb0ac8979caa Author: tbell Date: 2013-02-26 09:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/cb0ac8979caa 8009019: Updates to generated-configure.sh required for 8008914 Reviewed-by: sundar, jlaskey, jjg ! common/autoconf/generated-configure.sh Changeset: a9c8a32d09f9 Author: martin Date: 2013-03-05 13:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a9c8a32d09f9 8006988: build-infra: Configure fails if 'cl' is in path on linux Summary: Respect user CC and CXX environment variables; use cl iff on windows Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: c022bc48b7ed Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/c022bc48b7ed Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: c4901c0e0579 Author: lana Date: 2013-03-05 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/c4901c0e0579 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 929e2461818b Author: dholmes Date: 2013-03-05 22:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/929e2461818b 8009529: Fix for 8006988 missed closed configure changes Reviewed-by: mr ! common/autoconf/generated-configure.sh Changeset: b35d986ff276 Author: mduigou Date: 2013-03-06 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b35d986ff276 8009162: root repo "make test" target should run against image Reviewed-by: alanb, martin, erikj ! common/makefiles/Main.gmk Changeset: 980ccff2d4f5 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/980ccff2d4f5 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 22b9a31a92eb Author: lana Date: 2013-03-13 23:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/22b9a31a92eb Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: a69761ae281b Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a69761ae281b Merge Changeset: e2057191f6da Author: omajid Date: 2013-03-18 10:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/e2057191f6da 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: 29153d0df68f Author: omajid Date: 2013-03-19 11:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/29153d0df68f 8010277: Configure doesn't fail when Xrender.h is missing Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 466685ba01bf Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/466685ba01bf Added tag jdk8-b82 for changeset 29153d0df68f ! .hgtags From john.coomes at oracle.com Fri Mar 22 07:28:42 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 07:28:42 +0000 Subject: hg: hsx/hotspot-gc/corba: 14 new changesets Message-ID: <20130322072852.A3C9F48323@hg.openjdk.java.net> Changeset: 0ac9424678e7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0ac9424678e7 Added tag jdk8-b81 for changeset 2a00aeeb466b ! .hgtags Changeset: e725dd195858 Author: dmeetry Date: 2013-02-15 01:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/e725dd195858 7199858: Marshal exception is wrong Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java Changeset: c528d8ce83f1 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/c528d8ce83f1 Merge Changeset: 67ef27b4e16c Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/67ef27b4e16c Merge Changeset: 05386b4610e9 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/05386b4610e9 Merge Changeset: 3c73273667ae Author: coffeys Date: 2012-10-30 17:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/3c73273667ae 8000631: Restrict access to class constructor Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java + src/share/classes/sun/corba/JavaCorbaAccess.java + src/share/classes/sun/corba/SharedSecrets.java Changeset: 80882eae6279 Author: ngmr Date: 2012-10-30 17:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/80882eae6279 8000540: Improve IIOP type reuse management Reviewed-by: alanb, ahgross, coffeys ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 0ca1fc7c5f44 Author: mbankal Date: 2012-12-17 07:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0ca1fc7c5f44 7141694: Improving CORBA internals Reviewed-by: coffeys, ahgross ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: f4f39d873b9a Author: coffeys Date: 2012-11-06 15:50 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/f4f39d873b9a 7201066: Change modifiers on unused fields Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java Changeset: 59bff16bc0bf Author: ewendeli Date: 2013-02-19 21:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/59bff16bc0bf Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 996bd5fd0941 Author: ewendeli Date: 2013-02-25 07:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/996bd5fd0941 Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 7341134e52ff Author: lana Date: 2013-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/7341134e52ff Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 48e1bc77004d Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/48e1bc77004d Merge Changeset: a45bb25a67c7 Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/a45bb25a67c7 Added tag jdk8-b82 for changeset 48e1bc77004d ! .hgtags From john.coomes at oracle.com Fri Mar 22 07:28:57 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 07:28:57 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 7 new changesets Message-ID: <20130322072921.5A70948324@hg.openjdk.java.net> Changeset: 94000590f01f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/94000590f01f Added tag jdk8-b81 for changeset ef3495555a4c ! .hgtags Changeset: f4898ff0aff1 Author: joehw Date: 2012-12-12 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/f4898ff0aff1 8001235: Improve JAXP HTTP handling Reviewed-by: lancea, skoivu ! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java Changeset: 3206516132e8 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/3206516132e8 Merge Changeset: 46ce56a4e40f Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/46ce56a4e40f Merge Changeset: 8a0cb78fefbc Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/8a0cb78fefbc Merge Changeset: d5a58291f09a Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/d5a58291f09a Merge Changeset: a46d69a1a8ec Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/a46d69a1a8ec Added tag jdk8-b82 for changeset d5a58291f09a ! .hgtags From john.coomes at oracle.com Fri Mar 22 07:29:26 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 07:29:26 +0000 Subject: hg: hsx/hotspot-gc/jaxws: 2 new changesets Message-ID: <20130322072933.3ACC248325@hg.openjdk.java.net> Changeset: d8d8032d02d7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/d8d8032d02d7 Added tag jdk8-b81 for changeset c88bb21560cc ! .hgtags Changeset: a1dcc0d83da1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/a1dcc0d83da1 Added tag jdk8-b82 for changeset d8d8032d02d7 ! .hgtags From john.coomes at oracle.com Fri Mar 22 07:36:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 07:36:11 +0000 Subject: hg: hsx/hotspot-gc/jdk: 171 new changesets Message-ID: <20130322081314.0BAEF48328@hg.openjdk.java.net> Changeset: 758db1c4c65c Author: ehelin Date: 2013-03-04 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/758db1c4c65c 8009384: Temporarily disable jstat tests to ease complicated push Reviewed-by: mchung ! test/ProblemList.txt Changeset: aee1c6c52b68 Author: erikj Date: 2013-03-06 16:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/aee1c6c52b68 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! makefiles/CompileNativeLibraries.gmk Changeset: da8edcfc19af Author: katleman Date: 2013-03-11 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/da8edcfc19af Merge Changeset: bc0ca8bc4637 Author: erikj Date: 2013-03-12 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc0ca8bc4637 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine Reviewed-by: dholmes, tbell ! make/common/shared/Defs-utils.gmk ! makefiles/Images.gmk Changeset: c0f8022eba53 Author: katleman Date: 2013-03-12 19:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c0f8022eba53 Merge Changeset: 509c45748f3e Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/509c45748f3e Added tag jdk8-b81 for changeset c0f8022eba53 ! .hgtags Changeset: f6eb212081b2 Author: jgodinez Date: 2013-02-14 14:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f6eb212081b2 8008173: [parfait] #1173 Uninitialised variable -- TransformHelper.cpp Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 4b11045a9c4c Author: jgodinez Date: 2013-02-18 14:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4b11045a9c4c 8005191: [parfait] #384 sun/font/layout/LookupProcessor.cpp Null pointer dereference Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: 41008f5cef1a Author: lana Date: 2013-02-19 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/41008f5cef1a Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: d2d7da120c37 Author: jgodinez Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d2d7da120c37 8006110: pageDialog is showing the swing dialog with DialogTypeSelection.NATIVE Reviewed-by: bae, prr ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 99c1f910abcc Author: jgodinez Date: 2013-02-22 13:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/99c1f910abcc 8005796: [parfait] Possible uninitialised variable at jdk/src/share/native/sun/java2d/loops/ByteBinary1Bit.c Reviewed-by: prr, vadim, flar Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/AnyByteBinary.h ! src/share/native/sun/java2d/loops/ByteIndexed.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/UshortIndexed.h Changeset: 934f5f10107d Author: lana Date: 2013-02-22 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/934f5f10107d Merge Changeset: 4fd6048a78c0 Author: lana Date: 2013-02-22 23:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4fd6048a78c0 Merge Changeset: f3368a3fc023 Author: bae Date: 2013-03-05 17:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f3368a3fc023 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Reviewed-by: jgodinez, ant ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/classes/sun/font/CStrikeDisposer.java ! src/macosx/native/sun/font/AWTStrike.m Changeset: fd8810d50c99 Author: bae Date: 2013-03-07 14:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fd8810d50c99 8005530: [lcms] Improve performance of ColorConverOp for default destinations Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/Makefile ! make/sun/cmm/lcms/mapfile-vers ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/liblcms/mapfile-vers ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/demo/java2d/J2DBench/build.xml + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_medium.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_small.jpg ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/EmbeddedProfileTests.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 8e9b133dcec9 Author: lana Date: 2013-03-12 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8e9b133dcec9 Merge Changeset: e6c94a202bfd Author: alexsch Date: 2013-02-15 14:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e6c94a202bfd 7173873: JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) will never lead to SE if EXIT_ON_CLOSE is already set Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/JFrame.java Changeset: 4bf242def958 Author: dingxmin Date: 2013-02-15 15:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4bf242def958 8008289: DefaultButtonModel instance keeps stale listeners in html FormView Reviewed-by: malenkov, alexsch ! src/share/classes/javax/swing/text/html/FormView.java + test/javax/swing/text/html/7189299/bug7189299.java Changeset: 88a83b9e9baa Author: kshefov Date: 2013-02-15 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/88a83b9e9baa 8005920: After pressing combination Windows Key and M key, the frame, the instruction and the dialog can't be minimized. Reviewed-by: serb, denis Contributed-by: Vera Akulova ! test/java/awt/Modal/WsDisabledStyle/Winkey/Winkey.java Changeset: 0fe12ecf80b2 Author: pchelko Date: 2013-02-19 11:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0fe12ecf80b2 8008374: Build failure (NEWBUILD=false) on Mac Summary: Fixed an old build system failure Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: 5ad0bd367f6d Author: kshefov Date: 2013-02-19 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5ad0bd367f6d 8008379: TEST_BUG: Fail automatically with java.lang.NullPointerException. Reviewed-by: serb, anthony + test/java/awt/Modal/ModalDialogMultiscreenTest/ModalDialogMultiscreenTest.java Changeset: a43115c6359d Author: kshefov Date: 2013-02-19 20:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a43115c6359d 8006070: TEST_BUG: Up and down the Y coordinate of the mouse position, the selected item doesn't change for the single list. Reviewed-by: serb, anthony + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.html + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.java Changeset: 9bc26b7b8b47 Author: lana Date: 2013-02-19 22:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9bc26b7b8b47 Merge - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: 73d1efc4710a Author: ant Date: 2013-02-22 15:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/73d1efc4710a 8006406: lightweight embedding in other Java UI toolkits Reviewed-by: serb, anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/HToolkit.java + src/share/classes/sun/awt/LightweightFrame.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/classes/sun/swing/JLightweightFrame.java + src/share/classes/sun/swing/LightweightContent.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java + src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_Window.h Changeset: 63bb402d4a6a Author: lana Date: 2013-02-23 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/63bb402d4a6a Merge Changeset: d502cc7bcc3d Author: pchelko Date: 2013-02-25 10:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d502cc7bcc3d 8006634: Unify LWCToolkit.invokeAndWait() and sun.awt.datatransfer.ToolkitThreadBlockedHandler Summary: Changed the logic for the nested event loops and deleted deadlock detection Reviewed-by: art, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuBar.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e58f0b163f43 Author: denis Date: 2013-02-27 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e58f0b163f43 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java Changeset: bc914b7f0878 Author: denis Date: 2013-02-27 20:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc914b7f0878 8009158: Incomplete fix for 7178079 Reviewed-by: serb, anthony ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: 3dee850e2653 Author: serb Date: 2013-02-28 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3dee850e2653 8008660: Failure in 2D Queue Flusher thread on Mac Reviewed-by: swingler, bae ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/LWCToolkit.h ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m Changeset: 554d0f41a6ab Author: serb Date: 2013-02-28 20:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/554d0f41a6ab 8003169: [macosx] JVM crash after disconnecting from projector Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 657a02fcaa00 Author: malenkov Date: 2013-03-01 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/657a02fcaa00 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs Reviewed-by: alexsch ! src/share/classes/java/beans/PropertyDescriptor.java ! test/java/beans/Introspector/Test7192955.java Changeset: 5816595a4cdc Author: serb Date: 2013-03-01 15:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5816595a4cdc 7194902: [macosx] closed/java/awt/Button/DoubleActionEventTest/DoubleActionEventTest failed since jdk8b49 7181403: Invalid MouseEvent conversion with SwingUtilities.convertMouseEvent Reviewed-by: malenkov, alexsch ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 4912a9e3a95e Author: serb Date: 2013-03-01 21:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4912a9e3a95e 7184945: [macosx] NPE in AquaComboBoxUI since jdk7u6b17, jdk8b47 Reviewed-by: malenkov, alexsch ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: 91e17a813483 Author: alexsch Date: 2013-03-06 19:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/91e17a813483 6877495: JTextField and JTextArea does not support supplementary characters Reviewed-by: serb, alexp ! src/share/classes/sun/awt/datatransfer/DataTransferer.java + test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java Changeset: 7962014b1729 Author: mcherkas Date: 2013-03-06 20:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7962014b1729 8007295: Reduce number of warnings in awt classes Reviewed-by: bae, anthony ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/geom/AffineTransform.java Changeset: f3ffead3069e Author: lana Date: 2013-03-12 16:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f3ffead3069e Merge Changeset: 153884b550f0 Author: chegar Date: 2013-02-14 13:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/153884b550f0 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList Reviewed-by: mcimadamore ! test/ProblemList.txt Changeset: e57019d2f34a Author: mduigou Date: 2013-02-13 14:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e57019d2f34a 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up Reviewed-by: mduigou, martin Contributed-by: Peter Levart ! src/share/classes/java/util/IdentityHashMap.java Changeset: 1405ad6afb1e Author: bharadwaj Date: 2013-02-14 11:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1405ad6afb1e 8007736: VerifyError for use of static method in interface Reviewed-by: mchung ! src/share/native/common/check_code.c + test/vm/verifier/TestStaticIF.java Changeset: 1ce1a307cded Author: sherman Date: 2013-02-15 01:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ce1a307cded 8008254: j.u.Calendar.JavatimeTest failed at TL b78 pit testing Summary: to use j.t.ZoneId zone name to keep round-trip Reviewed-by: okutsu ! test/java/util/Calendar/JavatimeTest.java Changeset: 048637b40787 Author: chegar Date: 2013-02-15 11:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/048637b40787 8008223: java/net/BindException/Test.java fails rarely Reviewed-by: khazra, alanb ! test/java/net/BindException/Test.java Changeset: 7748ffdca16a Author: rfield Date: 2013-02-16 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7748ffdca16a 8004970: Implement serialization in the lambda metafactory Reviewed-by: forax ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java + src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: 43726ed11fb3 Author: sherman Date: 2013-02-17 01:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/43726ed11fb3 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control Summary: To remove jdk/make/tools/javazic from the jdk repo Reviewed-by: alanb - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: ce6a2fcb4c9b Author: yhuang Date: 2013-02-16 21:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ce6a2fcb4c9b 8006748: getISO3Country() returns wrong value Reviewed-by: naoto ! src/share/classes/java/util/LocaleISOData.java Changeset: bcde0486261e Author: dingxmin Date: 2013-02-18 08:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bcde0486261e 6429204: (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/java/nio/channels/Selector/RacyDeregister.java Changeset: 49b3d8efd30a Author: darcy Date: 2013-02-19 00:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/49b3d8efd30a 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone Reviewed-by: mduigou, okutsu ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/util/TimeZone.java Changeset: 885bb24f6018 Author: coffeys Date: 2013-02-19 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/885bb24f6018 7197187: Currency.isPastCutoverDate should be made more robust Reviewed-by: alanb ! src/share/classes/java/util/Currency.java Changeset: 01b6b0dd2006 Author: coffeys Date: 2013-02-19 14:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/01b6b0dd2006 8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/protocol/http/HttpOnly.java Changeset: 824187de1591 Author: jzavgren Date: 2013-02-19 16:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/824187de1591 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc Reviewed-by: alanb, chegar, dholmes ! src/windows/native/java/io/WinNTFileSystem_md.c Changeset: e20c1c9197bf Author: emc Date: 2013-02-19 17:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e20c1c9197bf 8008312: Re-enable MethodParameter tests in JDK Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java Changeset: af396ec087f4 Author: naoto Date: 2013-02-19 10:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af396ec087f4 7092447: Clarify the default locale used in each locale sensitive operation Reviewed-by: okutsu ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Scanner.java Changeset: 16efb7ba188f Author: mduigou Date: 2013-02-19 11:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/16efb7ba188f 8004561: Additional functional interfaces, extension methods and name changes Summary: Adds additional functional interfaces for primitives and "Bi" (two operand). Adds utility extension methods. Includes some name changes for existing functional interfaces per EG decisions. Reviewed-by: briangoetz, darcy, chegar, dholmes ! src/share/classes/java/time/chrono/HijrahDeviationReader.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java + src/share/classes/java/util/function/BiConsumer.java + src/share/classes/java/util/function/BiFunction.java + src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java - src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/BooleanSupplier.java + src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java - src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java - src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java - src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/ObjDoubleConsumer.java + src/share/classes/java/util/function/ObjIntConsumer.java + src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/ToDoubleBiFunction.java + src/share/classes/java/util/function/ToDoubleFunction.java + src/share/classes/java/util/function/ToIntBiFunction.java + src/share/classes/java/util/function/ToIntFunction.java + src/share/classes/java/util/function/ToLongBiFunction.java + src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java ! test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 267bca6af07e Author: jzavgren Date: 2013-02-19 15:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/267bca6af07e 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Reviewed-by: mullan, chegar ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: ec1a79c3a99c Author: ksrini Date: 2013-02-19 16:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ec1a79c3a99c 8008262: pack200 should support MethodParameters - part 2 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/Utils.java Changeset: 85a44860f5bb Author: lana Date: 2013-02-19 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/85a44860f5bb Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java Changeset: ca43e2761a1d Author: ykantser Date: 2013-02-13 10:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ca43e2761a1d 8008089: Delete OS dependent check in JdkFinder.getExecutable() Reviewed-by: egahlin, alanb ! test/lib/testlibrary/jdk/testlibrary/JdkFinder.java Changeset: 0a2b308cc82d Author: uta Date: 2013-02-20 16:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0a2b308cc82d 8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN) Summary: the SetHandleInformation arguments list was fixed. Reviewed-by: alanb ! src/windows/native/java/lang/ProcessImpl_md.c Changeset: 5772e9edbc4c Author: dcubed Date: 2013-02-20 13:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5772e9edbc4c 8008352: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh fails on MKS Summary: Use more portable pattern counting constructs in test driver. Reviewed-by: sspitsyn, sla, coleenp ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh Changeset: 1da987f0311a Author: rfield Date: 2013-02-21 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1da987f0311a 8008356: Test LambdaSerialization.java failing Summary: run in /othervm mode Reviewed-by: ksrini ! test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: 03db11a7fb8e Author: lana Date: 2013-02-21 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/03db11a7fb8e Merge Changeset: 9078c34437ab Author: msheppar Date: 2013-02-21 20:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9078c34437ab 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests Summary: Refactored code to use java.util.Base64 Mime Encoder and Decoder as a replacement for sun.misc.BASE64Encoder and sun.misc.BASE64Decoder Reviewed-by: vinnie, chegar, sherman ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java Changeset: c6d77b2b4478 Author: stefank Date: 2013-01-22 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c6d77b2b4478 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodInBacktrace.sh + test/java/lang/instrument/RedefineMethodInBacktraceAgent.java + test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java Changeset: 0e93015e77f6 Author: stefank Date: 2013-01-22 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0e93015e77f6 7140852: Add test for 7022100 Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodWithAnnotations.sh + test/java/lang/instrument/RedefineMethodWithAnnotationsAgent.java + test/java/lang/instrument/RedefineMethodWithAnnotationsAnnotations.java + test/java/lang/instrument/RedefineMethodWithAnnotationsApp.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java Changeset: 63fe6a9820b6 Author: alanb Date: 2013-02-22 14:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/63fe6a9820b6 8008290: (profiles) Startup regression due to additional checking of JAR file manifests Reviewed-by: lancea, chegar, iris, mchung, sherman ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 9f9dac5a9e74 Author: lancea Date: 2013-02-22 09:29 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9f9dac5a9e74 8008716: address typo in CallableStatement javadocs Reviewed-by: chegar ! src/share/classes/java/sql/CallableStatement.java Changeset: 8d8a35ac7d40 Author: lancea Date: 2013-02-22 09:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8d8a35ac7d40 Merge Changeset: 6f9b3e216b01 Author: darcy Date: 2013-02-23 13:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6f9b3e216b01 6556996: (ann spec) SuppressWarnings strings should be documented Reviewed-by: mduigou, chegar, abuckley ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/SafeVarargs.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/Inherited.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.java Changeset: 155095c245b4 Author: alanb Date: 2013-02-25 17:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/155095c245b4 8008808: Allowed dependencies added by JDK-8008481 no longer required Reviewed-by: tbell, chegar ! make/tools/src/build/tools/deps/refs.allowed Changeset: 58f829566fe3 Author: bchristi Date: 2013-02-25 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/58f829566fe3 8006039: test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C Summary: Avoid automated test failure by just exiting when in 'C' locale Reviewed-by: naoto, ksrini ! test/ProblemList.txt ! test/tools/launcher/I18NJarTest.java Changeset: 4cf4403c9bf2 Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4cf4403c9bf2 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: bc92e4b044e2 Author: kmo Date: 2013-02-26 11:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc92e4b044e2 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/7087570/Test7087570.java Changeset: 5fcecbcefb71 Author: chegar Date: 2013-02-26 11:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5fcecbcefb71 Merge Changeset: 77447981db73 Author: chegar Date: 2013-02-26 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77447981db73 Merge Changeset: 022cd5adc0fa Author: alanb Date: 2013-02-26 14:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/022cd5adc0fa 8008977: profiles build broken by Nashorn build changes Reviewed-by: chegar ! makefiles/profile-rtjar-includes.txt Changeset: 5ebc62421717 Author: rfield Date: 2013-02-26 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5ebc62421717 8008770: SerializedLambda incorrect class loader for lambda deserializing class Summary: current thread's context ClassLoader was used to load class by name, pass class not name in serialization (Thank you Peter Levart for test and prototype. Thank you Sundar and Peter for unofficial reviews) Reviewed-by: forax ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java + test/java/lang/invoke/lambda/LambdaClassLoaderSerialization.java ! test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: ecd33c6ab12f Author: alanb Date: 2013-02-26 22:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ecd33c6ab12f 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes Reviewed-by: mduigou ! makefiles/CreateJars.gmk Changeset: 543be9488e50 Author: darcy Date: 2013-02-26 17:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/543be9488e50 8009102: Several docs warnings in Project Lambda APIs Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java Changeset: d623f520557b Author: darcy Date: 2013-02-26 17:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d623f520557b 8008279: Remove InvalidContainerAnnotationError.java Reviewed-by: jfranck - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: f5416026cdf5 Author: sundar Date: 2013-02-27 17:22 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f5416026cdf5 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java + test/javax/script/ExceptionTest.java ! test/javax/script/GetInterfaceTest.java ! test/javax/script/Helper.java - test/javax/script/RhinoExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/Test3.js ! test/javax/script/Test5.java ! test/javax/script/Test5.js ! test/javax/script/Test6.java ! test/javax/script/Test7.js ! test/javax/script/UnescapedBracketRegExTest.java ! test/javax/script/VersionTest.java Changeset: 13013dedcdfd Author: alanb Date: 2013-02-27 14:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/13013dedcdfd 8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present Reviewed-by: hawtin, mullan, dsamersoff, mchung ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/security/util/SecurityConstants.java ! test/java/lang/SecurityManager/NoAWT.java Changeset: 1b3173c326e6 Author: sundar Date: 2013-02-27 20:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1b3173c326e6 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine Reviewed-by: alanb ! test/sun/tools/jrunscript/CheckEngine.java ! test/sun/tools/jrunscript/jrunscript-DTest.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-cpTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/jrunscript/repl.out Changeset: 093fdf8937bd Author: vladidan Date: 2013-02-22 17:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/093fdf8937bd 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries Summary: Adding sun.os.abi Java Property support Reviewed-by: bobv, alanb, dholmes ! makefiles/Images.gmk ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c Changeset: f4b01f4e8f35 Author: mduigou Date: 2013-02-27 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f4b01f4e8f35 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 Reviewed-by: alanb ! src/share/classes/java/util/IdentityHashMap.java + test/java/util/Map/ToArray.java Changeset: 7d272e524768 Author: chegar Date: 2013-02-28 12:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7d272e524768 8006409: ThreadLocalRandom should dropping padding fields from its serialized form Reviewed-by: dl, martin, alanb, shade ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: 7246a6e4dd5a Author: juh Date: 2013-02-28 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7246a6e4dd5a 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: def2e05299b7 Author: xuelei Date: 2013-03-01 02:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/def2e05299b7 7030966: Support AEAD CipherSuites Reviewed-by: weijun, wetmore, valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 1652ac7b4bfd Author: mullan Date: 2013-03-01 16:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1652ac7b4bfd 8008908: Access denied when invoking Subject.doAsPrivileged() Summary: wildcard principal names are not processed correctly Reviewed-by: xuelei ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/WildcardPrincipalName.java + test/sun/security/provider/PolicyFile/wildcard.policy Changeset: 1ca712765acb Author: mullan Date: 2013-03-01 16:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ca712765acb Merge Changeset: 30e30ef6077e Author: dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by: alanb, chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/CopyAndMove.java Changeset: f08ad5938709 Author: chegar Date: 2013-03-02 08:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f08ad5938709 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Reviewed-by: chegar Contributed-by: Doug Lea
, Chris Hegarty ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/ThreadLessCommon.java + test/java/util/concurrent/forkjoin/ThrowingRunnable.java Changeset: df76ba760eec Author: ksrini Date: 2013-03-03 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/df76ba760eec 8007297: [pack200] allow opcodes with InterfaceMethodRefs Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java Changeset: 83e847f59fd6 Author: darcy Date: 2013-03-04 19:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/83e847f59fd6 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations Reviewed-by: jjg ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java + test/java/lang/reflect/OldenCompilingWithDefaults.java Changeset: 1a2e59d19d3e Author: naoto Date: 2013-03-04 20:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1a2e59d19d3e 8004240: Return value from getAdapterPrefence() can be modified Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + test/java/util/Locale/Bug8004240.java Changeset: 62639ca66ab9 Author: ewang Date: 2013-03-05 10:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/62639ca66ab9 8009259: TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently Reviewed-by: chegar, alanb ! test/sun/misc/Cleaner/ExitOnThrow.java ! test/sun/misc/Cleaner/exitOnThrow.sh Changeset: b5bef1f71de6 Author: jzavgren Date: 2013-03-05 14:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b5bef1f71de6 8008804: file descriptor leak in src/windows/native/java/net/DualStackPlainSocketImpl.c Reviewed-by: alanb, chegar, dsamersoff ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Changeset: be79440b8026 Author: jzavgren Date: 2013-03-05 09:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/be79440b8026 4880778: URL final class has protected methods Summary: The two set() methods have been defined to be package private. Reviewed-by: alanb, chegar, khazra ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java Changeset: f960a34f05ce Author: lana Date: 2013-03-05 11:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f960a34f05ce Merge ! makefiles/Images.gmk Changeset: 34372bb9115d Author: sla Date: 2013-03-05 19:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/34372bb9115d 8009397: test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Reviewed-by: alanb ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: 38e1821c4472 Author: jfranck Date: 2013-03-06 18:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/38e1821c4472 8007808: Missing method: Executable.getAnnotatedReturnType() Reviewed-by: darcy, forax ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java Changeset: 14e49a70729a Author: martin Date: 2013-03-06 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/14e49a70729a 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Summary: Define FILES_m to force use of linker script Reviewed-by: sherman, alanb, ohair ! make/java/zip/Makefile ! src/share/native/java/util/zip/Inflater.c Changeset: cf54f6be3e9e Author: weijun Date: 2013-03-07 11:32 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cf54f6be3e9e 8009604: old make images failed: JarBASE64Encoder class not found Reviewed-by: xuelei, wetmore ! make/common/Release.gmk Changeset: 48b7295f02f8 Author: chegar Date: 2013-03-07 10:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/48b7295f02f8 6370908: Add support for HTTP_CONNECT proxy in Socket class Reviewed-by: chegar Contributed-by: Damjan Jovanovic , Chris Hegarty + src/share/classes/java/net/HttpConnectSocketImpl.java ! src/share/classes/java/net/Socket.java + test/java/net/Socket/HttpProxy.java Changeset: 98cf76df3e6e Author: alanb Date: 2013-03-08 12:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/98cf76df3e6e 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently Reviewed-by: chegar + test/java/lang/invoke/lambda/LUtils.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: 01908630df14 Author: alanb Date: 2013-03-08 19:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/01908630df14 8009645: ClassFileTransformer hooks in ClassLoader no longer required Reviewed-by: mchung, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/ClassFileTransformer.java Changeset: e38b46041049 Author: mduigou Date: 2013-03-08 15:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e38b46041049 8001667: Comparator combinators and extension methods Reviewed-by: mduigou, briangoetz Contributed-by: henry.jen at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java + src/share/classes/java/util/Comparators.java ! test/java/util/Collections/ReverseOrder.java + test/java/util/ComparatorsTest.java Changeset: 230bafd05509 Author: weijun Date: 2013-03-09 17:27 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/230bafd05509 8000653: SPNEGO tests fail at context.getDelegCred().getRemainingInitLifetime(mechOid) Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/SpnegoLifeTime.java Changeset: 334ddf3b101f Author: coleenp Date: 2013-03-12 10:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/334ddf3b101f 7154889: Non-zero padding is still not allowed in the tableswitch/lookupswitch instructions. Summary: Do not check that the padding bytes are zero if class file format version >=51. Reviewed-by: dholmes, coleenp, mullan, kvn Contributed-by: harold.seigel at oracle.com ! src/share/native/common/check_code.c Changeset: 6379415d8fca Author: wetmore Date: 2013-03-12 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6379415d8fca 8009925: Back out AEAD CipherSuites temporarily Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java - src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java - test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 5880bfd30db1 Author: lana Date: 2013-03-12 16:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5880bfd30db1 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - test/javax/script/RhinoExceptionTest.java Changeset: 72ffb2bc15bb Author: lana Date: 2013-03-12 18:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/72ffb2bc15bb Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java ! test/ProblemList.txt - test/javax/script/RhinoExceptionTest.java Changeset: 66a892bb28b7 Author: anthony Date: 2012-10-12 15:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/66a892bb28b7 7173145: Improve in-memory representation of splashscreens Reviewed-by: bae, mschoene ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 85bf51db473c Author: xuelei Date: 2012-10-15 07:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/85bf51db473c 7192393: Better Checking of order of TLS Messages Summary: Also reviewed by Andrew Gross Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: 24a3eb2f0553 Author: malenkov Date: 2012-10-15 19:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/24a3eb2f0553 7200493: Improve cache handling Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/finder/MethodFinder.java Changeset: c7c39320bc6c Author: rupashka Date: 2012-10-16 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c7c39320bc6c 7186948: Improve Swing data validation Reviewed-by: art, ahgross ! src/share/classes/javax/swing/UIDefaults.java Changeset: 3c8d0085b094 Author: ksrini Date: 2012-10-16 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3c8d0085b094 7186945: Unpack200 improvement Reviewed-by: jrose, jjh, mschoene ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 01f67953c057 Author: ksrini Date: 2012-10-16 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/01f67953c057 7186957: Improve Pack200 data validation Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: b0bf41ba1cf8 Author: ksrini Date: 2012-10-16 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b0bf41ba1cf8 7186946: Refine unpacker resource usage Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/native/com/sun/java/util/jar/pack/jni.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: f0bc5a6dff2b Author: ksrini Date: 2012-10-16 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f0bc5a6dff2b 7200499: Better data validation for options Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c Changeset: 7e19ab4ff5d3 Author: ksrini Date: 2012-10-16 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7e19ab4ff5d3 7200500: Launcher better input validation Reviewed-by: darcy, jjh, mschoene ! src/share/bin/parse_manifest.c Changeset: 62f3270f03fa Author: dholmes Date: 2012-08-22 21:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/62f3270f03fa 6776941: Improve thread pool shutdown Reviewed-by: dl, skoivu ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: e7cce63bf293 Author: xuelei Date: 2012-10-22 07:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e7cce63bf293 7192392: Better validation of client keys Summary: Also reviewed by Andrew Gross Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java - src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/KeyUtil.java ! test/sun/security/mscapi/ShortRSAKeyWithinTLS.java Changeset: 091dd6eb30aa Author: khazra Date: 2012-10-22 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/091dd6eb30aa 7186954: Improve connection performance Reviewed-by: chegar, skoivu ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java Changeset: c26d42a92bd8 Author: weijun Date: 2012-09-19 12:58 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c26d42a92bd8 8000210: Improve JarFile code quality Reviewed-by: ahgross, xuelei, mschoene ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java Changeset: a54b61ae6f12 Author: mullan Date: 2012-10-26 15:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a54b61ae6f12 7201068: Better handling of UI elements Reviewed-by: xuelei ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 71ab8d79c6b4 Author: asaha Date: 2012-10-26 10:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/71ab8d79c6b4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: be07910b3fad Author: asaha Date: 2012-10-26 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/be07910b3fad Merge Changeset: e14221289076 Author: dsamersoff Date: 2012-10-30 17:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e14221289076 8000539: JMX implementation allows invocation of methods of a system class Summary: Added extra packageAccess check call Reviewed-by: ahgross, dfuchs Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: 64440cc2ea8b Author: mchung Date: 2012-11-02 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/64440cc2ea8b 7197546: (proxy) Reflect about creating reflective proxies Reviewed-by: alanb, jdn, jrose ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy Changeset: f936be5be1e7 Author: rupashka Date: 2012-11-06 15:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f936be5be1e7 7200491: Tighten up JTable layout code Reviewed-by: art, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java Changeset: 3069b91ff041 Author: chegar Date: 2012-11-07 14:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3069b91ff041 7201071: InetSocketAddress serialization issue Reviewed-by: alanb, michaelm, skoivu ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java Changeset: 69fd15e0437d Author: smarks Date: 2012-11-08 15:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/69fd15e0437d 7201070: Serialization to conform to protocol Reviewed-by: dmocek, ahgross, skoivu ! src/share/classes/java/io/ObjectInputStream.java Changeset: 9097b6ec0ecd Author: ksrini Date: 2012-11-09 14:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9097b6ec0ecd 8002091: tools/launcher/ToolsOpts.java test started to fail since 7u11 b01 on Windows Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c ! test/tools/launcher/ToolsOpts.java Changeset: 7bc8d5a63d9e Author: bagiras Date: 2012-11-15 23:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7bc8d5a63d9e 7192977: Issue in toolkit thread Reviewed-by: skoivu, rupashka, art ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 09e2dcd476cf Author: bae Date: 2012-11-16 11:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/09e2dcd476cf 8001972: Improve image processing Reviewed-by: prr, ahgross ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 1b616e1ca09c Author: dmocek Date: 2012-11-19 13:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1b616e1ca09c 6563318: RMI data sanitization Reviewed-by: ahgross, hawtin, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! test/java/rmi/testlibrary/JavaVM.java Changeset: aa8717a5c9cd Author: dmocek Date: 2012-11-19 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/aa8717a5c9cd 8001242: Improve RMI HTTP conformance Reviewed-by: ahgross, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java Changeset: ecedf46ae7db Author: bae Date: 2012-11-20 11:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ecedf46ae7db 8002325: Improve management of images Reviewed-by: prr, ahgross ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h Changeset: eda84d5738e3 Author: denis Date: 2012-11-26 20:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eda84d5738e3 7186952: Improve clipboard access Reviewed-by: serb, ahgross ! src/share/classes/java/awt/TextComponent.java ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: d1668eca22bf Author: mchung Date: 2012-11-26 22:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d1668eca22bf 6664509: Add logging context 6664528: Find log level matching its name or value given at construction time Reviewed-by: alanb, ahgross, jgish, hawtin ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/lib/security/java.security Changeset: b8ee2e9ff7e3 Author: denis Date: 2012-11-30 15:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b8ee2e9ff7e3 7201064: Better dialogue checking Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: 90bbdae7aaa4 Author: ewendeli Date: 2013-02-03 23:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/90bbdae7aaa4 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/rmi/testlibrary/JavaVM.java Changeset: cc2057f84eb7 Author: mchung Date: 2012-12-05 14:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cc2057f84eb7 8004175: Restricted packages added in java.security are missing in java.security-{macosx, solaris, windows} Reviewed-by: alanb, ahgross, mullan ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89e43b8940c9 Author: dsamersoff Date: 2012-12-07 22:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/89e43b8940c9 8000537: Contextualize RequiredModelMBean class Summary: Contextualize RequiredModelMBean class Reviewed-by: asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Changeset: 7933c80c162a Author: denis Date: 2012-12-12 21:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7933c80c162a 8004341: Two JCK tests fails with 7u11 b06 Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: ed08394e1a15 Author: mullan Date: 2012-12-18 13:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ed08394e1a15 8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01 Reviewed-by: vinnie, skoivu, mgrebac, ohair, tbell ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: 32cd4975d2d6 Author: mchung Date: 2013-01-10 19:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/32cd4975d2d6 8005615: Java Logger fails to load tomcat logger implementation (JULI) Reviewed-by: alanb, ahgross ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/CustomLogManager.java + test/java/util/logging/CustomLogManagerTest.java + test/java/util/logging/SimpleLogManager.java Changeset: c0fbd737aef0 Author: ewendeli Date: 2013-01-28 11:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c0fbd737aef0 8006864: Update java.security-linux to include changes in java.security Reviewed-by: mchung, mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 12491fa16985 Author: ewendeli Date: 2013-02-05 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/12491fa16985 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java Changeset: de419ea8ed8f Author: mchung Date: 2013-01-28 15:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/de419ea8ed8f 8006882: Proxy generated classes in sun.proxy package breaks JMockit Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8effe3b7489d Author: dfuchs Date: 2013-01-30 11:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8effe3b7489d 8006446: Restrict MBeanServer access Reviewed-by: alanb, mchung, darcy, jrose, ahgross, skoivu ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java Changeset: ebfb0bb58428 Author: mchung Date: 2013-01-24 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ebfb0bb58428 8004937: Improve proxy construction Reviewed-by: jrose, ahgross ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java Changeset: af11c227a91e Author: mchung Date: 2013-02-05 22:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af11c227a91e 8007393: Possible race condition after JDK-6664509 Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 1143bb5e7064 Author: mchung Date: 2013-02-07 09:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1143bb5e7064 8007611: logging behavior in applet changed Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 5925630b7a7d Author: xuelei Date: 2013-02-07 16:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5925630b7a7d 8006777: Improve TLS handling of invalid messages Reviewed-by: wetmore, ahgross ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: d57363ff612f Author: valeriep Date: 2013-02-07 16:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d57363ff612f 8007688: Blacklist known bad certificate Summary: Added two known bad certs to the blacklist certs. Reviewed-by: mullan ! src/share/classes/sun/security/util/UntrustedCertificates.java Changeset: c18aeb4ca957 Author: ewendeli Date: 2013-02-19 21:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c18aeb4ca957 Merge ! src/share/bin/parse_manifest.c ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/sun/awt/image/awt_parseImage.c ! test/Makefile Changeset: f7fb3de623ba Author: ewendeli Date: 2013-02-19 21:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f7fb3de623ba Merge Changeset: f686c8e3c8e0 Author: ewendeli Date: 2013-02-25 08:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f686c8e3c8e0 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: e3cac5962e32 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e3cac5962e32 8006439: Improve MethodHandles coverage Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 62be74f35886 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/62be74f35886 8006179: JSR292 MethodHandles lookup with interface using findVirtual() Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java Changeset: 9995881dfb4e Author: vlivanov Date: 2013-02-22 02:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9995881dfb4e 8006125: Update MethodHandles library interactions Reviewed-by: jrose ! src/share/classes/sun/reflect/misc/MethodUtil.java Changeset: 0807820fca96 Author: vlivanov Date: 2013-02-22 02:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0807820fca96 8004933: Improve MethodHandle interaction with libraries Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: ae1fed8d80e1 Author: ewendeli Date: 2013-02-26 06:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ae1fed8d80e1 Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 5e4c2d7f3b67 Author: ewendeli Date: 2013-02-26 20:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e4c2d7f3b67 Merge ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/sun/security/util/KeyLength.java Changeset: 4d4848124bff Author: ewendeli Date: 2013-02-27 09:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4d4848124bff Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 36ff48ae6ffe Author: ewendeli Date: 2013-02-27 18:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/36ff48ae6ffe Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 931fb59eae26 Author: lana Date: 2013-03-12 19:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/931fb59eae26 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/lang/Class.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 9528e88f8d53 Author: lana Date: 2013-03-13 23:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9528e88f8d53 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: f282190e931a Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f282190e931a Merge Changeset: 624bcb480006 Author: omajid Date: 2013-03-18 10:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/624bcb480006 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! makefiles/CompileNativeLibraries.gmk Changeset: cdcd4512c6f1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cdcd4512c6f1 Added tag jdk8-b82 for changeset 624bcb480006 ! .hgtags From john.coomes at oracle.com Fri Mar 22 08:26:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 08:26:11 +0000 Subject: hg: hsx/hotspot-gc/nashorn: 134 new changesets Message-ID: <20130322082727.19BA74832A@hg.openjdk.java.net> Changeset: b8a1b238c77c Author: duke Date: 2007-12-01 00:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b8a1b238c77c Initial load + .hgignore + .jcheck/conf Changeset: 6031a0bc0ae2 Author: jcoomes Date: 2012-12-20 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/6031a0bc0ae2 8005364: initial hg tags for nashorn repo Reviewed-by: amurillo + .hgtags Changeset: da1e581c933b Author: jlaskey Date: 2012-12-21 16:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/da1e581c933b 8005403: Open-source Nashorn Reviewed-by: attila, hannesw, lagergren, sundar Contributed-by: james.laskey at oracle.com, akhil.arora at oracle.com, andreas.woess at jku.at, attila.szegedi at oracle.com, hannes.wallnoefer at oracle.com, henry.jen at oracle.com, marcus.lagergren at oracle.com, pavel.semenov at oracle.com, pavel.stepanov at oracle.com, petr.hejl at oracle.com, petr.pisl at oracle.com, sundararajan.athijegannathan at oracle.com ! .hgignore + ASSEMBLY_EXCEPTION + LICENSE + README + RELEASE_README + THIRD_PARTY_README + bin/checkintest.sh + bin/fixorphantests.sh + bin/fixwhitespace.sh + bin/jjs + bin/jjs.bat + bin/jjssecure + bin/jjssecure.bat + bin/nashorn + bin/nashorn.bat + bin/rm-non-tracked.sh + bin/verbose_octane.bat + bin/verbose_octane.sh + buildtools/nasgen/README + buildtools/nasgen/build.xml + buildtools/nasgen/nasgen.iml + buildtools/nasgen/project.properties + buildtools/nasgen/src/META-INF/MANIFEST.MF + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + docs/DEVELOPER_README + docs/genshelldoc.js + make/Makefile + make/build-benchmark.xml + make/build-nasgen.xml + make/build.xml + make/nbproject/ide-file-targets.xml + make/nbproject/ide-targets.xml + make/nbproject/jdk.xml + make/nbproject/nbjdk.properties + make/nbproject/nbjdk.xml + make/nbproject/project.xml + make/project.properties + samples/counters.js + samples/letter.js + samples/parser.js + samples/shell.js + samples/test.js + samples/uniq.js + src/META-INF/MANIFEST.MF + src/META-INF/services/javax.script.ScriptEngineFactory + src/jdk/nashorn/api/scripting/NashornException.java + src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/api/scripting/package-info.java + src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/BranchOptimizer.java + src/jdk/nashorn/internal/codegen/ClassEmitter.java + src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompileUnit.java + src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/ConstantData.java + src/jdk/nashorn/internal/codegen/Emitter.java + src/jdk/nashorn/internal/codegen/Frame.java + src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Lower.java + src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/Namespace.java + src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/codegen/SharedScopeCall.java + src/jdk/nashorn/internal/codegen/Splitter.java + src/jdk/nashorn/internal/codegen/Transform.java + src/jdk/nashorn/internal/codegen/WeighNodes.java + src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/MapCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java + src/jdk/nashorn/internal/codegen/types/ArrayType.java + src/jdk/nashorn/internal/codegen/types/BitwiseType.java + src/jdk/nashorn/internal/codegen/types/BooleanType.java + src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeOps.java + src/jdk/nashorn/internal/codegen/types/IntType.java + src/jdk/nashorn/internal/codegen/types/LongType.java + src/jdk/nashorn/internal/codegen/types/NumberType.java + src/jdk/nashorn/internal/codegen/types/NumericType.java + src/jdk/nashorn/internal/codegen/types/ObjectType.java + src/jdk/nashorn/internal/codegen/types/Type.java + src/jdk/nashorn/internal/ir/AccessNode.java + src/jdk/nashorn/internal/ir/Assignment.java + src/jdk/nashorn/internal/ir/BaseNode.java + src/jdk/nashorn/internal/ir/BinaryNode.java + src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BreakNode.java + src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/CallNode.java + src/jdk/nashorn/internal/ir/CaseNode.java + src/jdk/nashorn/internal/ir/CatchNode.java + src/jdk/nashorn/internal/ir/ContinueNode.java + src/jdk/nashorn/internal/ir/DoWhileNode.java + src/jdk/nashorn/internal/ir/EmptyNode.java + src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/ForNode.java + src/jdk/nashorn/internal/ir/FunctionCall.java + src/jdk/nashorn/internal/ir/FunctionNode.java + src/jdk/nashorn/internal/ir/IdentNode.java + src/jdk/nashorn/internal/ir/IfNode.java + src/jdk/nashorn/internal/ir/IndexNode.java + src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LabeledNode.java + src/jdk/nashorn/internal/ir/LineNumberNode.java + src/jdk/nashorn/internal/ir/LiteralNode.java + src/jdk/nashorn/internal/ir/Location.java + src/jdk/nashorn/internal/ir/Node.java + src/jdk/nashorn/internal/ir/ObjectNode.java + src/jdk/nashorn/internal/ir/PropertyKey.java + src/jdk/nashorn/internal/ir/PropertyNode.java + src/jdk/nashorn/internal/ir/ReferenceNode.java + src/jdk/nashorn/internal/ir/ReturnNode.java + src/jdk/nashorn/internal/ir/RuntimeNode.java + src/jdk/nashorn/internal/ir/SplitNode.java + src/jdk/nashorn/internal/ir/SwitchNode.java + src/jdk/nashorn/internal/ir/Symbol.java + src/jdk/nashorn/internal/ir/TernaryNode.java + src/jdk/nashorn/internal/ir/ThrowNode.java + src/jdk/nashorn/internal/ir/TryNode.java + src/jdk/nashorn/internal/ir/TypeOverride.java + src/jdk/nashorn/internal/ir/UnaryNode.java + src/jdk/nashorn/internal/ir/VarNode.java + src/jdk/nashorn/internal/ir/WhileNode.java + src/jdk/nashorn/internal/ir/WithNode.java + src/jdk/nashorn/internal/ir/annotations/ChildNode.java + src/jdk/nashorn/internal/ir/annotations/Ignore.java + src/jdk/nashorn/internal/ir/annotations/ParentNode.java + src/jdk/nashorn/internal/ir/annotations/Reference.java + src/jdk/nashorn/internal/ir/debug/ASTWriter.java + src/jdk/nashorn/internal/ir/debug/JSONWriter.java + src/jdk/nashorn/internal/ir/debug/PrintVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java + src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java + src/jdk/nashorn/internal/objects/ArrayBufferView.java + src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java + src/jdk/nashorn/internal/objects/DateParser.java + src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java + src/jdk/nashorn/internal/objects/Global.java + src/jdk/nashorn/internal/objects/NativeArguments.java + src/jdk/nashorn/internal/objects/NativeArray.java + src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeBoolean.java + src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/objects/NativeDebug.java + src/jdk/nashorn/internal/objects/NativeError.java + src/jdk/nashorn/internal/objects/NativeEvalError.java + src/jdk/nashorn/internal/objects/NativeFloat32Array.java + src/jdk/nashorn/internal/objects/NativeFloat64Array.java + src/jdk/nashorn/internal/objects/NativeFunction.java + src/jdk/nashorn/internal/objects/NativeInt16Array.java + src/jdk/nashorn/internal/objects/NativeInt32Array.java + src/jdk/nashorn/internal/objects/NativeInt8Array.java + src/jdk/nashorn/internal/objects/NativeJSAdapter.java + src/jdk/nashorn/internal/objects/NativeJSON.java + src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/objects/NativeJavaImporter.java + src/jdk/nashorn/internal/objects/NativeMath.java + src/jdk/nashorn/internal/objects/NativeNumber.java + src/jdk/nashorn/internal/objects/NativeObject.java + src/jdk/nashorn/internal/objects/NativeRangeError.java + src/jdk/nashorn/internal/objects/NativeReferenceError.java + src/jdk/nashorn/internal/objects/NativeRegExp.java + src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + src/jdk/nashorn/internal/objects/NativeStrictArguments.java + src/jdk/nashorn/internal/objects/NativeString.java + src/jdk/nashorn/internal/objects/NativeSyntaxError.java + src/jdk/nashorn/internal/objects/NativeTypeError.java + src/jdk/nashorn/internal/objects/NativeURIError.java + src/jdk/nashorn/internal/objects/NativeUint16Array.java + src/jdk/nashorn/internal/objects/NativeUint32Array.java + src/jdk/nashorn/internal/objects/NativeUint8Array.java + src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java + src/jdk/nashorn/internal/objects/PrototypeObject.java + src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/annotations/Attribute.java + src/jdk/nashorn/internal/objects/annotations/Constructor.java + src/jdk/nashorn/internal/objects/annotations/Function.java + src/jdk/nashorn/internal/objects/annotations/Getter.java + src/jdk/nashorn/internal/objects/annotations/Property.java + src/jdk/nashorn/internal/objects/annotations/ScriptClass.java + src/jdk/nashorn/internal/objects/annotations/Setter.java + src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java + src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java + src/jdk/nashorn/internal/objects/annotations/Where.java + src/jdk/nashorn/internal/objects/package-info.java + src/jdk/nashorn/internal/parser/AbstractParser.java + src/jdk/nashorn/internal/parser/JSONParser.java + src/jdk/nashorn/internal/parser/Lexer.java + src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/parser/RegExp.java + src/jdk/nashorn/internal/parser/RegExpScanner.java + src/jdk/nashorn/internal/parser/Scanner.java + src/jdk/nashorn/internal/parser/Token.java + src/jdk/nashorn/internal/parser/TokenKind.java + src/jdk/nashorn/internal/parser/TokenLookup.java + src/jdk/nashorn/internal/parser/TokenStream.java + src/jdk/nashorn/internal/parser/TokenType.java + src/jdk/nashorn/internal/runtime/AccessorProperty.java + src/jdk/nashorn/internal/runtime/BitVector.java + src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/ConsString.java + src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/Debug.java + src/jdk/nashorn/internal/runtime/DebugLogger.java + src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java + src/jdk/nashorn/internal/runtime/ECMAErrors.java + src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/ErrorManager.java + src/jdk/nashorn/internal/runtime/FindProperty.java + src/jdk/nashorn/internal/runtime/FunctionScope.java + src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/GlobalObject.java + src/jdk/nashorn/internal/runtime/JSErrorType.java + src/jdk/nashorn/internal/runtime/JSType.java + src/jdk/nashorn/internal/runtime/Logging.java + src/jdk/nashorn/internal/runtime/NashornLoader.java + src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/NumberToString.java + src/jdk/nashorn/internal/runtime/ParserException.java + src/jdk/nashorn/internal/runtime/Property.java + src/jdk/nashorn/internal/runtime/PropertyAccess.java + src/jdk/nashorn/internal/runtime/PropertyDescriptor.java + src/jdk/nashorn/internal/runtime/PropertyHashMap.java + src/jdk/nashorn/internal/runtime/PropertyListener.java + src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + src/jdk/nashorn/internal/runtime/PropertyMap.java + src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java + src/jdk/nashorn/internal/runtime/RegExpMatch.java + src/jdk/nashorn/internal/runtime/Scope.java + src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptLoader.java + src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Source.java + src/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk/nashorn/internal/runtime/StructureLoader.java + src/jdk/nashorn/internal/runtime/URIUtils.java + src/jdk/nashorn/internal/runtime/Undefined.java + src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + src/jdk/nashorn/internal/runtime/Version.java + src/jdk/nashorn/internal/runtime/WithObject.java + src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java + src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java + src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java + src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java + src/jdk/nashorn/internal/runtime/arrays/MapIterator.java + src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java + src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java + src/jdk/nashorn/internal/runtime/linker/Lookup.java + src/jdk/nashorn/internal/runtime/linker/Mangler.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java + src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java + src/jdk/nashorn/internal/runtime/linker/NashornGuards.java + src/jdk/nashorn/internal/runtime/linker/NashornLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + src/jdk/nashorn/internal/runtime/options/KeyValueOption.java + src/jdk/nashorn/internal/runtime/options/Option.java + src/jdk/nashorn/internal/runtime/options/OptionTemplate.java + src/jdk/nashorn/internal/runtime/options/Options.java + src/jdk/nashorn/internal/runtime/options/ValueOption.java + src/jdk/nashorn/internal/runtime/resources/Messages.properties + src/jdk/nashorn/internal/runtime/resources/Options.properties + src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + src/jdk/nashorn/internal/runtime/resources/parser.js + src/jdk/nashorn/internal/runtime/resources/version.properties-template + src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/tools/Shell.java + src/jdk/nashorn/tools/resources/Shell.properties + src/jdk/nashorn/tools/resources/shell.js + src/netscape/javascript/JSObject.java + src/overview.html + test/README + test/examples/dual-fields-micro.js + test/examples/innerbench.js + test/examples/typechain.js + test/lib/benchmark.js + test/opt/add.js + test/opt/add_constant.js + test/opt/add_reuse_callsite.js + test/opt/add_revert2.js + test/opt/cascade_specialize.js + test/script/assert.js + test/script/basic/NASHORN-100.js + test/script/basic/NASHORN-100.js.EXPECTED + test/script/basic/NASHORN-101.js + test/script/basic/NASHORN-101.js.EXPECTED + test/script/basic/NASHORN-102.js + test/script/basic/NASHORN-102.js.EXPECTED + test/script/basic/NASHORN-103.js + test/script/basic/NASHORN-104.js + test/script/basic/NASHORN-104.js.EXPECTED + test/script/basic/NASHORN-105.js + test/script/basic/NASHORN-105.js.EXPECTED + test/script/basic/NASHORN-106.js + test/script/basic/NASHORN-106.js.EXPECTED + test/script/basic/NASHORN-107.js + test/script/basic/NASHORN-108.js + test/script/basic/NASHORN-108.js.EXPECTED + test/script/basic/NASHORN-109.js + test/script/basic/NASHORN-109.js.EXPECTED + test/script/basic/NASHORN-11.js + test/script/basic/NASHORN-11.js.EXPECTED + test/script/basic/NASHORN-111.js + test/script/basic/NASHORN-111.js.EXPECTED + test/script/basic/NASHORN-113.js + test/script/basic/NASHORN-113.js.EXPECTED + test/script/basic/NASHORN-114.js + test/script/basic/NASHORN-115.js + test/script/basic/NASHORN-115.js.EXPECTED + test/script/basic/NASHORN-117.js + test/script/basic/NASHORN-118.js + test/script/basic/NASHORN-118.js.EXPECTED + test/script/basic/NASHORN-119.js + test/script/basic/NASHORN-119.js.EXPECTED + test/script/basic/NASHORN-12.js + test/script/basic/NASHORN-120.js + test/script/basic/NASHORN-122.js + test/script/basic/NASHORN-122.js.EXPECTED + test/script/basic/NASHORN-126.js + test/script/basic/NASHORN-126.js.EXPECTED + test/script/basic/NASHORN-127.js + test/script/basic/NASHORN-127.js.EXPECTED + test/script/basic/NASHORN-130.js + test/script/basic/NASHORN-132.js + test/script/basic/NASHORN-132.js.EXPECTED + test/script/basic/NASHORN-133.js + test/script/basic/NASHORN-133.js.EXPECTED + test/script/basic/NASHORN-135.js + test/script/basic/NASHORN-136.js + test/script/basic/NASHORN-136.js.EXPECTED + test/script/basic/NASHORN-14.js + test/script/basic/NASHORN-14.js.EXPECTED + test/script/basic/NASHORN-148.js + test/script/basic/NASHORN-148.js.EXPECTED + test/script/basic/NASHORN-15.js + test/script/basic/NASHORN-15.js.EXPECTED + test/script/basic/NASHORN-153.js + test/script/basic/NASHORN-156.js + test/script/basic/NASHORN-157.js + test/script/basic/NASHORN-163.js + test/script/basic/NASHORN-163.js.EXPECTED + test/script/basic/NASHORN-164.js + test/script/basic/NASHORN-165.js + test/script/basic/NASHORN-166.js + test/script/basic/NASHORN-168.js + test/script/basic/NASHORN-168.js.EXPECTED + test/script/basic/NASHORN-169.js + test/script/basic/NASHORN-172.js + test/script/basic/NASHORN-173.js + test/script/basic/NASHORN-173.js.EXPECTED + test/script/basic/NASHORN-174.js + test/script/basic/NASHORN-175.js + test/script/basic/NASHORN-176.js + test/script/basic/NASHORN-177.js + test/script/basic/NASHORN-177.js.EXPECTED + test/script/basic/NASHORN-178.js + test/script/basic/NASHORN-178.js.EXPECTED + test/script/basic/NASHORN-179.js + test/script/basic/NASHORN-18.js + test/script/basic/NASHORN-18.js.EXPECTED + test/script/basic/NASHORN-181.js + test/script/basic/NASHORN-182.js + test/script/basic/NASHORN-183.js + test/script/basic/NASHORN-184.js + test/script/basic/NASHORN-184.js.EXPECTED + test/script/basic/NASHORN-185.js + test/script/basic/NASHORN-185.js.EXPECTED + test/script/basic/NASHORN-187.js + test/script/basic/NASHORN-188.js + test/script/basic/NASHORN-188.js.EXPECTED + test/script/basic/NASHORN-19.js + test/script/basic/NASHORN-19.js.EXPECTED + test/script/basic/NASHORN-190.js + test/script/basic/NASHORN-192.js + test/script/basic/NASHORN-194.js + test/script/basic/NASHORN-196.js + test/script/basic/NASHORN-198.js + test/script/basic/NASHORN-20.js + test/script/basic/NASHORN-20.js.EXPECTED + test/script/basic/NASHORN-201.js + test/script/basic/NASHORN-202.js + test/script/basic/NASHORN-203.js + test/script/basic/NASHORN-204.js + test/script/basic/NASHORN-205.js + test/script/basic/NASHORN-206.js + test/script/basic/NASHORN-207.js + test/script/basic/NASHORN-207_2.js + test/script/basic/NASHORN-208.js + test/script/basic/NASHORN-208.js.EXPECTED + test/script/basic/NASHORN-209.js + test/script/basic/NASHORN-209.js.EXPECTED + test/script/basic/NASHORN-21.js + test/script/basic/NASHORN-21.js.EXPECTED + test/script/basic/NASHORN-211.js + test/script/basic/NASHORN-212.js + test/script/basic/NASHORN-213.js + test/script/basic/NASHORN-215.js + test/script/basic/NASHORN-215.js.EXPECTED + test/script/basic/NASHORN-216.js + test/script/basic/NASHORN-217.js + test/script/basic/NASHORN-217.js.EXPECTED + test/script/basic/NASHORN-219.js + test/script/basic/NASHORN-219.js.EXPECTED + test/script/basic/NASHORN-22.js + test/script/basic/NASHORN-22.js.EXPECTED + test/script/basic/NASHORN-221.js + test/script/basic/NASHORN-222.js + test/script/basic/NASHORN-223.js + test/script/basic/NASHORN-225.js + test/script/basic/NASHORN-226.js + test/script/basic/NASHORN-227.js + test/script/basic/NASHORN-228.js + test/script/basic/NASHORN-229.js + test/script/basic/NASHORN-229_subtest.js + test/script/basic/NASHORN-23.js + test/script/basic/NASHORN-23.js.EXPECTED + test/script/basic/NASHORN-232.js + test/script/basic/NASHORN-234.js + test/script/basic/NASHORN-235.js + test/script/basic/NASHORN-236.js + test/script/basic/NASHORN-237.js + test/script/basic/NASHORN-239.js + test/script/basic/NASHORN-24.js + test/script/basic/NASHORN-24.js.EXPECTED + test/script/basic/NASHORN-241.js + test/script/basic/NASHORN-242.js + test/script/basic/NASHORN-245.js + test/script/basic/NASHORN-247.js + test/script/basic/NASHORN-25.js + test/script/basic/NASHORN-25.js.EXPECTED + test/script/basic/NASHORN-251.js + test/script/basic/NASHORN-252.js + test/script/basic/NASHORN-253.js + test/script/basic/NASHORN-256.js + test/script/basic/NASHORN-258.js + test/script/basic/NASHORN-258.js.EXPECTED + test/script/basic/NASHORN-26.js + test/script/basic/NASHORN-26.js.EXPECTED + test/script/basic/NASHORN-260.js + test/script/basic/NASHORN-261.js + test/script/basic/NASHORN-262.js + test/script/basic/NASHORN-263.js + test/script/basic/NASHORN-264.js + test/script/basic/NASHORN-265.js + test/script/basic/NASHORN-265.js.EXPECTED + test/script/basic/NASHORN-266.js + test/script/basic/NASHORN-269.js + test/script/basic/NASHORN-27.js + test/script/basic/NASHORN-27.js.EXPECTED + test/script/basic/NASHORN-270.js + test/script/basic/NASHORN-271.js + test/script/basic/NASHORN-275.js + test/script/basic/NASHORN-276.js + test/script/basic/NASHORN-277.js + test/script/basic/NASHORN-278.js + test/script/basic/NASHORN-28.js + test/script/basic/NASHORN-28.js.EXPECTED + test/script/basic/NASHORN-281.js + test/script/basic/NASHORN-284.js + test/script/basic/NASHORN-284.js.EXPECTED + test/script/basic/NASHORN-285.js + test/script/basic/NASHORN-285.js.EXPECTED + test/script/basic/NASHORN-288.js + test/script/basic/NASHORN-29.js + test/script/basic/NASHORN-29.js.EXPECTED + test/script/basic/NASHORN-293.js + test/script/basic/NASHORN-293.js.EXPECTED + test/script/basic/NASHORN-294.js + test/script/basic/NASHORN-296.js + test/script/basic/NASHORN-297.js + test/script/basic/NASHORN-30.js + test/script/basic/NASHORN-30.js.EXPECTED + test/script/basic/NASHORN-300.js + test/script/basic/NASHORN-301.js + test/script/basic/NASHORN-301.js.EXPECTED + test/script/basic/NASHORN-304.js + test/script/basic/NASHORN-310.js + test/script/basic/NASHORN-310.js.EXPECTED + test/script/basic/NASHORN-318.js + test/script/basic/NASHORN-318.js.EXPECTED + test/script/basic/NASHORN-32.js + test/script/basic/NASHORN-32.js.EXPECTED + test/script/basic/NASHORN-321.js + test/script/basic/NASHORN-321.js.EXPECTED + test/script/basic/NASHORN-323.js + test/script/basic/NASHORN-323.js.EXPECTED + test/script/basic/NASHORN-324.js + test/script/basic/NASHORN-33.js + test/script/basic/NASHORN-33.js.EXPECTED + test/script/basic/NASHORN-331.js + test/script/basic/NASHORN-331.js.EXPECTED + test/script/basic/NASHORN-337.js + test/script/basic/NASHORN-337.js.EXPECTED + test/script/basic/NASHORN-34.js + test/script/basic/NASHORN-34.js.EXPECTED + test/script/basic/NASHORN-340.js + test/script/basic/NASHORN-340.js.EXPECTED + test/script/basic/NASHORN-349.js + test/script/basic/NASHORN-354.js + test/script/basic/NASHORN-354.js.EXPECTED + test/script/basic/NASHORN-355.js + test/script/basic/NASHORN-355.js.EXPECTED + test/script/basic/NASHORN-36.js + test/script/basic/NASHORN-36.js.EXPECTED + test/script/basic/NASHORN-365.js + test/script/basic/NASHORN-366.js + test/script/basic/NASHORN-366.js.EXPECTED + test/script/basic/NASHORN-368.js + test/script/basic/NASHORN-368.js.EXPECTED + test/script/basic/NASHORN-37.js + test/script/basic/NASHORN-37.js.EXPECTED + test/script/basic/NASHORN-375.js + test/script/basic/NASHORN-376.js + test/script/basic/NASHORN-377.js + test/script/basic/NASHORN-377.js.EXPECTED + test/script/basic/NASHORN-378.js + test/script/basic/NASHORN-38.js + test/script/basic/NASHORN-38.js.EXPECTED + test/script/basic/NASHORN-380.js + test/script/basic/NASHORN-380.js.EXPECTED + test/script/basic/NASHORN-381.js + test/script/basic/NASHORN-382.js + test/script/basic/NASHORN-383.js + test/script/basic/NASHORN-384.js + test/script/basic/NASHORN-384.js.EXPECTED + test/script/basic/NASHORN-385.js + test/script/basic/NASHORN-385.js.EXPECTED + test/script/basic/NASHORN-389.js + test/script/basic/NASHORN-389.js.EXPECTED + test/script/basic/NASHORN-393.js + test/script/basic/NASHORN-393.js.EXPECTED + test/script/basic/NASHORN-394.js + test/script/basic/NASHORN-394.js.EXPECTED + test/script/basic/NASHORN-396.js + test/script/basic/NASHORN-397.js + test/script/basic/NASHORN-398.js + test/script/basic/NASHORN-40.js + test/script/basic/NASHORN-40.js.EXPECTED + test/script/basic/NASHORN-400.js + test/script/basic/NASHORN-400.js.EXPECTED + test/script/basic/NASHORN-401.js + test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/NASHORN-402.js + test/script/basic/NASHORN-402.js.EXPECTED + test/script/basic/NASHORN-404.js + test/script/basic/NASHORN-405.js + test/script/basic/NASHORN-405.js.EXPECTED + test/script/basic/NASHORN-406.js + test/script/basic/NASHORN-408.js + test/script/basic/NASHORN-408.js.EXPECTED + test/script/basic/NASHORN-415.js + test/script/basic/NASHORN-415.js.EXPECTED + test/script/basic/NASHORN-416.js + test/script/basic/NASHORN-417.js + test/script/basic/NASHORN-418.js + test/script/basic/NASHORN-420.js + test/script/basic/NASHORN-421.js + test/script/basic/NASHORN-423.js + test/script/basic/NASHORN-423.js.EXPECTED + test/script/basic/NASHORN-423a.js + test/script/basic/NASHORN-424.js + test/script/basic/NASHORN-424.js.EXPECTED + test/script/basic/NASHORN-425.js + test/script/basic/NASHORN-425.js.EXPECTED + test/script/basic/NASHORN-426.js + test/script/basic/NASHORN-427.js + test/script/basic/NASHORN-428.js + test/script/basic/NASHORN-429.js + test/script/basic/NASHORN-432.js + test/script/basic/NASHORN-433.js + test/script/basic/NASHORN-434.js + test/script/basic/NASHORN-435.js + test/script/basic/NASHORN-437.js + test/script/basic/NASHORN-44.js + test/script/basic/NASHORN-44.js.EXPECTED + test/script/basic/NASHORN-441.js + test/script/basic/NASHORN-441.js.EXPECTED + test/script/basic/NASHORN-442.js + test/script/basic/NASHORN-443.js + test/script/basic/NASHORN-444.js + test/script/basic/NASHORN-444.js.EXPECTED + test/script/basic/NASHORN-445.js + test/script/basic/NASHORN-446.js + test/script/basic/NASHORN-447.js + test/script/basic/NASHORN-448.js + test/script/basic/NASHORN-449.js + test/script/basic/NASHORN-449.js.EXPECTED + test/script/basic/NASHORN-45.js + test/script/basic/NASHORN-45.js.EXPECTED + test/script/basic/NASHORN-450.js + test/script/basic/NASHORN-452.js + test/script/basic/NASHORN-459.js + test/script/basic/NASHORN-46.js + test/script/basic/NASHORN-46.js.EXPECTED + test/script/basic/NASHORN-462.js + test/script/basic/NASHORN-463.js + test/script/basic/NASHORN-468.js + test/script/basic/NASHORN-47.js + test/script/basic/NASHORN-473.js + test/script/basic/NASHORN-473.js.EXPECTED + test/script/basic/NASHORN-474.js + test/script/basic/NASHORN-474.js.EXPECTED + test/script/basic/NASHORN-478.js + test/script/basic/NASHORN-48.js + test/script/basic/NASHORN-48.js.EXPECTED + test/script/basic/NASHORN-481.js + test/script/basic/NASHORN-481.js.EXPECTED + test/script/basic/NASHORN-482.js + test/script/basic/NASHORN-484.js + test/script/basic/NASHORN-484.js.EXPECTED + test/script/basic/NASHORN-486.js + test/script/basic/NASHORN-487.js + test/script/basic/NASHORN-488.js + test/script/basic/NASHORN-49.js + test/script/basic/NASHORN-49.js.EXPECTED + test/script/basic/NASHORN-490.js + test/script/basic/NASHORN-494.js + test/script/basic/NASHORN-497.js + test/script/basic/NASHORN-498.js + test/script/basic/NASHORN-499.js + test/script/basic/NASHORN-50.js + test/script/basic/NASHORN-50.js.EXPECTED + test/script/basic/NASHORN-500.js + test/script/basic/NASHORN-503.js + test/script/basic/NASHORN-503.js.EXPECTED + test/script/basic/NASHORN-51.js + test/script/basic/NASHORN-51.js.EXPECTED + test/script/basic/NASHORN-511.js + test/script/basic/NASHORN-515.js + test/script/basic/NASHORN-515.js.EXPECTED + test/script/basic/NASHORN-516.js + test/script/basic/NASHORN-52.js + test/script/basic/NASHORN-534.js + test/script/basic/NASHORN-534.js.EXPECTED + test/script/basic/NASHORN-535.js + test/script/basic/NASHORN-535.js.EXPECTED + test/script/basic/NASHORN-544.js + test/script/basic/NASHORN-55.js + test/script/basic/NASHORN-554.js + test/script/basic/NASHORN-554.js.EXPECTED + test/script/basic/NASHORN-556.js + test/script/basic/NASHORN-556.js.EXPECTED + test/script/basic/NASHORN-56.js + test/script/basic/NASHORN-56.js.EXPECTED + test/script/basic/NASHORN-562.js + test/script/basic/NASHORN-565.js + test/script/basic/NASHORN-565.js.EXPECTED + test/script/basic/NASHORN-575.js + test/script/basic/NASHORN-575.js.EXPECTED + test/script/basic/NASHORN-58.js + test/script/basic/NASHORN-58.js.EXPECTED + test/script/basic/NASHORN-59.js + test/script/basic/NASHORN-59.js.EXPECTED + test/script/basic/NASHORN-592.js + test/script/basic/NASHORN-592.js.EXPECTED + test/script/basic/NASHORN-597.js + test/script/basic/NASHORN-597.js.EXPECTED + test/script/basic/NASHORN-60.js + test/script/basic/NASHORN-60.js.EXPECTED + test/script/basic/NASHORN-609.js + test/script/basic/NASHORN-609.js.EXPECTED + test/script/basic/NASHORN-61.js + test/script/basic/NASHORN-61.js.EXPECTED + test/script/basic/NASHORN-62.js + test/script/basic/NASHORN-62.js.EXPECTED + test/script/basic/NASHORN-620.js + test/script/basic/NASHORN-620.js.EXPECTED + test/script/basic/NASHORN-623.js + test/script/basic/NASHORN-623.js.EXPECTED + test/script/basic/NASHORN-627.js + test/script/basic/NASHORN-627.js.EXPECTED + test/script/basic/NASHORN-63.js + test/script/basic/NASHORN-631.js.EXPECTED + test/script/basic/NASHORN-637.js + test/script/basic/NASHORN-637.js.EXPECTED + test/script/basic/NASHORN-638.js + test/script/basic/NASHORN-638.js.EXPECTED + test/script/basic/NASHORN-639.js + test/script/basic/NASHORN-64.js + test/script/basic/NASHORN-642.js + test/script/basic/NASHORN-642.js.EXPECTED + test/script/basic/NASHORN-646.js + test/script/basic/NASHORN-653.js + test/script/basic/NASHORN-658.js + test/script/basic/NASHORN-659.js + test/script/basic/NASHORN-66.js + test/script/basic/NASHORN-66.js.EXPECTED + test/script/basic/NASHORN-664.js + test/script/basic/NASHORN-665.js + test/script/basic/NASHORN-67.js + test/script/basic/NASHORN-67.js.EXPECTED + test/script/basic/NASHORN-678.js + test/script/basic/NASHORN-68.js + test/script/basic/NASHORN-68.js.EXPECTED + test/script/basic/NASHORN-689.js + test/script/basic/NASHORN-689.js.EXPECTED + test/script/basic/NASHORN-69.js + test/script/basic/NASHORN-69.js.EXPECTED + test/script/basic/NASHORN-691.js + test/script/basic/NASHORN-691.js.EXPECTED + test/script/basic/NASHORN-694.js + test/script/basic/NASHORN-694.js.EXPECTED + test/script/basic/NASHORN-697.js + test/script/basic/NASHORN-703.js + test/script/basic/NASHORN-703.js.EXPECTED + test/script/basic/NASHORN-703a.js + test/script/basic/NASHORN-703a.js.EXPECTED + test/script/basic/NASHORN-705.js + test/script/basic/NASHORN-71.js + test/script/basic/NASHORN-71.js.EXPECTED + test/script/basic/NASHORN-710.js + test/script/basic/NASHORN-711.js + test/script/basic/NASHORN-711.js.EXPECTED + test/script/basic/NASHORN-72.js + test/script/basic/NASHORN-72.js.EXPECTED + test/script/basic/NASHORN-722.js + test/script/basic/NASHORN-73.js + test/script/basic/NASHORN-73.js.EXPECTED + test/script/basic/NASHORN-737.js + test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/NASHORN-74.js + test/script/basic/NASHORN-74.js.EXPECTED + test/script/basic/NASHORN-740.js + test/script/basic/NASHORN-740.js.EXPECTED + test/script/basic/NASHORN-75.js + test/script/basic/NASHORN-75.js.EXPECTED + test/script/basic/NASHORN-758.js + test/script/basic/NASHORN-759.js + test/script/basic/NASHORN-759.js.EXPECTED + test/script/basic/NASHORN-760.js + test/script/basic/NASHORN-768.js + test/script/basic/NASHORN-778.js + test/script/basic/NASHORN-78.js + test/script/basic/NASHORN-79.js + test/script/basic/NASHORN-79.js.EXPECTED + test/script/basic/NASHORN-792.js + test/script/basic/NASHORN-792.js.EXPECTED + test/script/basic/NASHORN-80.js + test/script/basic/NASHORN-80.js.EXPECTED + test/script/basic/NASHORN-81.js + test/script/basic/NASHORN-833.js + test/script/basic/NASHORN-833.js.EXPECTED + test/script/basic/NASHORN-85.js + test/script/basic/NASHORN-85.js.EXPECTED + test/script/basic/NASHORN-86.js + test/script/basic/NASHORN-87.js + test/script/basic/NASHORN-89.js + test/script/basic/NASHORN-90.js + test/script/basic/NASHORN-90.js.EXPECTED + test/script/basic/NASHORN-91.js + test/script/basic/NASHORN-91.js.EXPECTED + test/script/basic/NASHORN-92.js + test/script/basic/NASHORN-92.js.EXPECTED + test/script/basic/NASHORN-93.js + test/script/basic/NASHORN-95.js + test/script/basic/NASHORN-95.js.EXPECTED + test/script/basic/NASHORN-96.js + test/script/basic/NASHORN-96.js.EXPECTED + test/script/basic/NASHORN-97.js + test/script/basic/NASHORN-98.js + test/script/basic/NASHORN-98.js.EXPECTED + test/script/basic/NASHORN-99.js + test/script/basic/addition.js + test/script/basic/addition.js.EXPECTED + test/script/basic/allgettersetters.js + test/script/basic/andor.js + test/script/basic/andor.js.EXPECTED + test/script/basic/anonrecur.js + test/script/basic/anonrecur.js.EXPECTED + test/script/basic/applycall.js + test/script/basic/applycall.js.EXPECTED + test/script/basic/args.js + test/script/basic/args.js.EXPECTED + test/script/basic/arity.js + test/script/basic/arity.js.EXPECTED + test/script/basic/arrayprotoclass.js + test/script/basic/arrayprotoclass.js.EXPECTED + test/script/basic/arrays.js + test/script/basic/arrays.js.EXPECTED + test/script/basic/arrays2.js + test/script/basic/arrays2.js.EXPECTED + test/script/basic/arraysIntKey.js + test/script/basic/arraysIntKey.js.EXPECTED + test/script/basic/arrayset.js + test/script/basic/arrayset.js.EXPECTED + test/script/basic/arrayundefined.js + test/script/basic/arrayundefined.js.EXPECTED + test/script/basic/assign.js + test/script/basic/assign.js.EXPECTED + test/script/basic/bitwise_and.js + test/script/basic/bitwise_and.js.EXPECTED + test/script/basic/booleangetter.js + test/script/basic/booleangetter.js.EXPECTED + test/script/basic/builtin.js + test/script/basic/builtin.js.EXPECTED + test/script/basic/builtin_assign.js + test/script/basic/builtin_assign.js.EXPECTED + test/script/basic/builtinchain.js + test/script/basic/builtinchain.js.EXPECTED + test/script/basic/calllink.js + test/script/basic/calllink.js.EXPECTED + test/script/basic/closure.js + test/script/basic/closure.js.EXPECTED + test/script/basic/commandargs.js + test/script/basic/commandargs.js.EXPECTED + test/script/basic/compile-octane.js + test/script/basic/compile-octane.js.EXPECTED + test/script/basic/condassign.js + test/script/basic/condassign.js.EXPECTED + test/script/basic/construct.js + test/script/basic/construct.js.EXPECTED + test/script/basic/constructorname.js + test/script/basic/constructorname.js.EXPECTED + test/script/basic/date.js + test/script/basic/date.js.EXPECTED + test/script/basic/dateparse.js + test/script/basic/dateparse.js.EXPECTED + test/script/basic/decinc.js + test/script/basic/decinc.js.EXPECTED + test/script/basic/delete.js + test/script/basic/delete.js.EXPECTED + test/script/basic/delete2.js + test/script/basic/delete2.js.EXPECTED + test/script/basic/dotpropname.js + test/script/basic/dotpropname.js.EXPECTED + test/script/basic/doublecache.js + test/script/basic/doublecache.js.EXPECTED + test/script/basic/enumeration.js + test/script/basic/enumeration.js.EXPECTED + test/script/basic/errors.js + test/script/basic/errors.js.EXPECTED + test/script/basic/errorstack.js + test/script/basic/errorstack.js.EXPECTED + test/script/basic/eval.js + test/script/basic/eval.js.EXPECTED + test/script/basic/evalreturn.js + test/script/basic/evalreturn.js.EXPECTED + test/script/basic/exprclosure.js + test/script/basic/exprclosure.js.EXPECTED + test/script/basic/extensibility.js + test/script/basic/extensibility.js.EXPECTED + test/script/basic/fileline.js + test/script/basic/fileline.js.EXPECTED + test/script/basic/finally-catchalls.js + test/script/basic/finally-catchalls.js.EXPECTED + test/script/basic/finallyreturn.js + test/script/basic/finallyreturn.js.EXPECTED + test/script/basic/forin.js + test/script/basic/forin.js.EXPECTED + test/script/basic/forin2.js + test/script/basic/forin2.js.EXPECTED + test/script/basic/funcarray.js + test/script/basic/funcarray.js.EXPECTED + test/script/basic/funcbind.js + test/script/basic/funcbind.js.EXPECTED + test/script/basic/funcconstructor.js + test/script/basic/funcconstructor.js.EXPECTED + test/script/basic/getclassname.js + test/script/basic/getenv.js + test/script/basic/getenv.js.EXPECTED + test/script/basic/getter_callsite.js + test/script/basic/getter_callsite.js.EXPECTED + test/script/basic/gettercalls.js + test/script/basic/gettercalls.js.EXPECTED + test/script/basic/getterfunc.js + test/script/basic/getterfunc.js.EXPECTED + test/script/basic/gettersetter.js + test/script/basic/gettersetter.js.EXPECTED + test/script/basic/globalaccess.js + test/script/basic/globalaccess.js.EXPECTED + test/script/basic/globals.js + test/script/basic/globals.js.EXPECTED + test/script/basic/globalscope.js + test/script/basic/globalscope.js.EXPECTED + test/script/basic/hello.js + test/script/basic/hello.js.EXPECTED + test/script/basic/herestr_operator.js + test/script/basic/herestr_operator.js.EXPECTED + test/script/basic/illegaljavaname.js + test/script/basic/illegaljavaname.js.EXPECTED + test/script/basic/incheck.js + test/script/basic/incheck.js.EXPECTED + test/script/basic/indexedcall.js + test/script/basic/indexedcall.js.EXPECTED + test/script/basic/info.js + test/script/basic/info.js.EXPECTED + test/script/basic/inherited_nonwritable.js + test/script/basic/instanceof.js + test/script/basic/instanceof.js.EXPECTED + test/script/basic/instanceof2.js + test/script/basic/instanceof2.js.EXPECTED + test/script/basic/interfaces.js + test/script/basic/interfaces.js.EXPECTED + test/script/basic/iterator.js + test/script/basic/iterator.js.EXPECTED + test/script/basic/java.js + test/script/basic/java.js.EXPECTED + test/script/basic/javaarray.js + test/script/basic/javaarray.js.EXPECTED + test/script/basic/javaarrayconversion.js + test/script/basic/javaarrayconversion.js.EXPECTED + test/script/basic/javaexceptions.js + test/script/basic/javaexceptions.js.EXPECTED + test/script/basic/javaimporter.js + test/script/basic/javaimporter.js.EXPECTED + test/script/basic/javainnerclasses.js + test/script/basic/javainnerclasses.js.EXPECTED + test/script/basic/javasigcall.js + test/script/basic/javasigcall.js.EXPECTED + test/script/basic/jquery.js + test/script/basic/jquery.js.EXPECTED + test/script/basic/jsadapter.js + test/script/basic/jsadapter.js.EXPECTED + test/script/basic/jsadapterlink.js + test/script/basic/jsadapterlink.js.EXPECTED + test/script/basic/json.js + test/script/basic/json.js.EXPECTED + test/script/basic/list.js + test/script/basic/list.js.EXPECTED + test/script/basic/literal.js + test/script/basic/literal.js.EXPECTED + test/script/basic/load.js + test/script/basic/load.js.EXPECTED + test/script/basic/loadedfile.js + test/script/basic/localundef.js + test/script/basic/localundef.js.EXPECTED + test/script/basic/map.js + test/script/basic/map.js.EXPECTED + test/script/basic/math.js + test/script/basic/math.js.EXPECTED + test/script/basic/minuszero.js + test/script/basic/minuszero.js.EXPECTED + test/script/basic/module.js + test/script/basic/moduleload.js + test/script/basic/moduleload.js.EXPECTED + test/script/basic/nashorn2.js + test/script/basic/nashorn2.js.EXPECTED + test/script/basic/natives.js + test/script/basic/natives.js.EXPECTED + test/script/basic/new.js + test/script/basic/new.js.EXPECTED + test/script/basic/newexpr.js + test/script/basic/newexpr.js.EXPECTED + test/script/basic/newnew.js + test/script/basic/newnew.js.EXPECTED + test/script/basic/nonconstructors.js + test/script/basic/nonconstructors.js.EXPECTED + test/script/basic/nosuchmethod.js + test/script/basic/nosuchmethod.js.EXPECTED + test/script/basic/nosuchproperty.js + test/script/basic/nosuchproperty.js.EXPECTED + test/script/basic/number.js + test/script/basic/number.js.EXPECTED + test/script/basic/numberstring.js + test/script/basic/numberstring.js.EXPECTED + test/script/basic/objectprops.js + test/script/basic/objectprops.js.EXPECTED + test/script/basic/objects.js + test/script/basic/objects.js.EXPECTED + test/script/basic/options.js + test/script/basic/options.js.EXPECTED + test/script/basic/propchange.js + test/script/basic/propchange.js.EXPECTED + test/script/basic/propertycheck.js + test/script/basic/propertycheck.js.EXPECTED + test/script/basic/proto.js.EXPECTED + test/script/basic/prototype.js + test/script/basic/prototype.js.EXPECTED + test/script/basic/pushpull.js + test/script/basic/pushpull.js.EXPECTED + test/script/basic/regex.js + test/script/basic/regex.js.EXPECTED + test/script/basic/regexp_flags.js + test/script/basic/run-octane.js + test/script/basic/runsunspider.js + test/script/basic/runsunspider.js.EXPECTED + test/script/basic/samfunc.js + test/script/basic/samfunc.js.EXPECTED + test/script/basic/scripting.js + test/script/basic/scripting.js.EXPECTED + test/script/basic/sealfreeze.js + test/script/basic/sealfreeze.js.EXPECTED + test/script/basic/setlength.js + test/script/basic/setlength.js.EXPECTED + test/script/basic/stdin.js + test/script/basic/stdin.js.EXPECTED + test/script/basic/strings.js + test/script/basic/strings.js.EXPECTED + test/script/basic/throws.js + test/script/basic/throws.js.EXPECTED + test/script/basic/tosource.js + test/script/basic/tosource.js.EXPECTED + test/script/basic/tostring.js + test/script/basic/tostring.js.EXPECTED + test/script/basic/try.js + test/script/basic/try.js.EXPECTED + test/script/basic/trybreakcont.js + test/script/basic/trybreakcont.js.EXPECTED + test/script/basic/trycatch.js + test/script/basic/trycatch.js.EXPECTED + test/script/basic/trycatchfor.js + test/script/basic/trycatchfor.js.EXPECTED + test/script/basic/tryfinallyreturn.js + test/script/basic/tryfinallyreturn.js.EXPECTED + test/script/basic/tryforbreak.js + test/script/basic/tryforbreak.js.EXPECTED + test/script/basic/typechange.js + test/script/basic/typechange.js.EXPECTED + test/script/basic/typeof.js + test/script/basic/typeof.js.EXPECTED + test/script/basic/typeof2.js + test/script/basic/typeof2.js.EXPECTED + test/script/basic/undefined.js + test/script/basic/undefined.js.EXPECTED + test/script/basic/underscore.js + test/script/basic/underscore.js.EXPECTED + test/script/basic/varargs.js + test/script/basic/varargs.js.EXPECTED + test/script/basic/void.js + test/script/basic/void.js.EXPECTED + test/script/basic/with.js + test/script/basic/with.js.EXPECTED + test/script/basic/withprimitive.js + test/script/basic/withprimitive.js.EXPECTED + test/script/basic/writable_relink.js + test/script/basic/writable_relink.js.EXPECTED + test/script/basic/xmlStrings.js.EXPECTED + test/script/basic/xorassign.js + test/script/basic/xorassign.js.EXPECTED + test/script/basic/yui.js + test/script/basic/yui.js.EXPECTED + test/script/error/NASHORN-154/README + test/script/error/NASHORN-154/function_mult_params_in_strict.js + test/script/error/NASHORN-154/function_mult_params_in_strict.js.EXPECTED + test/script/error/NASHORN-154/improper_return_break_continue.js + test/script/error/NASHORN-154/improper_return_break_continue.js.EXPECTED + test/script/error/NASHORN-154/invalid_lvalue.js + test/script/error/NASHORN-154/invalid_lvalue.js.EXPECTED + test/script/error/NASHORN-154/literal_data_and_accessor.js + test/script/error/NASHORN-154/literal_data_and_accessor.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_getters.js + test/script/error/NASHORN-154/literal_mult_getters.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js.EXPECTED + test/script/error/NASHORN-154/with_in_strict.js + test/script/error/NASHORN-154/with_in_strict.js.EXPECTED + test/script/error/NASHORN-214.js + test/script/error/NASHORN-214.js.EXPECTED + test/script/error/NASHORN-35.js + test/script/error/NASHORN-35.js.EXPECTED + test/script/error/NASHORN-39.js + test/script/error/NASHORN-39.js.EXPECTED + test/script/error/NASHORN-568.js + test/script/error/NASHORN-568.js.EXPECTED + test/script/error/NASHORN-57.js + test/script/error/NASHORN-57.js.EXPECTED + test/script/error/NASHORN-668.js + test/script/error/NASHORN-668.js.EXPECTED + test/script/error/quotemissing.js + test/script/error/quotemissing.js.EXPECTED + test/script/error/strictmode.js + test/script/error/strictmode.js.EXPECTED + test/script/representations/NASHORN-592a.js + test/script/sandbox/NASHORN-525.js + test/script/sandbox/README + test/script/sandbox/classloader.js + test/script/sandbox/classloader.js.EXPECTED + test/script/sandbox/doprivileged.js + test/script/sandbox/doprivileged.js.EXPECTED + test/script/sandbox/exit.js + test/script/sandbox/exit.js.EXPECTED + test/script/sandbox/file.js + test/script/sandbox/file.js.EXPECTED + test/script/sandbox/javaextend.js + test/script/sandbox/javaextend.js.EXPECTED + test/script/sandbox/loadLibrary.js + test/script/sandbox/net.js + test/script/sandbox/net.js.EXPECTED + test/script/sandbox/property.js + test/script/sandbox/property.js.EXPECTED + test/script/sandbox/reflection.js + test/script/sandbox/reflection.js.EXPECTED + test/script/sandbox/runnable.js + test/script/sandbox/runnable.js.EXPECTED + test/script/sandbox/unsafe.js + test/script/sandbox/unsafe.js.EXPECTED + test/script/test262.js + test/script/test262_single.js + test/src/UnnamedPackageTestCallback.java + test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/Window.java + test/src/jdk/nashorn/api/scripting/WindowEventHandler.java + test/src/jdk/nashorn/internal/access/BooleanAccessTest.java + test/src/jdk/nashorn/internal/access/MethodAccessTest.java + test/src/jdk/nashorn/internal/access/NumberAccessTest.java + test/src/jdk/nashorn/internal/access/NumberBoxingTest.java + test/src/jdk/nashorn/internal/access/ObjectAccessTest.java + test/src/jdk/nashorn/internal/access/Person.java + test/src/jdk/nashorn/internal/access/SharedObject.java + test/src/jdk/nashorn/internal/access/StringAccessTest.java + test/src/jdk/nashorn/internal/codegen/CompilerTest.java + test/src/jdk/nashorn/internal/parser/ParserTest.java + test/src/jdk/nashorn/internal/performance/AuroraWrapper.java + test/src/jdk/nashorn/internal/performance/OctaneTest.java + test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java + test/src/jdk/nashorn/internal/performance/SplayTest.java + test/src/jdk/nashorn/internal/runtime/ContextTest.java + test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java + test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java + test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java + test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java + test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java + test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/ScriptTest.java + test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/TestConfig.java + test/src/jdk/nashorn/internal/test/framework/TestFinder.java + test/src/jdk/nashorn/internal/test/framework/TestHelper.java + test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java + test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/internal/test/models/FinalClass.java + test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/internal/test/models/NonPublicClass.java + test/src/jdk/nashorn/internal/test/models/OuterClass.java + test/src/jdk/nashorn/internal/test/models/OverloadedSam.java + test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: b4b05457b8b2 Author: jlaskey Date: 2012-12-22 08:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b4b05457b8b2 8005440: Improve .hgignore filtering for Nashorn repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: 3a7e1580bc0a Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3a7e1580bc0a 8005666: Add webrev to .hgignore Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: c6e194450af7 Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c6e194450af7 8005665: JavaDoc should only display public interfaces Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/build.xml Changeset: 5a1b0714df0e Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5a1b0714df0e 8005663: Update copyright year to 2013 Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! bin/checkintest.sh ! bin/fixorphantests.sh ! bin/fixwhitespace.sh ! bin/jjs ! bin/jjs.bat ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashorn ! bin/nashorn.bat ! bin/rm-non-tracked.sh ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! buildtools/nasgen/build.xml ! buildtools/nasgen/nasgen.iml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! docs/genshelldoc.js ! make/Makefile ! make/build-benchmark.xml ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-file-targets.xml ! make/nbproject/ide-targets.xml ! make/nbproject/jdk.xml ! make/nbproject/nbjdk.properties ! make/nbproject/nbjdk.xml ! make/nbproject/project.xml ! make/project.properties ! samples/counters.js ! samples/letter.js ! samples/parser.js ! samples/shell.js ! samples/test.js ! samples/uniq.js ! src/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/package-info.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/Emitter.java ! src/jdk/nashorn/internal/codegen/Frame.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/ArrayType.java ! src/jdk/nashorn/internal/codegen/types/BitwiseType.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeOps.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/codegen/types/NumericType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyKey.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/annotations/ChildNode.java ! src/jdk/nashorn/internal/ir/annotations/Ignore.java ! src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/annotations/Attribute.java ! src/jdk/nashorn/internal/objects/annotations/Constructor.java ! src/jdk/nashorn/internal/objects/annotations/Function.java ! src/jdk/nashorn/internal/objects/annotations/Getter.java ! src/jdk/nashorn/internal/objects/annotations/Property.java ! src/jdk/nashorn/internal/objects/annotations/ScriptClass.java ! src/jdk/nashorn/internal/objects/annotations/Setter.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk/nashorn/internal/objects/annotations/Where.java ! src/jdk/nashorn/internal/objects/package-info.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/RegExp.java ! src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/parser/Token.java ! src/jdk/nashorn/internal/parser/TokenKind.java ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenStream.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSErrorType.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/NumberToString.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/Version.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Mangler.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/options/ValueOption.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! src/jdk/nashorn/internal/runtime/resources/version.properties-template ! src/jdk/nashorn/internal/scripts/JO$.java ! src/jdk/nashorn/internal/scripts/JS$.java ! src/jdk/nashorn/tools/Shell.java ! src/jdk/nashorn/tools/resources/Shell.properties ! src/jdk/nashorn/tools/resources/shell.js ! src/netscape/javascript/JSObject.java ! src/overview.html ! test/examples/dual-fields-micro.js ! test/examples/innerbench.js ! test/examples/typechain.js ! test/lib/benchmark.js ! test/opt/add.js ! test/opt/add_constant.js ! test/opt/add_reuse_callsite.js ! test/opt/add_revert2.js ! test/opt/cascade_specialize.js ! test/script/assert.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-101.js ! test/script/basic/NASHORN-102.js ! test/script/basic/NASHORN-103.js ! test/script/basic/NASHORN-104.js ! test/script/basic/NASHORN-105.js ! test/script/basic/NASHORN-106.js ! test/script/basic/NASHORN-107.js ! test/script/basic/NASHORN-108.js ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-11.js ! test/script/basic/NASHORN-111.js ! test/script/basic/NASHORN-113.js ! test/script/basic/NASHORN-114.js ! test/script/basic/NASHORN-115.js ! test/script/basic/NASHORN-117.js ! test/script/basic/NASHORN-118.js ! test/script/basic/NASHORN-119.js ! test/script/basic/NASHORN-12.js ! test/script/basic/NASHORN-120.js ! test/script/basic/NASHORN-122.js ! test/script/basic/NASHORN-126.js ! test/script/basic/NASHORN-127.js ! test/script/basic/NASHORN-130.js ! test/script/basic/NASHORN-132.js ! test/script/basic/NASHORN-133.js ! test/script/basic/NASHORN-135.js ! test/script/basic/NASHORN-136.js ! test/script/basic/NASHORN-14.js ! test/script/basic/NASHORN-148.js ! test/script/basic/NASHORN-15.js ! test/script/basic/NASHORN-153.js ! test/script/basic/NASHORN-156.js ! test/script/basic/NASHORN-157.js ! test/script/basic/NASHORN-163.js ! test/script/basic/NASHORN-164.js ! test/script/basic/NASHORN-165.js ! test/script/basic/NASHORN-166.js ! test/script/basic/NASHORN-168.js ! test/script/basic/NASHORN-169.js ! test/script/basic/NASHORN-172.js ! test/script/basic/NASHORN-173.js ! test/script/basic/NASHORN-174.js ! test/script/basic/NASHORN-175.js ! test/script/basic/NASHORN-176.js ! test/script/basic/NASHORN-177.js ! test/script/basic/NASHORN-178.js ! test/script/basic/NASHORN-179.js ! test/script/basic/NASHORN-18.js ! test/script/basic/NASHORN-181.js ! test/script/basic/NASHORN-182.js ! test/script/basic/NASHORN-183.js ! test/script/basic/NASHORN-184.js ! test/script/basic/NASHORN-185.js ! test/script/basic/NASHORN-187.js ! test/script/basic/NASHORN-188.js ! test/script/basic/NASHORN-19.js ! test/script/basic/NASHORN-190.js ! test/script/basic/NASHORN-192.js ! test/script/basic/NASHORN-194.js ! test/script/basic/NASHORN-196.js ! test/script/basic/NASHORN-198.js ! test/script/basic/NASHORN-20.js ! test/script/basic/NASHORN-201.js ! test/script/basic/NASHORN-202.js ! test/script/basic/NASHORN-203.js ! test/script/basic/NASHORN-204.js ! test/script/basic/NASHORN-205.js ! test/script/basic/NASHORN-206.js ! test/script/basic/NASHORN-207.js ! test/script/basic/NASHORN-207_2.js ! test/script/basic/NASHORN-208.js ! test/script/basic/NASHORN-209.js ! test/script/basic/NASHORN-21.js ! test/script/basic/NASHORN-211.js ! test/script/basic/NASHORN-212.js ! test/script/basic/NASHORN-213.js ! test/script/basic/NASHORN-215.js ! test/script/basic/NASHORN-216.js ! test/script/basic/NASHORN-217.js ! test/script/basic/NASHORN-219.js ! test/script/basic/NASHORN-22.js ! test/script/basic/NASHORN-221.js ! test/script/basic/NASHORN-222.js ! test/script/basic/NASHORN-223.js ! test/script/basic/NASHORN-225.js ! test/script/basic/NASHORN-226.js ! test/script/basic/NASHORN-227.js ! test/script/basic/NASHORN-228.js ! test/script/basic/NASHORN-229.js ! test/script/basic/NASHORN-229_subtest.js ! test/script/basic/NASHORN-23.js ! test/script/basic/NASHORN-232.js ! test/script/basic/NASHORN-234.js ! test/script/basic/NASHORN-235.js ! test/script/basic/NASHORN-236.js ! test/script/basic/NASHORN-237.js ! test/script/basic/NASHORN-239.js ! test/script/basic/NASHORN-24.js ! test/script/basic/NASHORN-241.js ! test/script/basic/NASHORN-242.js ! test/script/basic/NASHORN-245.js ! test/script/basic/NASHORN-247.js ! test/script/basic/NASHORN-25.js ! test/script/basic/NASHORN-251.js ! test/script/basic/NASHORN-252.js ! test/script/basic/NASHORN-253.js ! test/script/basic/NASHORN-256.js ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-26.js ! test/script/basic/NASHORN-260.js ! test/script/basic/NASHORN-261.js ! test/script/basic/NASHORN-262.js ! test/script/basic/NASHORN-263.js ! test/script/basic/NASHORN-264.js ! test/script/basic/NASHORN-265.js ! test/script/basic/NASHORN-266.js ! test/script/basic/NASHORN-269.js ! test/script/basic/NASHORN-27.js ! test/script/basic/NASHORN-270.js ! test/script/basic/NASHORN-271.js ! test/script/basic/NASHORN-275.js ! test/script/basic/NASHORN-276.js ! test/script/basic/NASHORN-277.js ! test/script/basic/NASHORN-278.js ! test/script/basic/NASHORN-28.js ! test/script/basic/NASHORN-281.js ! test/script/basic/NASHORN-284.js ! test/script/basic/NASHORN-285.js ! test/script/basic/NASHORN-288.js ! test/script/basic/NASHORN-29.js ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-294.js ! test/script/basic/NASHORN-296.js ! test/script/basic/NASHORN-297.js ! test/script/basic/NASHORN-30.js ! test/script/basic/NASHORN-300.js ! test/script/basic/NASHORN-301.js ! test/script/basic/NASHORN-304.js ! test/script/basic/NASHORN-310.js ! test/script/basic/NASHORN-318.js ! test/script/basic/NASHORN-32.js ! test/script/basic/NASHORN-321.js ! test/script/basic/NASHORN-323.js ! test/script/basic/NASHORN-324.js ! test/script/basic/NASHORN-33.js ! test/script/basic/NASHORN-331.js ! test/script/basic/NASHORN-337.js ! test/script/basic/NASHORN-34.js ! test/script/basic/NASHORN-340.js ! test/script/basic/NASHORN-349.js ! test/script/basic/NASHORN-354.js ! test/script/basic/NASHORN-355.js ! test/script/basic/NASHORN-36.js ! test/script/basic/NASHORN-365.js ! test/script/basic/NASHORN-366.js ! test/script/basic/NASHORN-368.js ! test/script/basic/NASHORN-37.js ! test/script/basic/NASHORN-375.js ! test/script/basic/NASHORN-376.js ! test/script/basic/NASHORN-377.js ! test/script/basic/NASHORN-378.js ! test/script/basic/NASHORN-38.js ! test/script/basic/NASHORN-380.js ! test/script/basic/NASHORN-381.js ! test/script/basic/NASHORN-382.js ! test/script/basic/NASHORN-383.js ! test/script/basic/NASHORN-384.js ! test/script/basic/NASHORN-385.js ! test/script/basic/NASHORN-389.js ! test/script/basic/NASHORN-393.js ! test/script/basic/NASHORN-394.js ! test/script/basic/NASHORN-396.js ! test/script/basic/NASHORN-397.js ! test/script/basic/NASHORN-398.js ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-400.js ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-402.js ! test/script/basic/NASHORN-404.js ! test/script/basic/NASHORN-405.js ! test/script/basic/NASHORN-406.js ! test/script/basic/NASHORN-408.js ! test/script/basic/NASHORN-415.js ! test/script/basic/NASHORN-416.js ! test/script/basic/NASHORN-417.js ! test/script/basic/NASHORN-418.js ! test/script/basic/NASHORN-420.js ! test/script/basic/NASHORN-421.js ! test/script/basic/NASHORN-423.js ! test/script/basic/NASHORN-423a.js ! test/script/basic/NASHORN-424.js ! test/script/basic/NASHORN-425.js ! test/script/basic/NASHORN-426.js ! test/script/basic/NASHORN-427.js ! test/script/basic/NASHORN-428.js ! test/script/basic/NASHORN-429.js ! test/script/basic/NASHORN-432.js ! test/script/basic/NASHORN-433.js ! test/script/basic/NASHORN-434.js ! test/script/basic/NASHORN-435.js ! test/script/basic/NASHORN-437.js ! test/script/basic/NASHORN-44.js ! test/script/basic/NASHORN-441.js ! test/script/basic/NASHORN-442.js ! test/script/basic/NASHORN-443.js ! test/script/basic/NASHORN-444.js ! test/script/basic/NASHORN-445.js ! test/script/basic/NASHORN-446.js ! test/script/basic/NASHORN-447.js ! test/script/basic/NASHORN-448.js ! test/script/basic/NASHORN-449.js ! test/script/basic/NASHORN-45.js ! test/script/basic/NASHORN-450.js ! test/script/basic/NASHORN-452.js ! test/script/basic/NASHORN-459.js ! test/script/basic/NASHORN-46.js ! test/script/basic/NASHORN-462.js ! test/script/basic/NASHORN-463.js ! test/script/basic/NASHORN-468.js ! test/script/basic/NASHORN-47.js ! test/script/basic/NASHORN-473.js ! test/script/basic/NASHORN-474.js ! test/script/basic/NASHORN-478.js ! test/script/basic/NASHORN-48.js ! test/script/basic/NASHORN-481.js ! test/script/basic/NASHORN-482.js ! test/script/basic/NASHORN-484.js ! test/script/basic/NASHORN-486.js ! test/script/basic/NASHORN-487.js ! test/script/basic/NASHORN-488.js ! test/script/basic/NASHORN-49.js ! test/script/basic/NASHORN-490.js ! test/script/basic/NASHORN-494.js ! test/script/basic/NASHORN-497.js ! test/script/basic/NASHORN-498.js ! test/script/basic/NASHORN-499.js ! test/script/basic/NASHORN-50.js ! test/script/basic/NASHORN-500.js ! test/script/basic/NASHORN-503.js ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-511.js ! test/script/basic/NASHORN-515.js ! test/script/basic/NASHORN-516.js ! test/script/basic/NASHORN-52.js ! test/script/basic/NASHORN-534.js ! test/script/basic/NASHORN-535.js ! test/script/basic/NASHORN-544.js ! test/script/basic/NASHORN-55.js ! test/script/basic/NASHORN-554.js ! test/script/basic/NASHORN-556.js ! test/script/basic/NASHORN-56.js ! test/script/basic/NASHORN-562.js ! test/script/basic/NASHORN-565.js ! test/script/basic/NASHORN-575.js ! test/script/basic/NASHORN-58.js ! test/script/basic/NASHORN-59.js ! test/script/basic/NASHORN-592.js ! test/script/basic/NASHORN-597.js ! test/script/basic/NASHORN-60.js ! test/script/basic/NASHORN-609.js ! test/script/basic/NASHORN-61.js ! test/script/basic/NASHORN-62.js ! test/script/basic/NASHORN-620.js ! test/script/basic/NASHORN-623.js ! test/script/basic/NASHORN-627.js ! test/script/basic/NASHORN-63.js ! test/script/basic/NASHORN-637.js ! test/script/basic/NASHORN-638.js ! test/script/basic/NASHORN-639.js ! test/script/basic/NASHORN-64.js ! test/script/basic/NASHORN-642.js ! test/script/basic/NASHORN-646.js ! test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-658.js ! test/script/basic/NASHORN-659.js ! test/script/basic/NASHORN-66.js ! test/script/basic/NASHORN-664.js ! test/script/basic/NASHORN-665.js ! test/script/basic/NASHORN-67.js ! test/script/basic/NASHORN-678.js ! test/script/basic/NASHORN-68.js ! test/script/basic/NASHORN-689.js ! test/script/basic/NASHORN-69.js ! test/script/basic/NASHORN-691.js ! test/script/basic/NASHORN-694.js ! test/script/basic/NASHORN-697.js ! test/script/basic/NASHORN-703.js ! test/script/basic/NASHORN-703a.js ! test/script/basic/NASHORN-705.js ! test/script/basic/NASHORN-71.js ! test/script/basic/NASHORN-710.js ! test/script/basic/NASHORN-711.js ! test/script/basic/NASHORN-72.js ! test/script/basic/NASHORN-722.js ! test/script/basic/NASHORN-73.js ! test/script/basic/NASHORN-737.js ! test/script/basic/NASHORN-74.js ! test/script/basic/NASHORN-740.js ! test/script/basic/NASHORN-75.js ! test/script/basic/NASHORN-758.js ! test/script/basic/NASHORN-759.js ! test/script/basic/NASHORN-760.js ! test/script/basic/NASHORN-768.js ! test/script/basic/NASHORN-778.js ! test/script/basic/NASHORN-78.js ! test/script/basic/NASHORN-79.js ! test/script/basic/NASHORN-792.js ! test/script/basic/NASHORN-80.js ! test/script/basic/NASHORN-81.js ! test/script/basic/NASHORN-833.js ! test/script/basic/NASHORN-85.js ! test/script/basic/NASHORN-86.js ! test/script/basic/NASHORN-87.js ! test/script/basic/NASHORN-89.js ! test/script/basic/NASHORN-90.js ! test/script/basic/NASHORN-91.js ! test/script/basic/NASHORN-92.js ! test/script/basic/NASHORN-93.js ! test/script/basic/NASHORN-95.js ! test/script/basic/NASHORN-96.js ! test/script/basic/NASHORN-97.js ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-99.js ! test/script/basic/addition.js ! test/script/basic/allgettersetters.js ! test/script/basic/andor.js ! test/script/basic/anonrecur.js ! test/script/basic/applycall.js ! test/script/basic/args.js ! test/script/basic/arity.js ! test/script/basic/arrayprotoclass.js ! test/script/basic/arrays.js ! test/script/basic/arrays2.js ! test/script/basic/arraysIntKey.js ! test/script/basic/arrayset.js ! test/script/basic/arrayundefined.js ! test/script/basic/assign.js ! test/script/basic/bitwise_and.js ! test/script/basic/booleangetter.js ! test/script/basic/builtin.js ! test/script/basic/builtin_assign.js ! test/script/basic/builtinchain.js ! test/script/basic/calllink.js ! test/script/basic/closure.js ! test/script/basic/commandargs.js ! test/script/basic/compile-octane.js ! test/script/basic/condassign.js ! test/script/basic/construct.js ! test/script/basic/constructorname.js ! test/script/basic/date.js ! test/script/basic/dateparse.js ! test/script/basic/decinc.js ! test/script/basic/delete.js ! test/script/basic/delete2.js ! test/script/basic/dotpropname.js ! test/script/basic/doublecache.js ! test/script/basic/enumeration.js ! test/script/basic/errors.js ! test/script/basic/errorstack.js ! test/script/basic/eval.js ! test/script/basic/evalreturn.js ! test/script/basic/exprclosure.js ! test/script/basic/extensibility.js ! test/script/basic/fileline.js ! test/script/basic/finally-catchalls.js ! test/script/basic/finallyreturn.js ! test/script/basic/forin.js ! test/script/basic/forin2.js ! test/script/basic/funcarray.js ! test/script/basic/funcbind.js ! test/script/basic/funcconstructor.js ! test/script/basic/getclassname.js ! test/script/basic/getenv.js ! test/script/basic/getter_callsite.js ! test/script/basic/gettercalls.js ! test/script/basic/getterfunc.js ! test/script/basic/gettersetter.js ! test/script/basic/globalaccess.js ! test/script/basic/globals.js ! test/script/basic/globalscope.js ! test/script/basic/hello.js ! test/script/basic/herestr_operator.js ! test/script/basic/illegaljavaname.js ! test/script/basic/incheck.js ! test/script/basic/indexedcall.js ! test/script/basic/info.js ! test/script/basic/inherited_nonwritable.js ! test/script/basic/instanceof.js ! test/script/basic/instanceof2.js ! test/script/basic/interfaces.js ! test/script/basic/iterator.js ! test/script/basic/java.js ! test/script/basic/javaarray.js ! test/script/basic/javaarrayconversion.js ! test/script/basic/javaexceptions.js ! test/script/basic/javaimporter.js ! test/script/basic/javainnerclasses.js ! test/script/basic/javasigcall.js ! test/script/basic/jquery.js ! test/script/basic/jsadapter.js ! test/script/basic/jsadapterlink.js ! test/script/basic/json.js ! test/script/basic/list.js ! test/script/basic/literal.js ! test/script/basic/load.js ! test/script/basic/loadedfile.js ! test/script/basic/localundef.js ! test/script/basic/map.js ! test/script/basic/math.js ! test/script/basic/minuszero.js ! test/script/basic/module.js ! test/script/basic/moduleload.js ! test/script/basic/nashorn2.js ! test/script/basic/natives.js ! test/script/basic/new.js ! test/script/basic/newexpr.js ! test/script/basic/newnew.js ! test/script/basic/nonconstructors.js ! test/script/basic/nosuchmethod.js ! test/script/basic/nosuchproperty.js ! test/script/basic/number.js ! test/script/basic/numberstring.js ! test/script/basic/objectprops.js ! test/script/basic/objects.js ! test/script/basic/options.js ! test/script/basic/propchange.js ! test/script/basic/propertycheck.js ! test/script/basic/prototype.js ! test/script/basic/pushpull.js ! test/script/basic/regex.js ! test/script/basic/regexp_flags.js ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/script/basic/samfunc.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED ! test/script/basic/sealfreeze.js ! test/script/basic/setlength.js ! test/script/basic/stdin.js ! test/script/basic/strings.js ! test/script/basic/throws.js ! test/script/basic/tosource.js ! test/script/basic/tostring.js ! test/script/basic/try.js ! test/script/basic/trybreakcont.js ! test/script/basic/trycatch.js ! test/script/basic/trycatchfor.js ! test/script/basic/tryfinallyreturn.js ! test/script/basic/tryforbreak.js ! test/script/basic/typechange.js ! test/script/basic/typeof.js ! test/script/basic/typeof2.js ! test/script/basic/undefined.js ! test/script/basic/underscore.js ! test/script/basic/varargs.js ! test/script/basic/void.js ! test/script/basic/with.js ! test/script/basic/withprimitive.js ! test/script/basic/writable_relink.js ! test/script/basic/xorassign.js ! test/script/basic/yui.js ! test/script/error/NASHORN-154/function_mult_params_in_strict.js ! test/script/error/NASHORN-154/improper_return_break_continue.js ! test/script/error/NASHORN-154/invalid_lvalue.js ! test/script/error/NASHORN-154/literal_data_and_accessor.js ! test/script/error/NASHORN-154/literal_mult_getters.js ! test/script/error/NASHORN-154/literal_mult_prop_in_strict.js ! test/script/error/NASHORN-154/with_in_strict.js ! test/script/error/NASHORN-214.js ! test/script/error/NASHORN-35.js ! test/script/error/NASHORN-39.js ! test/script/error/NASHORN-568.js ! test/script/error/NASHORN-57.js ! test/script/error/NASHORN-668.js ! test/script/error/quotemissing.js ! test/script/error/strictmode.js ! test/script/representations/NASHORN-592a.js ! test/script/sandbox/NASHORN-525.js ! test/script/sandbox/classloader.js ! test/script/sandbox/doprivileged.js ! test/script/sandbox/exit.js ! test/script/sandbox/file.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/loadLibrary.js ! test/script/sandbox/net.js ! test/script/sandbox/property.js ! test/script/sandbox/reflection.js ! test/script/sandbox/runnable.js ! test/script/sandbox/unsafe.js ! test/script/test262.js ! test/script/test262_single.js ! test/src/UnnamedPackageTestCallback.java ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/api/scripting/WindowEventHandler.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/access/MethodAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberBoxingTest.java ! test/src/jdk/nashorn/internal/access/ObjectAccessTest.java ! test/src/jdk/nashorn/internal/access/Person.java ! test/src/jdk/nashorn/internal/access/SharedObject.java ! test/src/jdk/nashorn/internal/access/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/performance/AuroraWrapper.java ! test/src/jdk/nashorn/internal/performance/OctaneTest.java ! test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java ! test/src/jdk/nashorn/internal/performance/SplayTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java ! test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptTest.java ! test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java ! test/src/jdk/nashorn/internal/test/framework/TestHelper.java ! test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java ! test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java ! test/src/jdk/nashorn/internal/test/models/FinalClass.java ! test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java ! test/src/jdk/nashorn/internal/test/models/NonPublicClass.java ! test/src/jdk/nashorn/internal/test/models/OuterClass.java ! test/src/jdk/nashorn/internal/test/models/OverloadedSam.java ! test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: 1e3f411f47bf Author: lagergren Date: 2013-01-07 19:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1e3f411f47bf 8005789: Forgot to document -Dnashorn.unstable.relink.threshold Summary: Added documentation to DEVELOPER_README, fixed code convention warnings Reviewed-by: attila ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: 41c7093477ae Author: jlaskey Date: 2013-01-07 14:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/41c7093477ae 8005703: Offsets miscalculated for blocks Reviewed-by: lagergren Contributed-by: petr.hejl at oracle.com ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: d14da0d0c577 Author: sundar Date: 2013-01-08 08:51 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d14da0d0c577 8005782: get rid of javadoc errors, warnings in nashorn build Reviewed-by: lagergren ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 0e7da548ef6a Author: lagergren Date: 2013-01-08 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/0e7da548ef6a 8005788: Loggers and their corresponding system properties not working correctly Summary: 1-1 mapping now maintained. Used Context err instead of System.err in several places (after bootstrapping Context). Problematic closing of err stream replaced by @SuppressWarnings("resource") Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 5f2db2d8a7fa Author: sundar Date: 2013-01-08 15:02 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5f2db2d8a7fa 8005835: NASHORN-668 output fails to compare with the corresponding .EXPECTED file Reviewed-by: lagergren, hannesw ! test/script/error/NASHORN-668.js.EXPECTED Changeset: d8e4d66f1a06 Author: lagergren Date: 2013-01-08 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d8e4d66f1a06 8005843: refSymbols lookup of unbound variable could cause NullPointerException in Lower Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/NASHORN-837.js Changeset: c5a321205f49 Author: attila Date: 2013-01-08 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c5a321205f49 8005846: Remove Mangler in favor of Dynalink's NameCodec Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 4620ac94e7dc Author: attila Date: 2013-01-08 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4620ac94e7dc 8005801: Refactor findSetMethod Summary: findSetMethod() was a very large single method, very unreadable and unmaintainable. It was broken into easy-to-understand pieces. The refactoring required introduction of a comand-object like entity, SetMethodCreator, to contain the nontrivial transient state of the algorithm that made the original big method so resistant to refactoring in the first place. Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java - src/jdk/nashorn/internal/runtime/linker/Mangler.java Changeset: 69a4f0363d0f Author: lagergren Date: 2013-01-08 15:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/69a4f0363d0f 8005842: Loops in ASTWriter. Corrected @Reference and @Ignore node annotation for IR nodes Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java Changeset: 548587cfb065 Author: sundar Date: 2013-01-08 21:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/548587cfb065 8005848: assigning to global toString variable affects Object.prototype.toString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK_8005848.js Changeset: 812b9963b1c7 Author: attila Date: 2013-01-09 15:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/812b9963b1c7 8005777: Bug in the FacetIntrospector of Dynalink - non-public class should search super Reviewed-by: lagergren, sundar ! make/project.properties Changeset: 4cd65798ec70 Author: sundar Date: 2013-01-09 22:32 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4cd65798ec70 8005940: provide ant targets to get and update external test scripts Reviewed-by: jlaskey, lagergren ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! make/Makefile ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 9f59ba5090f2 Author: lagergren Date: 2013-01-10 10:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9f59ba5090f2 8005971: runsunspider.js should check results of benchmarks Reviewed-by: attila, hannesw ! test/script/basic/runsunspider.js Changeset: a7f177d6639c Author: sundar Date: 2013-01-10 19:03 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a7f177d6639c 8005987: ant octane tries to run non-benchmark scripts Reviewed-by: lagergren, attila, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 0362d36d3dd6 Author: sundar Date: 2013-01-10 19:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/0362d36d3dd6 8005982: NASHORN-71.js failing in nightlys Reviewed-by: attila, lagergren, jlaskey ! test/script/basic/NASHORN-71.js - test/script/basic/NASHORN-71.js.EXPECTED Changeset: 2a5c2258827b Author: attila Date: 2013-01-10 15:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/2a5c2258827b 8005983: JavaAdapterFactory generated proxy classes should take extra constructor arguments at the end Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED Changeset: 2a4769fcd13f Author: lagergren Date: 2013-01-11 10:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/2a4769fcd13f 8005976: Break out AccessSpecializer into one pass before CodeGenerator instead of iterative applications from CodeGenerator Summary: Now scope and slot information is guaranteed to be fixed AND NOT CHANGE before CodeGeneration. We want to keep it that way to build future type specializations and bring all type work out of CodeGenerator. Reviewed-by: attila, hannesw + bin/dump_octane_code.sh ! bin/verbose_octane.sh ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f67bf56495ca Author: sundar Date: 2013-01-11 18:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f67bf56495ca 8006082: Provide option to run octane benchmarks in separate processes Reviewed-by: lagergren, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 8a5922638ff0 Author: sundar Date: 2013-01-11 20:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8a5922638ff0 8006093: Add a makefile target to run all tests (test, test262, perf tests) Reviewed-by: attila, hannesw ! make/Makefile ! make/build.xml Changeset: eda69555239a Author: attila Date: 2013-01-14 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/eda69555239a 8006168: ability to generate multi-type Java adapters Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED + test/src/jdk/nashorn/internal/test/models/DessertTopping.java + test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/internal/test/models/FloorWax.java + test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 3c6db5ea0ecc Author: sundar Date: 2013-01-14 21:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3c6db5ea0ecc 8006181: nashorn script engine does not run jrunscript's initialization script Reviewed-by: lagergren, jlaskey Contributed-by: rieberandreas at gmail.com + src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/api/scripting/resources/init.js Changeset: 1d0307c2bb4c Author: attila Date: 2013-01-15 13:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1d0307c2bb4c 8006293: Reduce ScriptObject.findCallMethodMethod Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java Changeset: ee73d7378e3e Author: attila Date: 2013-01-15 17:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ee73d7378e3e 8005958: invoking a function through INVOKESTATIC with more arguments than it declares resulted in malformed bytecode being generated Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8005958.js Changeset: 9088170e68df Author: attila Date: 2013-01-15 18:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9088170e68df 8006337: Discarded arguments for INVOKESTATIC must still be evaluated for side effects Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006337.js + test/script/basic/JDK-8006337.js.EXPECTED Changeset: 617313881c55 Author: jlaskey Date: 2013-01-16 07:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/617313881c55 8006304: Remove pre-population of maps for constructor produced maps Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + test/script/basic/JDK-8006304.js + test/script/basic/JDK-8006304.js.EXPECTED Changeset: 80447df16322 Author: sundar Date: 2013-01-16 17:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/80447df16322 8006412: Improve toString method of ScriptObjectMirror class Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cd5b684ce7b2 Author: sundar Date: 2013-01-16 21:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/cd5b684ce7b2 8006424: Passing null or undefined to adapter class constructors results in NPE or ClassCastException Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/basic/JDK-8006424.js Changeset: 4acebfe9e504 Author: jlaskey Date: 2013-01-17 10:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4acebfe9e504 8006517: PropertyHashMap.Element.equals() compares to Property Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java Changeset: f8136c060914 Author: sundar Date: 2013-01-18 08:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f8136c060914 8006527: nashorn jsr223 engine does not work in sandbox Reviewed-by: jlaskey, attila, lagergren + bin/nashornsecure + bin/nashornsecure.bat ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/sandbox/engine.js + test/script/sandbox/engine.js.EXPECTED + test/script/sandbox/jsadapter.js Changeset: 4361e8cd6a02 Author: sundar Date: 2013-01-18 17:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4361e8cd6a02 8006562: findOwnMH in nashorn "objects" package should be cleaned up Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java Changeset: c887baec012a Author: sundar Date: 2013-01-19 09:14 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c887baec012a 8006584: improve variable handling in NashornScriptEngine Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a8966074d4e9 Author: sundar Date: 2013-01-19 22:35 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a8966074d4e9 8006557: JDK8/Lambda build clashes on Map.replace() Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 0cee498b330d Author: attila Date: 2013-01-21 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/0cee498b330d 8006525: Give StaticClass objects their own linker Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 8b3cc4ad1810 Author: sundar Date: 2013-01-21 21:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8b3cc4ad1810 8006635: Reduce access levels as much as possible Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 935dcec38e9a Author: hannesw Date: 2013-01-22 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/935dcec38e9a 8006570: This-value for non-strict functions should be converted to object Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8006570.js + test/script/basic/JDK-8006570.js.EXPECTED Changeset: e43d1013d871 Author: attila Date: 2013-01-22 14:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e43d1013d871 8006677: Remove unused FunctionNode flags Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: e62dba3ce52b Author: sundar Date: 2013-01-22 22:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e62dba3ce52b 8006678: Avoid too many Context.getGlobal() calls Reviewed-by: lagergren, jlaskey ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 0dbcb7350595 Author: sundar Date: 2013-01-23 17:04 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/0dbcb7350595 8006736: nashorn script engine should support the usage multiple global objects with same engine instance Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: d4a968ca8953 Author: sundar Date: 2013-01-24 16:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d4a968ca8953 8006575: Error in codegen for element access on primitive value Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006575.js Changeset: 3f528769aee1 Author: sundar Date: 2013-01-24 17:49 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3f528769aee1 8006755: Functions inside with statements dont get correct scope Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8006755.js Changeset: edfa73d9fde7 Author: hannesw Date: 2013-01-24 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/edfa73d9fde7 8006408: Clean up and specialize NativeString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/examples/string-micro.js Changeset: f336aee22e85 Author: jlaskey Date: 2013-01-24 12:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f336aee22e85 8006852: Move tests from JIRA for prepopulated map failures Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8006852a.js + test/script/basic/JDK-8006852a.js.EXPECTED + test/script/basic/JDK-8006852b.js Changeset: bff7087396d7 Author: sundar Date: 2013-01-24 22:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/bff7087396d7 8006857: ClassCastException when interface implementing function uses arguments object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8006857.js + test/script/basic/JDK-8006857.js.EXPECTED Changeset: f52d7294536f Author: hannesw Date: 2013-01-25 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f52d7294536f 8006766: Array-like access to characters of a string is slow Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java Changeset: 8f7a86f82376 Author: sundar Date: 2013-01-28 18:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8f7a86f82376 8006983: Introduce a command line option to switch off syntactic extensions of nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8006983.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED Changeset: 265c46dbcf43 Author: sundar Date: 2013-01-28 21:29 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/265c46dbcf43 8007004: nashorn script engine should not use thread context class loader as script 'application loader' Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java Changeset: b6c69beebde6 Author: jlaskey Date: 2013-01-28 16:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b6c69beebde6 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! make/Makefile + makefiles/BuildNashorn.gmk + makefiles/Makefile Changeset: 333748665588 Author: sundar Date: 2013-01-29 19:57 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/333748665588 8007091: Provide private API to pass application class loader for nashorn script engine Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 755404d7d189 Author: jlaskey Date: 2013-01-29 14:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/755404d7d189 8007094: Apply version to nashorn.jar manifest Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 59970b70ebb5 Author: lagergren Date: 2013-01-30 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/59970b70ebb5 8007062: Split Lower up into Lower/Attr/FinalizeTypes. Integrate AccessSpecalizer into FinalizeTypes. Summary: Lower suffered from being a "God class" trying to do everything at once. As Nashorn code generation has grown, so has Lower. It does several post processing passes, tries to do several things at once even though all type information isn't in place, adjusting state afterwards and so on. It also performs control flow analysis, type attribution and constant folding, and everything else code generation related before byte code emission. I have now separated the compilation process into Lower (create low level nodes from high level ones, copy code such as finally block inlining etc), Attr (assign types and symbols to all nodes - freeze slot and scope information) and FinalizeTypes (insert explicit casts, specialize invoke dynamic types for scope accesses). I've removed the kludgy AccessSpecializer, as this now integrates naturally with typing. Everything is now much easier to read and each module performs only one thing. I have added separate loggers for the separate ti ers. In the process I have also fixed: (1) problems with type coercion (see test/script/basic/typecoercion.js, basically our coercion was too late and our symbol inference was erroneous. This only manifested itself in very rare occasions where toNumber coercion has side effects, such as for example when valueOf is overridden) (2) copying literal nodes (literal copy did not use the superclass copy, which made all the Node specific fields not to be copied (3) erroneous literal tokenization (literals shouldn't always just inherit token information from whatever node that creates them) (4) splitter weighnodes - unary nodes were considered weightless (4) removed the hateful and kludgy "VarNode.shouldAppend", which really isn't needed when we have an attribution phase that determines self reference symbols (the only thing it was used for) (5) duplicate line number issues in the parser (6) convert bug in CodeGenerator for intermediate results of scope accesses (see test/script/b asic/access-specializer.js) ... Several of these things just stopped being problems with the new architecture "can't happen anymore" and are not bug fixes per se. All tests run. No performance regressions exist that I've been able to measure. Some increases in performance were measured, but in the statistical margin of error (which is very wide as HotSpot currently has warmup issues with LambdaForms/invoke dynamic). Compile speed has not measurably increased. Reviewed-by: jlaskey, attila ! docs/DEVELOPER_README ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java - src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/FinalizeTypes.java + src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/access-specializer.js ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/typecoerce.js + test/script/basic/typecoerce.js.EXPECTED Changeset: ca6d5e4b8170 Author: sundar Date: 2013-01-30 17:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ca6d5e4b8170 8007132: Java objects returned from constructor functions are lost Reviewed-by: hannesw, lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8007132.js Changeset: 9f913c1843c8 Author: hannesw Date: 2013-01-30 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9f913c1843c8 8007109: Regression: String(ConsString) does not flatten argument to String Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/consstring.js + test/src/jdk/nashorn/internal/test/models/StringArgs.java Changeset: c04f54d5b672 Author: sundar Date: 2013-01-30 21:15 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c04f54d5b672 8007140: Java.extend crashes when attempting to extend java.lang.Object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8006424.js + test/script/basic/JDK-8007140.js Changeset: 9c1e7ae975db Author: sundar Date: 2013-01-31 20:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9c1e7ae975db 8007286: Add JavaAdapter and importPackage to compatibility script Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/importpackage.js + test/script/basic/javaadapter.js Changeset: f7825c1a11d3 Author: attila Date: 2013-01-31 18:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f7825c1a11d3 8006529: Methods always get callee - it should be conditional Summary: This commit streamlines the bytecode function signatures, prologue, local variable use, scope creation, and invocation. It started out quite innocently when we noticed that we always emit __callee__ parameters for all functions even when they are not needed, but it turned out to be quite a deep rabbit hole. In the end, I identified exact conditions when functions need to have a callee parameter, when they need to receive parent scope, when they need to create their own scope, when they need to have variable arity signature, and when they need to have an "arguments" object, and made sure that callee parameters in signatures only show up when they are needed, that parent function's scope is only passed to a child function when it is needed, that the function only creates its own scope when it is needed. In crypto.js, the number of scopes dropped from 446 to 244, and the number of callees dropped from 315 to 145. Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8006529-b.js + test/script/basic/JDK-8006529-b.js.EXPECTED + test/script/basic/JDK-8006529.js + test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 697f700d90c0 Author: hannesw Date: 2013-02-01 02:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/697f700d90c0 8007060: Primitive wrap filter throws ClassCastException in test262parallel Reviewed-by: sundar, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8007060.js + test/script/basic/JDK-8007060.js.EXPECTED Changeset: a704700470fb Author: jlaskey Date: 2013-02-04 08:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a704700470fb 8007455: Extraneous $(ECHO) in make/Makefile Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: bb86bf840f9f Author: attila Date: 2013-02-04 15:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/bb86bf840f9f 8007460: var assignment to a parameter in a varargs method causes compilation error Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8007460.js + test/script/basic/JDK-8007460.js.EXPECTED Changeset: bee7c8a45a04 Author: lagergren Date: 2013-02-04 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/bee7c8a45a04 8007215: Varargs broken for the case of passing more than the arg limit arguments. Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007215.js + test/script/basic/JDK-8007215.js.EXPECTED Changeset: 6f58c28c4faa Author: jlaskey Date: 2013-02-04 14:48 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/6f58c28c4faa 8006191: `cmd` -> exec("cmd") in script mode Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8006191.js + test/script/basic/JDK-8006191.js.EXPECTED Changeset: 5c2ed5d89524 Author: sundar Date: 2013-02-05 09:11 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5c2ed5d89524 8007452: add scripting programmers doc changes for nashorn Reviewed-by: jlaskey, hannesw + docs/JavaScriptingProgrammersGuide.html + docs/source/EvalFile.java + docs/source/EvalScript.java + docs/source/InvokeScriptFunction.java + docs/source/InvokeScriptMethod.java + docs/source/MultiScopes.java + docs/source/RunnableImpl.java + docs/source/RunnableImplObject.java + docs/source/ScriptVars.java + docs/source/importpackageclass.js + docs/source/javaarray.js + docs/source/javaextend.js + docs/source/javaimporter.js + docs/source/javatypes.js + docs/source/overload.js + docs/source/runnable.js + docs/source/samfunc.js + docs/source/test.js ! src/jdk/nashorn/internal/objects/NativeJava.java Changeset: c48e8a28da90 Author: sundar Date: 2013-02-05 18:44 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c48e8a28da90 8007521: $ENV should be undefined when security manager is present Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java - test/script/basic/JDK-8006191.js - test/script/basic/JDK-8006191.js.EXPECTED + test/script/currently-failing/JDK-8006191.js + test/script/currently-failing/JDK-8006191.js.EXPECTED + test/script/sandbox/env.js + test/script/sandbox/exec.js Changeset: 819b5485949d Author: sundar Date: 2013-02-05 21:00 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/819b5485949d 8007522: IllegalStateException thrown from String.prototype.search function Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8007522.js Changeset: f05d4dae30f7 Author: sundar Date: 2013-02-05 22:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f05d4dae30f7 8007523: VerifyError on script that uses regular expression literals with ternary operator Reviewed-by: lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java ! test/script/basic/JDK-8007522.js + test/script/basic/JDK-8007523.js Changeset: f6fae6de6f4f Author: hannesw Date: 2013-02-06 10:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f6fae6de6f4f 8007273: Creation of ScriptFunctions can be refactored Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: fcf541418304 Author: sundar Date: 2013-02-06 17:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/fcf541418304 8007619: Add support for deprecated properties of RegExp constructor Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007619.js + test/script/basic/JDK-8007619.js.EXPECTED Changeset: ec4d59c9b8d2 Author: jlaskey Date: 2013-02-06 08:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ec4d59c9b8d2 8007545: jjs input evalinput need to be NOT_ENUMERABLE Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/tools/resources/shell.js Changeset: 2ca25bf25d0c Author: jlaskey Date: 2013-02-06 11:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/2ca25bf25d0c 8007629: Remove extraneous quit from shell.js Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/resources/shell.js Changeset: 02f810c26ff9 Author: jlaskey Date: 2013-02-06 12:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/02f810c26ff9 8007643: Add testing for quit and exit Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/sandbox/exit.js ! test/script/sandbox/exit.js.EXPECTED Changeset: d7e83be6e7aa Author: sundar Date: 2013-02-07 17:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d7e83be6e7aa 8007715: Make sure that not all tests run with AllPermission Reviewed-by: lagergren, attila ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/README - test/script/basic/JDK-8006424.js - test/script/basic/JDK-8006529.js - test/script/basic/NASHORN-638.js - test/script/basic/NASHORN-638.js.EXPECTED - test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-758.js - test/script/basic/getenv.js - test/script/basic/getenv.js.EXPECTED ! test/script/basic/javaexceptions.js ! test/script/basic/newexpr.js + test/script/sandbox/interfaceimpl.js + test/script/sandbox/loadcompat.js + test/script/trusted/JDK-8006424.js + test/script/trusted/JDK-8006529.js + test/script/trusted/NASHORN-638.js + test/script/trusted/NASHORN-638.js.EXPECTED + test/script/trusted/NASHORN-653.js + test/script/trusted/README + test/script/trusted/getenv.js + test/script/trusted/getenv.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: bca3a64a4a82 Author: hannesw Date: 2013-02-07 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/bca3a64a4a82 8007627: Support @Getter annotation on constructor Reviewed-by: attila, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java Changeset: d5130a5803d1 Author: hannesw Date: 2013-02-07 15:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d5130a5803d1 8007718: Make static RegExp properties fully compatible to other engines Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007718.js + test/script/basic/JDK-8007718.js.EXPECTED Changeset: 8742be332c8a Author: jlaskey Date: 2013-02-08 09:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8742be332c8a 8006222: Move slot from SpillProperty to Property Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java Changeset: 5ead5333fa59 Author: attila Date: 2013-02-09 16:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5ead5333fa59 8006943: Fix order of function method arguments to be (callee, thisObject) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: abea4ba28901 Author: sundar Date: 2013-02-11 21:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/abea4ba28901 8007915: Nashorn IR, codegen, parser packages and Context instance should be inaccessible to user code Reviewed-by: lagergren, jlaskey, attila ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashornsecure ! bin/nashornsecure.bat ! make/Makefile ! make/build.xml + make/java.security.override ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java - src/jdk/nashorn/internal/parser/RegExp.java - src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/RegExp.java + src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/resources/parser.js + test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js + test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java + test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java + test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java + test/src/jdk/nashorn/api/javaaccess/Person.java + test/src/jdk/nashorn/api/javaaccess/SharedObject.java + test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java - test/src/jdk/nashorn/internal/access/BooleanAccessTest.java - test/src/jdk/nashorn/internal/access/MethodAccessTest.java - test/src/jdk/nashorn/internal/access/NumberAccessTest.java - test/src/jdk/nashorn/internal/access/NumberBoxingTest.java - test/src/jdk/nashorn/internal/access/ObjectAccessTest.java - test/src/jdk/nashorn/internal/access/Person.java - test/src/jdk/nashorn/internal/access/SharedObject.java - test/src/jdk/nashorn/internal/access/StringAccessTest.java - test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 774a0f349cc0 Author: hannesw Date: 2013-02-12 13:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/774a0f349cc0 8007956: Wrong or obsolete system properties in docs/DEVELOPER_README Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README Changeset: d50e1752f59b Author: attila Date: 2013-02-12 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d50e1752f59b 8007900: Function binding is inefficient Reviewed-by: jlaskey, lagergren + src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java + test/script/basic/funcbind2.js + test/script/basic/funcbind2.js.EXPECTED + test/script/basic/funcbind3.js + test/script/basic/funcbind3.js.EXPECTED Changeset: a3dc1b180ce7 Author: hannesw Date: 2013-02-13 13:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a3dc1b180ce7 8008096: TokenStream buffer should grow exponentially Reviewed-by: attila, lagergren, sundar ! src/jdk/nashorn/internal/parser/TokenStream.java Changeset: 38c44687e4bd Author: sundar Date: 2013-02-13 19:59 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/38c44687e4bd 8008103: Source object should maintain URL of the script source as a private field Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 222b9f32b674 Author: sundar Date: 2013-02-14 09:14 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/222b9f32b674 8008193: test262 tests should be run with security manager enabled Reviewed-by: jlaskey ! make/build.xml Changeset: 8c72a2bec1be Author: sundar Date: 2013-02-14 14:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8c72a2bec1be 8008197: Cross script engine function calls do not work as expected Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8008197.js ! test/script/basic/jquery.js Changeset: 43e32b36153c Author: lagergren Date: 2013-02-14 13:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/43e32b36153c 8008199: Lazy compilation and trampoline implementation Summary: The code pipeline now supports lazy compilation, which can be used to only compile certain FunctionNodes and leave others be, saving startup time. When these uncompiled nodes are hit, a trampoline will force them to be recompiled. This can also be used to specialize compilation fixing parameter types and return types to a callsite specific compilation. This will give performance. Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java - src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5a820fb11814 Author: attila Date: 2013-02-14 13:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5a820fb11814 8008085: Integrate Dynalink source code into Nashorn codebase Reviewed-by: jlaskey, lagergren, sundar ! THIRD_PARTY_README ! make/build.xml ! make/nbproject/project.xml ! make/project.properties + src/jdk/internal/dynalink/CallSiteDescriptor.java + src/jdk/internal/dynalink/ChainedCallSite.java + src/jdk/internal/dynalink/DefaultBootstrapper.java + src/jdk/internal/dynalink/DynamicLinker.java + src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/MonomorphicCallSite.java + src/jdk/internal/dynalink/NoSuchDynamicMethodException.java + src/jdk/internal/dynalink/RelinkableCallSite.java + src/jdk/internal/dynalink/beans/AbstractJavaLinker.java + src/jdk/internal/dynalink/beans/AccessibleMembersLookup.java + src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/BeanIntrospector.java + src/jdk/internal/dynalink/beans/BeanLinker.java + src/jdk/internal/dynalink/beans/BeansLinker.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java + src/jdk/internal/dynalink/beans/ClassLinker.java + src/jdk/internal/dynalink/beans/ClassString.java + src/jdk/internal/dynalink/beans/DynamicMethod.java + src/jdk/internal/dynalink/beans/DynamicMethodLinker.java + src/jdk/internal/dynalink/beans/FacetIntrospector.java + src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java + src/jdk/internal/dynalink/beans/MaximallySpecific.java + src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java + src/jdk/internal/dynalink/beans/OverloadedMethod.java + src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/StaticClass.java + src/jdk/internal/dynalink/beans/StaticClassIntrospector.java + src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/messages.properties + src/jdk/internal/dynalink/beans/package.html + src/jdk/internal/dynalink/linker/ConversionComparator.java + src/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java + src/jdk/internal/dynalink/linker/LinkRequest.java + src/jdk/internal/dynalink/linker/LinkerServices.java + src/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/package.html + src/jdk/internal/dynalink/package.html + src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java + src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java + src/jdk/internal/dynalink/support/AutoDiscovery.java + src/jdk/internal/dynalink/support/Backport.java + src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java + src/jdk/internal/dynalink/support/ClassMap.java + src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java + src/jdk/internal/dynalink/support/Guards.java + src/jdk/internal/dynalink/support/LinkRequestImpl.java + src/jdk/internal/dynalink/support/LinkerServicesImpl.java + src/jdk/internal/dynalink/support/Lookup.java + src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java + src/jdk/internal/dynalink/support/NameCodec.java + src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk/internal/dynalink/support/TypeConverterFactory.java + src/jdk/internal/dynalink/support/TypeUtilities.java + src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/messages.properties + src/jdk/internal/dynalink/support/package.html ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! test/script/sandbox/nashorninternals.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java Changeset: d086c3eead6b Author: lagergren Date: 2013-02-14 13:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d086c3eead6b 8008206: The allInteger case for SwitchNode generation in CodeGenerator assumes integer LITERALS only. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8008206.js + test/script/basic/JDK-8008206.js.EXPECTED Changeset: 3df0a0d62d60 Author: attila Date: 2013-02-14 13:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3df0a0d62d60 8007990: No access to interface methods on a restricted class Reviewed-by: jlaskey, lagergren, sundar ! make/build.xml + test/script/basic/JDK-8007990.js + test/script/basic/JDK-8007990.js.EXPECTED Changeset: d1ce4e09e4ba Author: hannesw Date: 2013-02-14 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d1ce4e09e4ba 8008198: java.lang.AssertionError: Invalid break target class jdk.nashorn.internal.ir.TryNode Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008198.js + test/script/basic/JDK-8008198.js.EXPECTED Changeset: d41d7cf9ab8b Author: jlaskey Date: 2013-02-14 11:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d41d7cf9ab8b 8008231: Fix build system to accommodate integration of dynalink Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 36065e5ea3d1 Author: hannesw Date: 2013-02-15 09:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/36065e5ea3d1 8008215: break in catch clause causes java.lang.VerifyError: Inconsistent stackmap Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008215.js + test/script/basic/JDK-8008215.js.EXPECTED Changeset: e478708faa22 Author: lagergren Date: 2013-02-15 09:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e478708faa22 8008239: Unpublicized parts of the code generator package that were only package internal. Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/Condition.java + src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/MapCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java - src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: 757a49aaad02 Author: sundar Date: 2013-02-15 18:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/757a49aaad02 8008291: Add more tests for better coverage of objects, scripting and parser packages Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/assign_builtin_func_props.js + test/script/basic/debugger.js + test/script/basic/yield.js ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 5851c5dac260 Author: sundar Date: 2013-02-15 20:40 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5851c5dac260 8008298: Add tests to cover specialized versions of Math functions. Reviewed-by: jlaskey, lagergren + test/script/basic/JDK-8008298.js Changeset: d5f74bd2dc20 Author: sundar Date: 2013-02-18 14:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d5f74bd2dc20 8008305: ScriptEngine.eval should offer the ability to provide a codebase Reviewed-by: lagergren, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/URLReader.java + test/script/trusted/JDK-8008305.js + test/script/trusted/JDK-8008305_subtest.js + test/script/trusted/urlreader.js Changeset: 3245e174fe3a Author: hannesw Date: 2013-02-18 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3245e174fe3a 8008351: Avoid using String.replace(String, String) in codegen Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/Condition.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java Changeset: f8221ce53c2e Author: attila Date: 2013-02-18 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f8221ce53c2e 8008371: Fix Dynalink compiler warnings and whitespace Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk/internal/dynalink/NoSuchDynamicMethodException.java ! src/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk/internal/dynalink/support/AutoDiscovery.java ! src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 4738de1bd57f Author: sundar Date: 2013-02-18 20:41 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4738de1bd57f 8008387: Improve code coverage tests for JSObjectLinker and NashornBottomLinker Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/javamethodcallerrors.js + test/script/basic/jsobject.js Changeset: b6798a83dbd4 Author: jlaskey Date: 2013-02-19 09:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b6798a83dbd4 8008420: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: b228e3cdbfc3 Author: jlaskey Date: 2013-02-19 09:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b228e3cdbfc3 Merge Changeset: b632446ba138 Author: sundar Date: 2013-02-19 20:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b632446ba138 8008448: Add coverage test for jdk.nashorn.internal.ir.debug.JSONWriter Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java + test/script/basic/JDK-8008448.js Changeset: 58eea0e8f369 Author: sundar Date: 2013-02-20 17:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/58eea0e8f369 8008207: Make constants array and source fields private Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 671852e35ced Author: lagergren Date: 2013-02-20 16:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/671852e35ced 8008166: URL handling was broken on windows, causing "load" to malfunction Reviewed-by: attila, jlaskey Contributed-by: klara.ward at oracle.com ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java Changeset: a971adb68f38 Author: lagergren Date: 2013-02-21 16:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a971adb68f38 8008648: Lazy JIT scope and callee semantics bugfixes. Broke out wallclock timer. Reviewed-by: attila, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationException.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Timing.java ! test/script/trusted/JDK-8006529.js Changeset: ae1c9716685b Author: jlaskey Date: 2013-02-21 15:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ae1c9716685b 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: 678da59a29b3 Author: lagergren Date: 2013-02-22 08:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/678da59a29b3 8008554: load was broken for URLs Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8008554.js Changeset: 230a711062c1 Author: lagergren Date: 2013-02-22 11:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/230a711062c1 8008575: Re-integrate code coverage Reviewed-by: attila, hannesw Contributed-by: eugene.drobitko at oracle.com, ilya.dergalin at oracle.com ! make/build.xml + make/code_coverage.xml ! make/project.properties Changeset: 267cc4c85160 Author: lagergren Date: 2013-02-22 12:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/267cc4c85160 8007002: Replace implicit exception throwing methods with explicit throws - simplify control flow and remove useless code Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/URLReader.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 3f0ff84aaf36 Author: jlaskey Date: 2013-02-22 10:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3f0ff84aaf36 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 508da3c7fc3a Author: hannesw Date: 2013-02-22 16:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/508da3c7fc3a 8008093: Make RegExp engine pluggable Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java - src/jdk/nashorn/internal/runtime/RegExp.java - src/jdk/nashorn/internal/runtime/RegExpMatch.java - src/jdk/nashorn/internal/runtime/RegExpScanner.java + src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/RegExpMatcher.java + src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java + src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: e42fd1640ff9 Author: hannesw Date: 2013-02-22 17:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e42fd1640ff9 8006028: Integrate Joni regexp engine with Nashorn Reviewed-by: lagergren, attila ! THIRD_PARTY_README ! docs/DEVELOPER_README + src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFold.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFoldArg.java + src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java + src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/Config.java + src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java + src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java + src/jdk/nashorn/internal/runtime/regexp/joni/MatcherFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/MinMaxLen.java + src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/NodeOptInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptAnchorInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptExactInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptMapInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/Option.java + src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java + src/jdk/nashorn/internal/runtime/regexp/joni/Region.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java + src/jdk/nashorn/internal/runtime/regexp/joni/Token.java + src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java + src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java + src/jdk/nashorn/internal/runtime/regexp/joni/Warnings.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnchorNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnyCharNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AnchorType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Arguments.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AsmConstants.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCSTATE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCVALTYPE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/EncloseType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/MetaChar.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPSize.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/RegexState.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackPopLevel.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StringType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/SyntaxProperties.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TargetInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TokenType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Traverse.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/CharacterType.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/IntHolder.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/InternalException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/JOniException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/SyntaxException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java Changeset: 7f5b7c6859d7 Author: sundar Date: 2013-02-22 22:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/7f5b7c6859d7 8008729: Make sure that we can run basic jsr223 tests using jtreg Reviewed-by: jlaskey, hannesw, lagergren + test/TEST.ROOT ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 5452f82eb2ce Author: jlaskey Date: 2013-02-22 23:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5452f82eb2ce 8008776: Revise BuildNashorn.gmk for changes in new build system Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 927fba6785b0 Author: sundar Date: 2013-02-25 16:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/927fba6785b0 8008731: Separate configuration environment (options, error/output writer etc.) from Context Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java - src/jdk/nashorn/internal/runtime/OptionsObject.java + src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5610ac25d8ff Author: sundar Date: 2013-02-25 18:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5610ac25d8ff 8008789: Enable java access and nashorn runtime tests for jtreg Reviewed-by: lagergren, jlaskey, hannesw ! make/build.xml ! test/TEST.ROOT ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: 1654918e0612 Author: attila Date: 2013-02-25 16:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1654918e0612 8006984: Introducing local into a function inside with statement confuses its scope Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8006984.js + test/script/basic/JDK-8006984.js.EXPECTED Changeset: a90094ae5be3 Author: sundar Date: 2013-02-26 22:57 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a90094ae5be3 8009021: nasgen should be run on boot jdk rather than currenly built jdk Reviewed-by: jlaskey ! makefiles/BuildNashorn.gmk Changeset: 1d3dca059b3e Author: alanb Date: 2013-02-27 14:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1d3dca059b3e 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Reviewed-by: chegar, sundar ! makefiles/BuildNashorn.gmk Changeset: 071e859b371e Author: attila Date: 2013-02-27 15:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/071e859b371e 8009143: Eliminate Dynalink dependency on java.beans Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java Changeset: 928ea3d8faf0 Author: attila Date: 2013-02-27 15:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/928ea3d8faf0 8009146: Eliminate some dead code in preparation for immutable AST Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: 1da9e37697f6 Author: attila Date: 2013-02-27 16:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1da9e37697f6 8009150: Previous dead code elimination was incomplete Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/ir/BinaryNode.java Changeset: 1e03be240534 Author: sundar Date: 2013-02-28 20:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1e03be240534 8009229: ant makefile default target should be "test" Reviewed-by: lagergren, jlaskey ! make/build.xml Changeset: 037e1de7ab1a Author: hannesw Date: 2013-02-28 22:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/037e1de7ab1a 8009240: RegExpScanner code is inefficient and too complex Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: 7e9fbe621d87 Author: sundar Date: 2013-03-01 15:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/7e9fbe621d87 8009263: Fix all javadoc errors in nashorn code Reviewed-by: hannesw, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java Changeset: 3b222c90b7de Author: jlaskey Date: 2013-03-02 11:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3b222c90b7de Merge Changeset: f90810d79b57 Author: hannesw Date: 2013-03-04 11:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f90810d79b57 8008370: coffee script compiler doesn't work with Nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8008370.js + test/script/basic/JDK-8008370.js.EXPECTED Changeset: fe5211fc3114 Author: jlaskey Date: 2013-03-04 11:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/fe5211fc3114 8009379: Remove $ from generated class names Reviewed-by: attila, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java - src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JO.java - src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/internal/scripts/JS.java Changeset: 3d57f57acd9c Author: sundar Date: 2013-03-06 22:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3d57f57acd9c 8009553: Object.create(Array.prototype) doesn't respect reset length Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8009553.js Changeset: 5759f600fcf7 Author: sundar Date: 2013-03-09 21:49 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5759f600fcf7 8009559: clean up method handle lookup code. Reviewed-by: ahgross, jlaskey, attila, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/java.security.override ! src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java - src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SafeUnreflector.java + src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java + src/jdk/internal/dynalink/beans/SandboxClassLoader.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/sandbox/Unreflector.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/lookup/Lookup.java + src/jdk/nashorn/internal/lookup/MethodHandleFactory.java + src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java - src/jdk/nashorn/internal/runtime/linker/Lookup.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/currently-failing/JDK-8006529.js - test/script/trusted/JDK-8006529.js Changeset: 053d7c55dc82 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/053d7c55dc82 Added tag jdk8-b82 for changeset 5759f600fcf7 ! .hgtags From john.coomes at oracle.com Fri Mar 22 08:23:12 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Mar 2013 08:23:12 +0000 Subject: hg: hsx/hotspot-gc/langtools: 58 new changesets Message-ID: <20130322082552.F266B48329@hg.openjdk.java.net> Changeset: 58289451d9ed Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/58289451d9ed Added tag jdk8-b81 for changeset ed69d087fdfd ! .hgtags Changeset: 63872da94576 Author: darcy Date: 2013-02-13 23:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/63872da94576 8001457: New tests needed for library-side changes for repeating annotations Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java Changeset: 88286a36bb34 Author: mchung Date: 2013-02-14 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/88286a36bb34 8006225: tools/jdeps/Basic.java failes with AssertionError Reviewed-by: alanb + src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! test/tools/jdeps/Basic.java Changeset: 040f02711b73 Author: jjg Date: 2013-02-15 08:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/040f02711b73 8007052: javap should include the descriptor for a method in verbose mode Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/DescriptorTest.java Changeset: 0baaae675b19 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0baaae675b19 8006749: compiler does not allow Object protected methods to be used in lambda Summary: Check.checkFunctionalInterface should take into account 'fake' override Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/LambdaConv26.java Changeset: f6e667f52af4 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f6e667f52af4 8007285: AbstractMethodError instead of compile-time error when method reference with super and abstract Summary: Missing abstractness check on super rmethod references Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/MethodReference62.java + test/tools/javac/lambda/MethodReference62.out Changeset: 4ff468de829d Author: mcimadamore Date: 2013-02-15 16:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4ff468de829d 8007462: Fix provisional applicability for method references Summary: Add speculative arity-based check to rule out potential candidates when stuck reference is passed to method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java + test/tools/javac/lambda/TargetType60.java + test/tools/javac/lambda/TargetType60.out Changeset: 3cd997b9fd84 Author: mcimadamore Date: 2013-02-15 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3cd997b9fd84 8007535: Compiler crashes on @FunctionalInterface used on interface with two inherited methods with same signatures Summary: Bad check in Types.interfaceCandidates Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/FunctionalInterfaceAnno02.java Changeset: 186023614cd3 Author: mcimadamore Date: 2013-02-15 16:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/186023614cd3 8007427: Annotation element as '_' gives compiler error instead of a warning 8007401: Write test to check for generation of warnings when '_' is used as an identifier Summary: Extended identifier production not used in annotation values Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/lambda/IdentifierTest.java + test/tools/javac/lambda/IdentifierTest.out Changeset: 258c72fa7fa2 Author: mcimadamore Date: 2013-02-15 16:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/258c72fa7fa2 Merge Changeset: da2f7dd53915 Author: mcimadamore Date: 2013-02-15 18:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/da2f7dd53915 8008309: TargetType60 fails because of bad golden file Summary: bad golden file Reviewed-by: jjg ! test/tools/javac/lambda/TargetType60.out Changeset: 9fb4f223a90d Author: jjg Date: 2013-02-15 11:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9fb4f223a90d 8008313: 8007052 breaks test/tools/javap/MethodParameters.java Reviewed-by: darcy ! test/tools/javap/MethodParameters.java Changeset: f1f605f85850 Author: rfield Date: 2013-02-15 18:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f1f605f85850 8004969: Generate $deserializeLambda$ method 8006763: super in method reference used in anonymous class - ClassFormatError is produced 8005632: Inner classes within lambdas cause build failures 8005653: Lambdas containing inner classes referencing external type variables do not correctly parameterize the inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/lambda/LambdaInnerTypeVarArgs.java + test/tools/javac/lambda/LambdaInnerTypeVarReflect.java + test/tools/javac/lambda/MethodReference61.java Changeset: 2620c953e9fe Author: vromero Date: 2013-02-18 14:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2620c953e9fe 6563143: javac should issue a warning for overriding equals without hashCode Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out ! test/tools/javac/diags/examples.not-yet.txt Changeset: 87884cd0fea3 Author: jjg Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/87884cd0fea3 8008339: Test TargetAnnoCombo.java is broken Reviewed-by: jjh ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java Changeset: 011cf7e0a148 Author: darcy Date: 2013-02-19 00:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/011cf7e0a148 8008267: Add @Supported annotation to com.sun.source types Reviewed-by: jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/Server.java Changeset: dc8b7aa7cef3 Author: vromero Date: 2013-02-19 17:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/dc8b7aa7cef3 8006212: javac, convert jtreg tests from shell script to java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java + test/tools/apt/Basics/CheckAptIsRemovedTest.java - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh + test/tools/javac/4846262/CheckEBCDICLocaleTest.java - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java - test/tools/javac/6302184/T6302184.sh + test/tools/javac/ClassPathTest/ClassPathTest.java - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java + test/tools/javac/ExtDirs/ExtDirTest.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh + test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java + test/tools/javac/T5090006/AssertionFailureTest.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh + test/tools/javac/constDebug/ConstDebugTest.java - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh + test/tools/javac/fatalErrors/NoJavaLangTest.java - test/tools/javac/innerClassFile/Driver.sh + test/tools/javac/innerClassFile/InnerClassFileTest.java - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java + test/tools/javac/javazip/JavaZipTest.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java + test/tools/javac/lib/ToolBox.java + test/tools/javac/links/LinksTest.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh + test/tools/javac/newlines/NewLineTest.java - test/tools/javac/newlines/Newlines.sh + test/tools/javac/stackmap/StackMapTest.java - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.java - test/tools/javac/unicode/SupplementaryJavaID6.sh + test/tools/javah/6257087/T6257087.java - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java + test/tools/javah/T4942232/MissingParamClassTest.java + test/tools/javah/constMacroTest/ConstMacroTest.java + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java + test/tools/javap/4866831/PublicInterfaceTest.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh + test/tools/javap/stackmap/StackmapTest.java - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 9345394ac8fe Author: ksrini Date: 2013-02-19 17:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9345394ac8fe 8006948: Update javac for MethodParameters format change Reviewed-by: ksrini, forax Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: 4cf6e84f844f Author: lana Date: 2013-02-19 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4cf6e84f844f Merge Changeset: 267225edc1fe Author: strarup Date: 2013-02-20 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/267225edc1fe 8006582: Test for parameter names feature Reviewed-by: jjg, darcy, emc - test/tools/javac/MethodParameters.java + test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AttributeVisitor.java + test/tools/javac/MethodParameters/ClassFileVisitor.java + test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/ReflectionVisitor.java + test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/Tester.java + test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParametersTest.java Changeset: d686d8a7eb78 Author: mcimadamore Date: 2013-02-21 15:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d686d8a7eb78 8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler Summary: Disentangle cyclic dependency between static-ness of synthetic lambda method and static-ness of classes nested within lambdas Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaConv27.java Changeset: 3a39d123d33a Author: mcimadamore Date: 2013-02-21 15:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3a39d123d33a 8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply Summary: DiagnosticFilter used during speculative attribution is too broad Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/lambda/speculative/MissingError.java + test/tools/javac/lambda/speculative/MissingError.out Changeset: f4fdd53f8b3e Author: mcimadamore Date: 2013-02-21 15:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f4fdd53f8b3e 8005183: Missing accessor for constructor reference pointing to private inner class ctor Summary: Compiler should add bridges when translating private constructor reference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference63.java Changeset: 7ac9242d2ca6 Author: mcimadamore Date: 2013-02-21 15:25 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/7ac9242d2ca6 8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated Summary: Wildcards inference should re-use some of the bounds info generated during capture conversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/TargetType64.java Changeset: 9f0ec00514b6 Author: mcimadamore Date: 2013-02-21 15:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9f0ec00514b6 8007461: Regression: bad overload resolution when inner class and outer class have method with same name Summary: Fix regression in varargs method resolution introduced by bad refactoring Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 3fef0cae83b3 Author: mcimadamore Date: 2013-02-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3fef0cae83b3 8008444: Inherited generic functional descriptors are merged incorrectly Summary: Missing call to Types.createMethodWithThrownTypes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv25.java + test/tools/javac/lambda/LambdaConv25.out Changeset: cd7340a84bb8 Author: rfield Date: 2013-02-21 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/cd7340a84bb8 8008405: Now that metafactory is in place, add javac lambda serialization tests Summary: Tests part of original langtools serialization review. Reviewed-by: mcimadamore + test/tools/javac/T8004969.java + test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java + test/tools/javac/lambda/LambdaInnerTypeVarSerialize.java Changeset: dabb36173c63 Author: ksrini Date: 2013-02-21 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/dabb36173c63 8008658: Four new method param jtreg tests fail in nightly tests Reviewed-by: jjg, ksrini, mcimadamore Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/MethodParameters/EnumTest.java ! test/tools/javac/MethodParameters/LocalClassTest.java ! test/tools/javac/MethodParameters/MemberClassTest.java Changeset: 6118072811e5 Author: lana Date: 2013-02-21 17:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6118072811e5 Merge ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 8e82e4f225e4 Author: mcimadamore Date: 2013-02-22 13:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8e82e4f225e4 8008337: Write test to check for compiler error when static method in interface is called via super() Reviewed-by: mcimadamore Contributed-by: sonali.goel at oracle.com + test/tools/javac/lambda/StaticMethodNegTest.java + test/tools/javac/lambda/StaticMethodNegTest.out Changeset: 94e67bed460d Author: mcimadamore Date: 2013-02-22 18:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/94e67bed460d 8008708: Regression: separate compilation causes crash in wildcards inference logic Summary: Invalid use of WildcardType.bound in Types.removeWildcards Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/separate/Foo.java + test/tools/javac/lambda/separate/Test.java Changeset: ccbe7ffdd867 Author: jjg Date: 2013-02-24 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ccbe7ffdd867 7112427: The doclet needs to be able to generate JavaFX documentation. Reviewed-by: jjg Contributed-by: jan.valenta at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/PropertyWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PropertyBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertyGetterTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertySetterTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java + test/com/sun/javadoc/testJavaFX/C.java + test/com/sun/javadoc/testJavaFX/D.java + test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java Changeset: bd49e0304281 Author: vromero Date: 2013-02-26 09:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bd49e0304281 8008436: javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out Changeset: 133a0a0c2cbc Author: mcimadamore Date: 2013-02-28 14:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/133a0a0c2cbc 8008723: Graph Inference: bad graph calculation leads to assertion error Summary: Dependencies are not propagated correctly through merged nodes during inference graph initialization Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/lambda/TargetType65.java Changeset: 332f23993353 Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/332f23993353 8008813: Structural most specific fails when method reference is passed to overloaded method Summary: Bad logic for checking most specific method reference type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/MostSpecific08.java Changeset: 08782b8b03ce Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/08782b8b03ce 8008537: Missing method reference lookup error when unbound search finds a static method Summary: Static-ness check should be applied after member reference resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java + test/tools/javac/diags/examples/StaticMethodInUnboundLookup.java ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference28.out ! test/tools/javac/lambda/MethodReference51.out ! test/tools/javac/lambda/TargetType60.java ! test/tools/javac/lambda/TargetType60.out Changeset: 6f988040a1c8 Author: jjg Date: 2013-03-01 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6f988040a1c8 8008949: javadoc stopped copying doc-files Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/com/sun/javadoc/testDocFiles/TestDocFiles.java + test/com/sun/javadoc/testDocFiles/pkg/Test.java + test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt Changeset: 69cd2bfd4a31 Author: mcimadamore Date: 2013-03-05 14:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/69cd2bfd4a31 8004962: Code generation crash with lambda and local classes Summary: Translation info should be propagated from LambdaToMethod to Lower Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/lambda/LambdaCapture07.java Changeset: d2a98dde7ecc Author: mcimadamore Date: 2013-03-05 14:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d2a98dde7ecc 8009227: Certain diagnostics should not be deferred Summary: Add new diagnostic flag to mark non deferrable diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/lambda/abort/CompletionFailure.java Changeset: a708c5f1da06 Author: mcimadamore Date: 2013-03-05 14:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a708c5f1da06 8009154: Missing cast in method reference bridge leads to NoSuchMethodError Summary: Missing cast in generated method reference bridge Reviewed-by: rfield, jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference65.java Changeset: 12202e6ab78a Author: mcimadamore Date: 2013-03-05 14:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/12202e6ab78a 8009129: Illegal access error when calling method reference Summary: Javac generates method handle referencing non public type Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/NotDefPublicCantAccessFragment.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/p/C.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out + test/tools/javac/lambda/inaccessibleMref01/p1/C.java + test/tools/javac/lambda/inaccessibleMref02/InaccessibleMref02.java + test/tools/javac/lambda/inaccessibleMref02/p1/C.java Changeset: 188a07a0a7a0 Author: lana Date: 2013-03-05 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/188a07a0a7a0 Merge Changeset: d0178bd8125c Author: mcimadamore Date: 2013-03-06 15:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d0178bd8125c 8009299: Javac crashes when compiling method reference to static interface method Summary: Assertion in Check.checMethod is too strict Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/MethodReference66.java Changeset: 8a78243291ef Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8a78243291ef 8009459: Wrong behavior of diamond finder with source level 7 Summary: Diamond finder doesn't take into account different inference behaviors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/6939780/T6939780.java + test/tools/javac/generics/diamond/6939780/T6939780_7.out + test/tools/javac/generics/diamond/6939780/T6939780_8.out - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out Changeset: c98b3e96c726 Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c98b3e96c726 8009391: Synthetic name of serializable lambda methods should not contain negative numbers Summary: Use hex representation of method signature hashcode to avoid negative numbers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java Changeset: 3806171b52d8 Author: vromero Date: 2013-03-07 10:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3806171b52d8 8009138: javac, equals-hashCode warning tuning Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6563143/EqualsHashCodeWarningTest.java + test/tools/javac/6563143/EqualsHashCodeWarningTest.out - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out Changeset: 823fb9229724 Author: vromero Date: 2013-03-07 10:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/823fb9229724 8009170: Regression: javac generates redundant bytecode in assignop involving arrays Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java + test/tools/javac/8009170/RedundantByteCodeInArrayTest.java Changeset: a02c3ddc182b Author: rfield Date: 2013-03-07 08:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a02c3ddc182b 8009582: Method reference generic constructor gives: IllegalArgumentException: Invalid lambda deserialization Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/GenericMethodRefImplClass.java Changeset: c61add6bf8ac Author: vromero Date: 2013-03-11 15:35 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c61add6bf8ac 6181889: Empty try/finally results in bytecodes being generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6181889/EmptyFinallyTest.java Changeset: d0ae21e3a382 Author: rfield Date: 2013-03-11 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d0ae21e3a382 8009742: Bad lambda name for lambda in a static initializer or ctor Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/SerializedLambdaInInit.java Changeset: fbb6e470079d Author: ohrstrom Date: 2013-03-11 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fbb6e470079d 8009843: sjavac should accept -cp as synonym for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/Main.java Changeset: 7fe9b9d29095 Author: jfranck Date: 2013-03-12 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/7fe9b9d29095 8005205: tests missing bugid for repeating annotation change Reviewed-by: jjg, ssides ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java Changeset: 6db9a3b1a93f Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6db9a3b1a93f 8008540: Constructor reference to non-reifiable array should be rejected 8008539: Spurious error when constructor reference mention an interface type 8008538: Constructor reference accepts wildcard parameterized types Summary: Overhaul of Check.checkConstructorRefType Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference64.java + test/tools/javac/lambda/MethodReference64.out Changeset: 5ddecb91d843 Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5ddecb91d843 8009545: Graph inference: dependencies between inference variables should be set during incorporation Summary: Move all transitivity checks into the incorporation round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/lambda/TargetType28.out Changeset: f427043f8c65 Author: jfranck Date: 2013-03-12 17:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f427043f8c65 7196531: Duplicate error messages on repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out Changeset: 39f8eb897ec6 Author: lana Date: 2013-03-12 16:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/39f8eb897ec6 Merge - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh - test/tools/javac/6302184/T6302184.sh - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MethodParameters.java - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out - test/tools/javac/innerClassFile/Driver.sh - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh - test/tools/javac/newlines/Newlines.sh - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh - test/tools/javac/unicode/SupplementaryJavaID6.sh - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 825da6847791 Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/825da6847791 Merge Changeset: 22ba3f92d4ae Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/22ba3f92d4ae Added tag jdk8-b82 for changeset 825da6847791 ! .hgtags From erik.helin at oracle.com Fri Mar 22 08:55:22 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 22 Mar 2013 09:55:22 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <51444BB8.1050409@oracle.com> References: <51444BB8.1050409@oracle.com> Message-ID: <514C1C7A.7020204@oracle.com> All, based on internal feedback, this change has been updated. The event has been renamed to vm/gc/detailed/object_count_after_gc. Furthermore, the part of the change that updated heapInspection.cpp/hpp has been extracted to a separate change (also out for review on hotspot-gc-dev at openjdk.java.net). New webrev located at: http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ Thanks, Erik On 03/16/2013 11:38 AM, Erik Helin wrote: > Hi all, > > this change adds an event, vm/gc/detailed/class_count_after_gc, that > sends information about the number of instances of each class on the > heap (as well as size and the name of the class). > > The event is sent after the marking phase for all old collections and an > object will be counted as live if the GC think that the object is live > (this is only tricky in the case of a concurrent collection). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 > > Testing: > JPRT > > Thanks, > Erik From erik.helin at oracle.com Fri Mar 22 09:06:00 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 22 Mar 2013 10:06:00 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable Message-ID: <514C1EF8.9060303@oracle.com> Hi all, I have refactored the HeapInspection class to prepare for the vm/gc/detailed/object_count_after_gc event. The refactoring mainly consists of breaking up the rather long heap_inspect function to multiple small functions that can be reused. I also moved the public enums used to initialize KlassInfoTable and KlassInfoHisto to private constants. Now they no longer have to be passed as an argument to the constructor. I also added a test to ensure that my refactoring did not break anything (the test is not that extensive but at least it ensures that the basic stuff is working). Webrev: http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 Testing: - JPRT - A new jtreg test (see webrev) Thanks, Erik From nils.eliasson at oracle.com Fri Mar 22 09:12:09 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 22 Mar 2013 10:12:09 +0100 Subject: RFR(S): 8007701: Hotspot trace Allocation Events In-Reply-To: <5149D4BF.8000704@oracle.com> References: <51423640.4000506@oracle.com> <5149D4BF.8000704@oracle.com> Message-ID: <514C2069.2070008@oracle.com> Latest webrev after more feedback: http://cr.openjdk.java.net/~neliasso/8007701/webrev.06/ //N On 2013-03-20 16:24, Nils Eliasson wrote: > Thanks for your review Erik, > > Updated the webrev with your suggestions > - Moved alloction events to GCTrace > - Renamed class event field to "class" > > http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/ > http://bugs.sun.com/view_bug.do?bug_id=8007701 > > //Nils Eliasson > > > On 2013-03-14 21:42, Nils Eliasson wrote: >> Hi all, >> >> I would like a review for this change that introduces two new tracing >> events. >> >> "AllocationInNewTLAB" is sent for the first object in a new TLAB and >> gives a reasonably cheap and reasonably fair object sampling. >> "AllocationOutsideTLAB" is sent for each object that gets allocated >> outside the TLABs. (The object doesn't fit or would cause too much >> wasted free space if the tlab was discarded.) >> >> These events use the allocation slow path in CollectedHeap which is >> used by default in the template interpreter and the C2 compiler. It >> is also used for all TLAB refills in the C1-compiler if the flag >> -XX:-FastTLABRefill is supplied. >> >> http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ >> http://bugs.sun.com/view_bug.do?bug_id=8007701 >> >> The event code for AllocationOutsideTLAB had to be put in >> CollectedHeap.cpp since tracing.hpp can't be included into >> CollectedHeap.inline.hpp. >> >> Thanks, >> Nils Eliasson > From erik.helin at oracle.com Fri Mar 22 09:35:56 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 22 Mar 2013 10:35:56 +0100 Subject: RFR(S): 8007701: Hotspot trace Allocation Events In-Reply-To: <514C2069.2070008@oracle.com> References: <51423640.4000506@oracle.com> <5149D4BF.8000704@oracle.com> <514C2069.2070008@oracle.com> Message-ID: <514C25FC.1080800@oracle.com> Nils, On 03/22/2013 10:12 AM, Nils Eliasson wrote: > Latest webrev after more feedback: > > http://cr.openjdk.java.net/~neliasso/8007701/webrev.06/ Looks good to me! Thanks, Erik > //N > > > On 2013-03-20 16:24, Nils Eliasson wrote: >> Thanks for your review Erik, >> >> Updated the webrev with your suggestions >> - Moved alloction events to GCTrace >> - Renamed class event field to "class" >> >> http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/ >> http://bugs.sun.com/view_bug.do?bug_id=8007701 >> >> //Nils Eliasson >> >> >> On 2013-03-14 21:42, Nils Eliasson wrote: >>> Hi all, >>> >>> I would like a review for this change that introduces two new tracing >>> events. >>> >>> "AllocationInNewTLAB" is sent for the first object in a new TLAB and >>> gives a reasonably cheap and reasonably fair object sampling. >>> "AllocationOutsideTLAB" is sent for each object that gets allocated >>> outside the TLABs. (The object doesn't fit or would cause too much >>> wasted free space if the tlab was discarded.) >>> >>> These events use the allocation slow path in CollectedHeap which is >>> used by default in the template interpreter and the C2 compiler. It >>> is also used for all TLAB refills in the C1-compiler if the flag >>> -XX:-FastTLABRefill is supplied. >>> >>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ >>> http://bugs.sun.com/view_bug.do?bug_id=8007701 >>> >>> The event code for AllocationOutsideTLAB had to be put in >>> CollectedHeap.cpp since tracing.hpp can't be included into >>> CollectedHeap.inline.hpp. >>> >>> Thanks, >>> Nils Eliasson >> > From thomas.schatzl at oracle.com Fri Mar 22 10:15:17 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 22 Mar 2013 11:15:17 +0100 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <514BFECC.8070206@oracle.com> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> Message-ID: <1363947317.2689.27.camel@cirrus> Hi, On Fri, 2013-03-22 at 07:48 +0100, Bengt Rutisson wrote: > > Hi John, > Your changes look good to me. > > I think your motivation for removing the verification from > universe2_init() and init_globals() is fine. Actually I wonder why > they were there in the first place, but they do seem intentionally put > in there. However, I'm fine with removing them. These verifications seem to make the intervals between verification smaller to be able to pinpoint any problem location quicker. Threads::create_vm() does a lot after all. Removal is fine with me as well. Comparing to the comments on the CR (great analysis btw!), you opted for the approach to just skip verification of roots, heap regions and remset until a safepoint. From your analysis, the other option would have been to allow a NULL VM thread in some places. Allowing a NULL VMThread would allow checking heap consistency right after Universe::genesis(). It is probably not expected that there are already issues about the heap at this stage, but since we're already verifying, I'd tend to prefer the option that verifies as much as possible. (Did not really check if it would really make a difference) Maybe you could add a guarantee() or such in Threads::oops_do() and Threads::possibly_parallel_oops_do() that only allowed a NULL VM Thread during initialization? > One question that is not strictly related to your change: > > The code to do the verification in Threads::create_vm() is: > > 3449 if (VerifyBeforeGC && > 3450 Universe::heap()->total_collections() >= VerifyGCStartAt) { > 3451 Universe::heap()->prepare_for_verify(); > 3452 Universe::verify(); // make sure we're starting with a > clean slate > 3453 } > > This is what it looked like before your change as well. But to me this > looks kind of odd. First, we re-use the flag VerifyBeforeGC even > though we are not about to do a GC. I can live with that, but it is You mean because of the name of the flag? That's a point. Otoh at VM start you're technically before the next gc (whenever this happens ;) > kind of strange. Then we have the check against VerifyGCStartAt. By > default this is 0 so we will do the verification. But why do we do > this check? There is no chance that we have been able to do any GC > yet, right? So, checking against Universe::heap()->total_collections() Some values of some command line options change VerifyGCStartAt to eventually disable verification at VM startup (beginning arguments.cpp:2004). > seems unnecessary. We should either check VerifyGCStartAt == 0 or not I would not mind either way; but you still need the VerifyBeforeGC (or another flag) because otherwise the verification would practically be unconditional as the default value of VerifyGCStartAt is zero. > include that flag at all (best choice in my opinion). Thomas From john.cuthbertson at oracle.com Fri Mar 22 11:58:29 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 22 Mar 2013 11:58:29 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp Message-ID: <20130322115847.162DD48336@hg.openjdk.java.net> Changeset: 7f16d1812865 Author: tamao Date: 2013-03-20 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7f16d1812865 7196080: assert(max_heap >= InitialHeapSize) in arguments.cpp Summary: Remove the related assertions becasue they do not hold here. Reviewed-by: jmasa, tschatzl Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp From thomas.schatzl at oracle.com Fri Mar 22 12:12:31 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 22 Mar 2013 13:12:31 +0100 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <1363611183.2603.45.camel@cirrus> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> <1363611183.2603.45.camel@cirrus> Message-ID: <1363954351.2689.50.camel@cirrus> Hi all, ping? On Mon, 2013-03-18 at 13:53 +0100, Thomas Schatzl wrote: > Hi all, > > On Thu, 2013-03-14 at 11:17 +0100, Mikael Gerdin wrote: > > Thomas, > > > > On 2013-03-14 09:28, Thomas Schatzl wrote: > > > > > > Hi all, > > > > > > please have a look at the following change which tries to make heap > > > size argument processing more intuitive. > > > > > > The second two are no bugs imo as the user did not mention a bound for > > > the maximum heap size in the arguments, so it would be free to choose > > > anything >= InitialHeapSize. > > > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~tschatzl/8006088/webrev/ > > > > > > The problem with the VM starting up when InitialHeapSize > MaxHeapSize > > > is fixed in the first hunk of collectorPolicy.cpp where the respective > > > sanity check has been added. > > > > > > The change for the "incompatible minimum and initial heap size is located > > > in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the > > > same as -Xms and -XX:MaxHeapSize the same as -Xmx. > > > > > > The latter for consistency (using the same code path for -Xmx and > > > -XX:MaxHeapSize), as at the moment it does not set any internal variables. > > > > > > The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp > > > where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize > > > has been set on the command line, New- and OldSize are shrunk to fit. > > > > The code looks like it does what you describe :) > > > > Since the arguments parsing code is kind of hard to follow IMO and > > seemingly hard to get right it might be a good idea to write a > > regression test for this. > > > > Just writing a short jtreg test to launch vms with these arg > > combinations that you described above and verify that we get the > > expected outcome should not be too much code with the ProcessTools test > > done, added jtreg tests. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8006088/webrev.1/ > > Note that the code additionally removes two asserts that are imo invalid > to do at this point. > > I.e. > > assert(max_heap >= InitialHeapSize, "Error");// or >= OldSize in 7196080 > assert(max_heap >= NewSize, "Error"); > > The max_heap >= OldSize assert is problematic because its default value > is 4M. So again, if you set MaxHeapSize to e.g. 1-3M, the assert will > fail. > > The same applies to NewSize with a sufficiently small heap. > > There is the new sanity check collectorPolicy.cpp that checks whether > MaxHeapSize >= InitialHeapSize also in product mode (i.e. conflicting > command line params have been set). > > Additionally, NewSize and OldSize are adjusted to MaxHeapSize (or > MaxHeapSize to NewSize + OldSize) later in the collector policy too. > > These asserts also cause different behavior with/without debug mode. Note that in 7196080 these asserts have already been removed. Thomas From bengt.rutisson at oracle.com Fri Mar 22 12:53:00 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 22 Mar 2013 13:53:00 +0100 Subject: RFR(S): 8007701: Hotspot trace Allocation Events In-Reply-To: <514C2069.2070008@oracle.com> References: <51423640.4000506@oracle.com> <5149D4BF.8000704@oracle.com> <514C2069.2070008@oracle.com> Message-ID: <514C542C.3090200@oracle.com> Hi Nils, Overall this looks good, but I have two questions. Could we add a new class (maybe called AllocTracer?) instead of adding the two static send methods to GCTracer? It feels a bit wrong to have the GCTracer handle things that don't happen during a GC. How do we handle the fact that this does not cover the C1 tlab allocations? Is there a bug to track that? Thanks, Bengt On 3/22/13 10:12 AM, Nils Eliasson wrote: > Latest webrev after more feedback: > > http://cr.openjdk.java.net/~neliasso/8007701/webrev.06/ > > //N > > > On 2013-03-20 16:24, Nils Eliasson wrote: >> Thanks for your review Erik, >> >> Updated the webrev with your suggestions >> - Moved alloction events to GCTrace >> - Renamed class event field to "class" >> >> http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/ >> http://bugs.sun.com/view_bug.do?bug_id=8007701 >> >> //Nils Eliasson >> >> >> On 2013-03-14 21:42, Nils Eliasson wrote: >>> Hi all, >>> >>> I would like a review for this change that introduces two new >>> tracing events. >>> >>> "AllocationInNewTLAB" is sent for the first object in a new TLAB and >>> gives a reasonably cheap and reasonably fair object sampling. >>> "AllocationOutsideTLAB" is sent for each object that gets allocated >>> outside the TLABs. (The object doesn't fit or would cause too much >>> wasted free space if the tlab was discarded.) >>> >>> These events use the allocation slow path in CollectedHeap which is >>> used by default in the template interpreter and the C2 compiler. It >>> is also used for all TLAB refills in the C1-compiler if the flag >>> -XX:-FastTLABRefill is supplied. >>> >>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ >>> http://bugs.sun.com/view_bug.do?bug_id=8007701 >>> >>> The event code for AllocationOutsideTLAB had to be put in >>> CollectedHeap.cpp since tracing.hpp can't be included into >>> CollectedHeap.inline.hpp. >>> >>> Thanks, >>> Nils Eliasson >> > From erik.helin at oracle.com Fri Mar 22 13:01:25 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 22 Mar 2013 14:01:25 +0100 Subject: RFR: Adding evacuation failed tracing event In-Reply-To: <514B94B1.2060503@oracle.com> References: <514A4A73.6080704@oracle.com> <514B94B1.2060503@oracle.com> Message-ID: <514C5625.1050000@oracle.com> John, On 03/22/2013 12:16 AM, John Cuthbertson wrote: > Hi Jesper, > > I've only looked at the first set of changes. I'll look at the second > set later tonight or tomorrow. > > On 3/20/2013 4:46 PM, Jesper Wilhelmsson wrote: >> Hi, >> >> I'm looking for a couple of reviews for this change. >> >> The change is to add evacuation failed tracing events to G1. Since the >> evacuation failed is very similar to a regular promotion failed in >> other young GCs, these events share most of the code. >> >> I have split the change into two parts: >> >> >> 1) JDK-8009992: Prepare tracing of promotion failed for integration of >> evacuation failed >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009992/webrev/ >> >> This part refactors the promotion failed code to use a generic copy >> failed class which is used as the base for the promotion failed handling. > > Looks good. Just one nit: > > || _src/share/vm/gc_implementation/shared/gcTraceSend.cpp_ >> 95 static TraceStructCopyFailed to_trace_struct(const >> CopyFailedInfo& cf_info) { >> 96 TraceStructCopyFailed failed_info; >> 97 failed_info.set_objectCount(cf_info.failed_count()); >> 98 failed_info.set_firstSize(cf_info.first_size()); >> 99 failed_info.set_smallestSize(cf_info.smallest_size()); >> 100 failed_info.set_totalSize(cf_info.total_size()); >> 101 failed_info.set_thread(cf_info.thread()->thread_id()); >> 102 return failed_info; >> 103 } >> 104 >> 105 void YoungGCTracer::send_promotion_failed_event(const >> PromotionFailedInfo& pf_info) const { >> 106 EventPromotionFailed e; >> 107 if (e.should_commit()) { >> 108 e.set_gcId(_shared_gc_info.id()); >> 109 e.set_data(to_trace_struct(pf_info)); >> 110 e.commit(); >> 111 } >> 112 } > > Won't this result in executing the copy constructors of > TraceStructCopyFailed multiple times? (One in the return from > to_trace_struct() and one in set_data().) No, it won't. This is because e.set_data() takes a const reference to a TraceStructCopy. See [0] for more information about how this works. The following code shows an example: #include class Foo { int _x; public: Foo(int x) : _x(x) { printf("Constructing a new Foo\n"); } Foo(const Foo &f) { _x = f.x(); printf("Copying a Foo\n"); } ~Foo() { printf("Destructing a Foo\n"); } int x() const { return _x; } }; Foo create_foo() { Foo f(17); return f; } void print_foo(const Foo &foo) { printf("Foo %d\n", foo.x()); } int main() { print_foo(create_foo()); return 0; } Running: g++ -O0 foo.cpp -o foo ; ./foo Results in: Constructing a new Foo Foo 17 Destructing a Foo Thanks, Erik [0]: http://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/ > Would it not be more efficient > to return the address of the struct in the EventPromotionFailed, i.e. > > to_trace_struct(e.data_addr(), pf_info); > > where to_trace_struct() is: > > void to_trace_struct(TraceStructCopyFailed* dest_data, const > CopyFailedInfo& cf_info) { > dest_data->set_objectCount(cf_info.failed_count()); > ... > } > > Other than that. It looks OK to me. Now on to the other one. > > JohnC > > From erik.helin at oracle.com Fri Mar 22 13:34:08 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 22 Mar 2013 14:34:08 +0100 Subject: RFR: Adding evacuation failed tracing event In-Reply-To: <514A4A73.6080704@oracle.com> References: <514A4A73.6080704@oracle.com> Message-ID: <514C5DD0.2030701@oracle.com> Jesper, changes looks good! Thanks, Erik On 03/21/2013 12:46 AM, Jesper Wilhelmsson wrote: > Hi, > > I'm looking for a couple of reviews for this change. > > The change is to add evacuation failed tracing events to G1. Since the > evacuation failed is very similar to a regular promotion failed in other > young GCs, these events share most of the code. > > I have split the change into two parts: > > > 1) JDK-8009992: Prepare tracing of promotion failed for integration of > evacuation failed > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8009992/webrev/ > > This part refactors the promotion failed code to use a generic copy > failed class which is used as the base for the promotion failed handling. > > > 2) JDK-8008916: G1: Evacuation failed tracing event > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/ > > This part adds the new event for G1 evacuation failed. > > > Thanks, > /Jesper From erik.helin at oracle.com Fri Mar 22 17:23:25 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Fri, 22 Mar 2013 17:23:25 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000754: NPG: Implement a MemoryPool MXBean for Metaspace Message-ID: <20130322172329.D9DF748347@hg.openjdk.java.net> Changeset: dbd5837b342f Author: ehelin Date: 2013-03-22 16:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dbd5837b342f 8000754: NPG: Implement a MemoryPool MXBean for Metaspace Reviewed-by: jmasa, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/metaspace/TestMetaspaceMemoryPools.java From john.cuthbertson at oracle.com Fri Mar 22 17:24:21 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 22 Mar 2013 10:24:21 -0700 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <1363954351.2689.50.camel@cirrus> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> <1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus> Message-ID: <514C93C5.5060806@oracle.com> Hi Thomas, The change looks good to me. Good comment about the alignment of OldSize. The tests look great. JohnC On 3/22/2013 5:12 AM, Thomas Schatzl wrote: > Hi all, > > ping? > > On Mon, 2013-03-18 at 13:53 +0100, Thomas Schatzl wrote: >> Hi all, >> >> On Thu, 2013-03-14 at 11:17 +0100, Mikael Gerdin wrote: >>> Thomas, >>> >>> On 2013-03-14 09:28, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> please have a look at the following change which tries to make heap >>>> size argument processing more intuitive. >>>> >>>> The second two are no bugs imo as the user did not mention a bound for >>>> the maximum heap size in the arguments, so it would be free to choose >>>> anything >= InitialHeapSize. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8006088/webrev/ >>>> >>>> The problem with the VM starting up when InitialHeapSize > MaxHeapSize >>>> is fixed in the first hunk of collectorPolicy.cpp where the respective >>>> sanity check has been added. >>>> >>>> The change for the "incompatible minimum and initial heap size is located >>>> in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the >>>> same as -Xms and -XX:MaxHeapSize the same as -Xmx. >>>> >>>> The latter for consistency (using the same code path for -Xmx and >>>> -XX:MaxHeapSize), as at the moment it does not set any internal variables. >>>> >>>> The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp >>>> where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize >>>> has been set on the command line, New- and OldSize are shrunk to fit. >>> The code looks like it does what you describe :) >>> >>> Since the arguments parsing code is kind of hard to follow IMO and >>> seemingly hard to get right it might be a good idea to write a >>> regression test for this. >>> >>> Just writing a short jtreg test to launch vms with these arg >>> combinations that you described above and verify that we get the >>> expected outcome should not be too much code with the ProcessTools test >> done, added jtreg tests. >> >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.1/ >> >> Note that the code additionally removes two asserts that are imo invalid >> to do at this point. >> >> I.e. >> >> assert(max_heap >= InitialHeapSize, "Error");// or >= OldSize in 7196080 >> assert(max_heap >= NewSize, "Error"); >> >> The max_heap >= OldSize assert is problematic because its default value >> is 4M. So again, if you set MaxHeapSize to e.g. 1-3M, the assert will >> fail. >> >> The same applies to NewSize with a sufficiently small heap. >> >> There is the new sanity check collectorPolicy.cpp that checks whether >> MaxHeapSize >= InitialHeapSize also in product mode (i.e. conflicting >> command line params have been set). >> >> Additionally, NewSize and OldSize are adjusted to MaxHeapSize (or >> MaxHeapSize to NewSize + OldSize) later in the collector policy too. >> >> These asserts also cause different behavior with/without debug mode. > Note that in 7196080 these asserts have already been removed. > > Thomas > > > From john.cuthbertson at oracle.com Fri Mar 22 18:00:32 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 22 Mar 2013 11:00:32 -0700 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure In-Reply-To: <514C0312.6000203@oracle.com> References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com> Message-ID: <514C9C40.8070102@oracle.com> Hi Leonid, This looks OK to me. JohnC On 3/22/2013 12:06 AM, Leonid Mesnik wrote: > Could anyone please review this small test fix. > > Leonid > On 03/20/2013 04:16 PM, Leonid Mesnik wrote: >> Hi >> >> Could you please review fix for 8009808 TEST-BUG : test case is >> using bash style tests. Default shell for jtreg is bourne. thus failure. >> >> I've completely rewritten test in java without major changes it test >> logic. >> I remove CMS so test could be run when CMS is not supported. Also I >> changed max memory to 128M to reduce memory load and increase number >> of GC log entries. >> >> Here is the link: >> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ >> >> > > From john.cuthbertson at oracle.com Fri Mar 22 18:19:47 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 22 Mar 2013 11:19:47 -0700 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <514BFECC.8070206@oracle.com> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> Message-ID: <514CA0C3.3080306@oracle.com> Hi Bengt, Thanks for looking over the changes. Replies inline.... On 3/21/2013 11:48 PM, Bengt Rutisson wrote: > > Hi John, > > Your changes look good to me. > > I think your motivation for removing the verification from > universe2_init() and init_globals() is fine. Actually I wonder why > they were there in the first place, but they do seem intentionally put > in there. However, I'm fine with removing them. I think they we're deliberately added - probably a very long time ago. And Thomas' speculation that it's just to narrow the window in case of an error sounds plausible. But since parallel scavenge skipped the generations until the the first true GC - not sure how useful it would be for PS. Likewise for G1 - in the default case we skipped these extra verifications and in the first verification we skipped part of the heap. > > About the test. Great that you write a regression test for this! :) > > The @summary says that the test uses -XX:+VerifyDuringGC but the > command line is actually using -XX:+VerifyBeforeGC (which is correct, > I think). Also, would it make sense to have a separate test that > specifies -XX:+UseG1GC and checks the output that we expect to see? Yeah. Good catch. It should be with VerifyBeforeGC. Must have had marking on the brain. As for the test. I think we can check the output for "VerifyBefore" for all the collectors. I'll change the test. > > One question that is not strictly related to your change: > > The code to do the verification in Threads::create_vm() is: > > 3449 if (VerifyBeforeGC && > 3450 Universe::heap()->total_collections() >= VerifyGCStartAt) { > 3451 Universe::heap()->prepare_for_verify(); > 3452 Universe::verify(); // make sure we're starting with a > clean slate > 3453 } > > This is what it looked like before your change as well. But to me this > looks kind of odd. First, we re-use the flag VerifyBeforeGC even > though we are not about to do a GC. I can live with that, but it is > kind of strange. Then we have the check against VerifyGCStartAt. By > default this is 0 so we will do the verification. But why do we do > this check? There is no chance that we have been able to do any GC > yet, right? So, checking against Universe::heap()->total_collections() > seems unnecessary. We should either check VerifyGCStartAt == 0 or not > include that flag at all (best choice in my opinion). I think this was a case of cut-n-paste from the GC code. I agree overriding the flag is strange - especially given that we have a flag for VerifyOnExit (or something like that). But it a pattern that we, in the GC team, recognize. :) I agree that checking against total_collections() is bogus. It will be 0 and so we'll skip the verification if VerifyGCStartAt is anything other than 0. I guess two choices: 1. Add new flag (or rename existing VerifyOnExit to VerifyOnInitAndExit), or 2. Use (VerifyBeforeGC && VerifyGCStartAt == 0) Cheers, JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Fri Mar 22 19:02:23 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 22 Mar 2013 12:02:23 -0700 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <1363947317.2689.27.camel@cirrus> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> <1363947317.2689.27.camel@cirrus> Message-ID: <514CAABF.9010501@oracle.com> Hi Thomas, Thanks for looking over the changes. Replies inline.... On 3/22/2013 3:15 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2013-03-22 at 07:48 +0100, Bengt Rutisson wrote: >> Hi John, >> Your changes look good to me. >> >> I think your motivation for removing the verification from >> universe2_init() and init_globals() is fine. Actually I wonder why >> they were there in the first place, but they do seem intentionally put >> in there. However, I'm fine with removing them. > These verifications seem to make the intervals between verification > smaller to be able to pinpoint any problem location quicker. > Threads::create_vm() does a lot after all. Removal is fine with me as > well. That was my guess as well but it looks like only CMS and Serial would do some verification. PS looks like it skips checking it's generations until just before the first real proper GC. > Comparing to the comments on the CR (great analysis btw!), you opted for > the approach to just skip verification of roots, heap regions and remset > until a safepoint. From your analysis, the other option would have been > to allow a NULL VM thread in some places. > > Allowing a NULL VMThread would allow checking heap consistency right > after Universe::genesis(). It is probably not expected that there are > already issues about the heap at this stage, but since we're already > verifying, I'd tend to prefer the option that verifies as much as > possible. > (Did not really check if it would really make a difference) > > Maybe you could add a guarantee() or such in Threads::oops_do() and > Threads::possibly_parallel_oops_do() that only allowed a NULL VM Thread > during initialization? I wouldn't say "opted". I would say "made the -UseTLABS and +UseTLABS cases consistent". :) I actually tried to get enable the verification but after several different crash/assertion errors decided it wasn't worth it. To do it we would need to do it at a safepoint - hence the move of the verify to after the creation of the VM thread - so we have something to execute the VM op. It wasn't just a NULL VM thread. That was only the first error. Here's where I went: Crash #1: Null VMThread. Changed Threads::oops_do() and Threads::possibly_parallel_oops_do() to allow for a NULL VM thread. This kind of makes sense. Afterall if we don't have a VM thread, there's no need to scan it for oops. Assertion #2: Assertion failure in ObjectSynchronizer::oops_do(): > void ObjectSynchronizer::oops_do(OopClosure* f) { > assert(SafepointSynchronize::is_at_safepoint(), "must be at safepoint"); > for (ObjectMonitor* block = gBlockList; block != NULL; block = > next(block)) { > assert(block->object() == CHAINMARKER, "must be a block header"); > for (int i = 1; i < _BLOCKSIZE; i++) { > ObjectMonitor* mid = &block[i]; > if (mid->object() != NULL) { > f->do_oop((oop*)mid->object_addr()); > } > } > } > } > Changed this one to allow for execution during VM startup. Afterall gBlockList was null so executing the routine before any Java code was executed was safe. Assertion #3: Assertion failure in G1CollectedHeap::verify_region_sets(): > void G1CollectedHeap::verify_region_sets() { > assert_heap_locked_or_at_safepoint(true /* should_be_vm_thread */); Tried two approaches. The first was to lock the Heap_lock. That led to Assertion #4: Assertion failure in CodeCache::blobs_do: > void CodeCache::blobs_do(CodeBlobClosure* f) { > assert_locked_or_safepoint(CodeCache_lock); > FOR_ALL_ALIVE_BLOBS(cb) { > f->do_code_blob(cb); > > #ifdef ASSERT > if (cb->is_nmethod()) > ((nmethod*)cb)->verify_scavenge_root_oops(); > #endif //ASSERT > } > } Why this did not fail when the Heap_lock was not locked - I do not know. But locking the CodeCache_lock was out of the question. Regardless of the locking over between the CodeCache_lock and Heap_lock, you get the deadlock detection assertion messages - which was assertion #5. I then removed locking the Heap_lock and allowed G1CollectedHeap::verify_region_sets() to be executed during startup. I didn't even look at failure #6. Following this approach is not worth it. If we want to do then we will need to do it in a VMOperation as a separate changeset. >> One question that is not strictly related to your change: >> >> The code to do the verification in Threads::create_vm() is: >> >> 3449 if (VerifyBeforeGC && >> 3450 Universe::heap()->total_collections() >= VerifyGCStartAt) { >> 3451 Universe::heap()->prepare_for_verify(); >> 3452 Universe::verify(); // make sure we're starting with a >> clean slate >> 3453 } >> >> This is what it looked like before your change as well. But to me this >> looks kind of odd. First, we re-use the flag VerifyBeforeGC even >> though we are not about to do a GC. I can live with that, but it is > You mean because of the name of the flag? That's a point. Otoh at VM > start you're technically before the next gc (whenever this happens ;) > >> kind of strange. Then we have the check against VerifyGCStartAt. By >> default this is 0 so we will do the verification. But why do we do >> this check? There is no chance that we have been able to do any GC >> yet, right? So, checking against Universe::heap()->total_collections() > Some values of some command line options change VerifyGCStartAt to > eventually disable verification at VM startup (beginning > arguments.cpp:2004). > >> seems unnecessary. We should either check VerifyGCStartAt == 0 or not > I would not mind either way; but you still need the VerifyBeforeGC (or > another flag) because otherwise the verification would practically be > unconditional as the default value of VerifyGCStartAt is zero. In my response to Bengt - I said I think we have a few choices: * Add a new flag to verify the heap during VM startup. * Rename and extend the existing VerifyOnExit(??) flag to cover verifying during startup. * change the code to "VerifyBeforeGC && VerifyGCStartAt == 0" * Leave it as we, in the GC team, are familiar with that particular pattern. :) Thanks, JohnC From jon.masamitsu at oracle.com Fri Mar 22 20:56:23 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 22 Mar 2013 13:56:23 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514B966E.4060706@oracle.com> References: <514B966E.4060706@oracle.com> Message-ID: <514CC577.209@oracle.com> Tao, Changes look fine. I would remove the "likely" so that messages read like "and will be removed in a future release" Fewer words are better and the intent is still clear. Jon On 3/21/2013 4:23 PM, Tao Mao wrote: > A simple changeset. Need a reviewer! > > 8010518 Move deprecating CMSIncrementalMode from > Arguments::check_deprecated_gcs() to > Arguments::check_deprecated_gc_flags() > https://jbs.oracle.com/bugs/browse/JDK-8010518 > > webrev: > http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ > > changeset: > Cleanup suggested by Bengt. From jon.masamitsu at oracle.com Fri Mar 22 21:24:28 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 22 Mar 2013 14:24:28 -0700 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <1363934518.2463.48.camel@cirrus> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> <1363593549.2603.1.camel@cirrus> <514B8CC7.7060607@oracle.com> <1363934518.2463.48.camel@cirrus> Message-ID: <514CCC0C.4030403@oracle.com> Thomas, Thanks for the extra effort. A comment not about correctness but more for readability. > + if (is_allocatable(upper_limit)) { > + *limit = upper_limit; > + } else if (upper_limit < min_allocation_size) { > + *limit = upper_limit; > + } else if (!is_allocatable(min_allocation_size)) { > + // we found that not even min_allocation_size is allocatable. Return it > + // anyway. There is no point to search for a better value any more. > + *limit = min_allocation_size; In the first "else if" if you changed it to (upper_limit <= min_allocation_size) can you eliminate the second "else if" like this + if (is_allocatable(upper_limit)) { + *limit = upper_limit; + } else if (upper_limit <= min_allocation_size) { + *limit = upper_limit; And it might read more easily as + if (is_allocatable(upper_limit) || +upper_limit <= min_allocation_size) { + *limit = upper_limit; Otherwise, looks good. Jon On 3/21/2013 11:41 PM, Thomas Schatzl wrote: > On Thu, 2013-03-21 at 15:42 -0700, Tao Mao wrote: >> On 3/18/13 12:59 AM, Thomas Schatzl wrote: >>> Hi all, >>> >>> here is a new webrev for this issue. Changes are: >>> >>> - merged code for os::has_allocatable_memory_limit of linux/bsd/solaris >>> into a single method. >> So, where is the merged routine now? > Simply put into os_posix.cpp. > (http://cr.openjdk.java.net/~tschatzl/7112912/webrev.1/src/os/posix/vm/os_posix.cpp.udiff.html) > > This is similar to other OS methods shared by all Unix OSes, so that it > is found during compilation in all these OSes. Ie. this follows current > standards in that respect. > > As mentioned, the OS class is currently being refactored where > inheritance instead of #include is used to share functionality with all > OSes. At least I think this is the currently agreed upon approach by the > runtime team as far as I could understand. > > Thanks, > Thomas > From jon.masamitsu at oracle.com Fri Mar 22 22:23:50 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 22 Mar 2013 15:23:50 -0700 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <1363954351.2689.50.camel@cirrus> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> <1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus> Message-ID: <514CD9F6.3070902@oracle.com> This comment is only correct if InitialHeapSize is not set on the command line or at least that's my understanding. 2355 // Currently the minimum size and the initial heap sizes are the same. Until InitialHeapSize was introduced, the initial heap size was the minimum heap size. Sometime during jdk7 development the default heap size for the client VM was changed to use the same (or at least similar ergonomics heap sizing as with the server VM) with the exception of windows (maybe, not sure about the windows exception). The minimum heap size was not changed as far as I know. Part of the ergonomics heap sizing is that the initial heap size is calculated and is not the minimum heap size. The motivation for the initial heap size change was faster start up (didn't have to go through GC's to get a bigger heap). The motivation for the client VM using the ergonomics heap sizing was easy of use. With the minimum heap size staying the same, if the application did not need a heap that was as large as the initial heap size, the heap sizing would shrink the heap back down. That way any footprint increase would be transitory at start up and the heap size would evolve to what it had been before (was the hope). The actual flag InitialHeapSize was introduced to give the user some control over the InitialHeapSize if such control was really needed but I don't think it was supposed to affect the minimum heap size. If I run fastdebug jdk8 on solaris with java -client -XX:+PrintGCDetails -XX:+Verbose -XX:InitialHeapSize=32m -version part of the Verbose output says Minimum heap 5242880 Initial heap 33554432 Maximum heap 268435456 I think this changeset would make the minimum heap 32m. Jon On 3/22/2013 5:12 AM, Thomas Schatzl wrote: > Hi all, > > ping? > > On Mon, 2013-03-18 at 13:53 +0100, Thomas Schatzl wrote: >> Hi all, >> >> On Thu, 2013-03-14 at 11:17 +0100, Mikael Gerdin wrote: >>> Thomas, >>> >>> On 2013-03-14 09:28, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> please have a look at the following change which tries to make heap >>>> size argument processing more intuitive. >>>> >>>> The second two are no bugs imo as the user did not mention a bound for >>>> the maximum heap size in the arguments, so it would be free to choose >>>> anything >= InitialHeapSize. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~tschatzl/8006088/webrev/ >>>> >>>> The problem with the VM starting up when InitialHeapSize > MaxHeapSize >>>> is fixed in the first hunk of collectorPolicy.cpp where the respective >>>> sanity check has been added. >>>> >>>> The change for the "incompatible minimum and initial heap size is located >>>> in arguments.cpp. I simply made the processing of -XX:InitialHeapSize the >>>> same as -Xms and -XX:MaxHeapSize the same as -Xmx. >>>> >>>> The latter for consistency (using the same code path for -Xmx and >>>> -XX:MaxHeapSize), as at the moment it does not set any internal variables. >>>> >>>> The issues in (3) are fixed in the last two hunks of collectorPolicy.cpp >>>> where if New- and OldSize are greater than MaxHeapSize *and* MaxHeapSize >>>> has been set on the command line, New- and OldSize are shrunk to fit. >>> The code looks like it does what you describe :) >>> >>> Since the arguments parsing code is kind of hard to follow IMO and >>> seemingly hard to get right it might be a good idea to write a >>> regression test for this. >>> >>> Just writing a short jtreg test to launch vms with these arg >>> combinations that you described above and verify that we get the >>> expected outcome should not be too much code with the ProcessTools test >> done, added jtreg tests. >> >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.1/ >> >> Note that the code additionally removes two asserts that are imo invalid >> to do at this point. >> >> I.e. >> >> assert(max_heap >= InitialHeapSize, "Error");// or >= OldSize in 7196080 >> assert(max_heap >= NewSize, "Error"); >> >> The max_heap >= OldSize assert is problematic because its default value >> is 4M. So again, if you set MaxHeapSize to e.g. 1-3M, the assert will >> fail. >> >> The same applies to NewSize with a sufficiently small heap. >> >> There is the new sanity check collectorPolicy.cpp that checks whether >> MaxHeapSize >= InitialHeapSize also in product mode (i.e. conflicting >> command line params have been set). >> >> Additionally, NewSize and OldSize are adjusted to MaxHeapSize (or >> MaxHeapSize to NewSize + OldSize) later in the collector policy too. >> >> These asserts also cause different behavior with/without debug mode. > Note that in 7196080 these asserts have already been removed. > > Thomas > > > From tao.mao at oracle.com Sat Mar 23 03:50:54 2013 From: tao.mao at oracle.com (Tao Mao) Date: Fri, 22 Mar 2013 20:50:54 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514BDBB3.7060005@oracle.com> References: <514B966E.4060706@oracle.com> <514BDBB3.7060005@oracle.com> Message-ID: <514D269E.5020609@oracle.com> Thank you for review and suggestion, Bengt. The Jira is updated. Tao On 3/21/13 9:18 PM, Bengt Rutisson wrote: > > Hi Tao, > > The change looks good. > > The bug report is a little sparse on information - it basically just > contains the title. I think it could be worth adding a line about why > we want to do this and maybe also comment on why you update the > message for MaxGCMinorPauseMillis. > > Something like: > > "When Arguments::check_deprecated_gcs() was added the check for the > use of the deprecated flag CMSIncrementalMode was included there. > Later the Arguments::check_deprecated_gc_flags() method was added. > Since the CMSIncrementalMode is just a flag it seems more logical to > check it in Arguments::check_deprecated_gc_flags() than in > Arguments::check_deprecated_gcs()." > > You can probably come up with a short comment on the > MaxGCMinorPauseMillis message update. This was not suggested by me, so > I'll let you figure something out ;) > > Bengt > > On 3/22/13 12:23 AM, Tao Mao wrote: >> A simple changeset. Need a reviewer! >> >> 8010518 Move deprecating CMSIncrementalMode from >> Arguments::check_deprecated_gcs() to >> Arguments::check_deprecated_gc_flags() >> https://jbs.oracle.com/bugs/browse/JDK-8010518 >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >> >> changeset: >> Cleanup suggested by Bengt. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Sat Mar 23 03:51:46 2013 From: tao.mao at oracle.com (Tao Mao) Date: Fri, 22 Mar 2013 20:51:46 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514CC577.209@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> Message-ID: <514D26D2.1030705@oracle.com> Thank you for review and suggestion. A new webrev is updated. http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ Tao On 3/22/13 1:56 PM, Jon Masamitsu wrote: > Tao, > > Changes look fine. I would remove the "likely" so that messages read > like > > "and will be removed in a future release" > > Fewer words are better and the intent is still clear. > > Jon > > > On 3/21/2013 4:23 PM, Tao Mao wrote: >> A simple changeset. Need a reviewer! >> >> 8010518 Move deprecating CMSIncrementalMode from >> Arguments::check_deprecated_gcs() to >> Arguments::check_deprecated_gc_flags() >> https://jbs.oracle.com/bugs/browse/JDK-8010518 >> >> webrev: >> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >> >> changeset: >> Cleanup suggested by Bengt. > From leonid.mesnik at oracle.com Sat Mar 23 13:48:47 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Sat, 23 Mar 2013 17:48:47 +0400 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure In-Reply-To: <514C9C40.8070102@oracle.com> References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com> <514C9C40.8070102@oracle.com> Message-ID: <514DB2BF.8070602@oracle.com> John Thank you for review. Is it enough to push fix or I need another one? Leonid On 03/22/2013 10:00 PM, John Cuthbertson wrote: > Hi Leonid, > > This looks OK to me. > > JohnC > > On 3/22/2013 12:06 AM, Leonid Mesnik wrote: >> Could anyone please review this small test fix. >> >> Leonid >> On 03/20/2013 04:16 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Could you please review fix for 8009808 TEST-BUG : test case is >>> using bash style tests. Default shell for jtreg is bourne. thus >>> failure. >>> >>> I've completely rewritten test in java without major changes it test >>> logic. >>> I remove CMS so test could be run when CMS is not supported. Also I >>> changed max memory to 128M to reduce memory load and increase number >>> of GC log entries. >>> >>> Here is the link: >>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ >>> >>> >> >> > -- Leonid Mesnik JVM SQE From bengt.rutisson at oracle.com Sun Mar 24 20:16:22 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Sun, 24 Mar 2013 21:16:22 +0100 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514D26D2.1030705@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> Message-ID: <514F5F16.9080909@oracle.com> Hi Tao, On 3/23/13 4:51 AM, Tao Mao wrote: > Thank you for review and suggestion. A new webrev is updated. > http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ I like Jon's suggestion about removing the word "likely" but that means that you need to update these tests: test/gc/startup_warnings/TestCMSIncrementalMode.java test/gc/startup_warnings/TestIncGC.java Also, would it make sense to remove the word "likely" from the warning messages in Arguments::check_deprecated_gcs() too? In that case you need to update these tests as well: test/gc/startup_warnings/TestDefNewCMS.java test/gc/startup_warnings/TestParNewSerialOld.java Bengt > > Tao > > On 3/22/13 1:56 PM, Jon Masamitsu wrote: >> Tao, >> >> Changes look fine. I would remove the "likely" so that messages read >> like >> >> "and will be removed in a future release" >> >> Fewer words are better and the intent is still clear. >> >> Jon >> >> >> On 3/21/2013 4:23 PM, Tao Mao wrote: >>> A simple changeset. Need a reviewer! >>> >>> 8010518 Move deprecating CMSIncrementalMode from >>> Arguments::check_deprecated_gcs() to >>> Arguments::check_deprecated_gc_flags() >>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>> >>> changeset: >>> Cleanup suggested by Bengt. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Mar 25 07:11:43 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Mar 2013 08:11:43 +0100 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <514CA0C3.3080306@oracle.com> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> <514CA0C3.3080306@oracle.com> Message-ID: <514FF8AF.5010806@oracle.com> Hi John, Some comments inline... On 3/22/13 7:19 PM, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking over the changes. Replies inline.... > > On 3/21/2013 11:48 PM, Bengt Rutisson wrote: >> >> Hi John, >> >> Your changes look good to me. >> >> I think your motivation for removing the verification from >> universe2_init() and init_globals() is fine. Actually I wonder why >> they were there in the first place, but they do seem intentionally >> put in there. However, I'm fine with removing them. > > I think they we're deliberately added - probably a very long time ago. > And Thomas' speculation that it's just to narrow the window in case of > an error sounds plausible. But since parallel scavenge skipped the > generations until the the first true GC - not sure how useful it would > be for PS. Likewise for G1 - in the default case we skipped these > extra verifications and in the first verification we skipped part of > the heap. Sound reasonable. Thanks for the extra explanation. > >> >> About the test. Great that you write a regression test for this! :) >> >> The @summary says that the test uses -XX:+VerifyDuringGC but the >> command line is actually using -XX:+VerifyBeforeGC (which is correct, >> I think). Also, would it make sense to have a separate test that >> specifies -XX:+UseG1GC and checks the output that we expect to see? > > Yeah. Good catch. It should be with VerifyBeforeGC. Must have had > marking on the brain. > > As for the test. I think we can check the output for "VerifyBefore" > for all the collectors. I'll change the test. Great! > >> >> One question that is not strictly related to your change: >> >> The code to do the verification in Threads::create_vm() is: >> >> 3449 if (VerifyBeforeGC && >> 3450 Universe::heap()->total_collections() >= VerifyGCStartAt) { >> 3451 Universe::heap()->prepare_for_verify(); >> 3452 Universe::verify(); // make sure we're starting with a >> clean slate >> 3453 } >> >> This is what it looked like before your change as well. But to me >> this looks kind of odd. First, we re-use the flag VerifyBeforeGC even >> though we are not about to do a GC. I can live with that, but it is >> kind of strange. Then we have the check against VerifyGCStartAt. By >> default this is 0 so we will do the verification. But why do we do >> this check? There is no chance that we have been able to do any GC >> yet, right? So, checking against >> Universe::heap()->total_collections() seems unnecessary. We should >> either check VerifyGCStartAt == 0 or not include that flag at all >> (best choice in my opinion). > > I think this was a case of cut-n-paste from the GC code. I agree > overriding the flag is strange - especially given that we have a flag > for VerifyOnExit (or something like that). But it a pattern that we, > in the GC team, recognize. :) I agree that checking against > total_collections() is bogus. It will be 0 and so we'll skip the > verification if VerifyGCStartAt is anything other than 0. I guess two > choices: > > 1. Add new flag (or rename existing VerifyOnExit to > VerifyOnInitAndExit), or > 2. Use (VerifyBeforeGC && VerifyGCStartAt == 0) Right. I would prefer 1. but I'm fine with 2. Maybe 2. is more reasonable change to do for this fix. Perhaps 1. should be its own change. Either way is fine with me. Thanks, Bengt > > Cheers, > > JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Mon Mar 25 08:27:33 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 09:27:33 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <49558944-52CE-4DCF-8B0C-A07457CB0C78@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> <98626133-0e7f-4854-80f1-be415b711eb3@default> <5140F444.20808@oracle.com> <49558944-52CE-4DCF-8B0C-A07457CB0C78@oracle.com> Message-ID: <51500A75.5010408@oracle.com> All, I have updated the change to be more general. There is now a class called JDKToolLauncher that can be used to launch any JDK tool, not only jmap. Please see the description of the new class in the javadoc in the source file JDKToolLauncher.java. New webrev located at: http://cr.openjdk.java.net/~ehelin/8009408/webrev.04/ Thanks, Erik On 03/18/2013 10:06 AM, Staffan Larsen wrote: > Just a thought: JmapLauncher could benefit from being more general so that it could launch other JDK tools as well - there is nothing jmap-specific in the class. > > /Staffan > > On 13 mar 2013, at 22:48, Erik Helin wrote: > >> All, >> >> based on a discussion with Bengt and Christian, we decided to move the JmapLauncher into the existing testlibrary since it all tests are likely to benefit from it, not only GC tests. >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8009408/webrev.03/ >> >> Thanks, >> Erik >> >> On 03/12/2013 01:14 PM, Christian T?rnqvist wrote: >>> Hi Erik, >>> >>> The change looks good :) >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Erik Helin >>> Sent: den 11 mars 2013 16:26 >>> To: Staffan Larsen >>> Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian T?rnqvist >>> Subject: Re: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" >>> >>> All, >>> >>> I've updated the change quite a bit based on feedback from Bengt and Christian. >>> >>> The class JmapLauncher has moved to the newly created gc testlibrary. >>> This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to contain utilities that can be used by all the gc jtreg tests. If there are code that is of interest for additional tests, then code can be easily be moved from the gc testlibrary to the general testlibrary. >>> >>> I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of this new gc testlibrary. >>> >>> Please see new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ >>> >>> Thanks, >>> Erik >>> >>> On 03/08/2013 01:34 PM, Staffan Larsen wrote: >>>> Looks good to me. >>>> >>>> /Staffan >>>> >>>> On 8 mar 2013, at 13:36, Erik Helin wrote: >>>> >>>>> Bengt and Staffan, >>>>> >>>>> thanks for he feedback! >>>>> >>>>> I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. >>>>> >>>>> I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? >>>>> >>>>> Please see new webrev at: >>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Erik and Staffan, >>>>>> >>>>>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>>>>> that returns "-d64" if necessary. You can't use this as is since you >>>>>> need to get "J-d64" but I think we should do something to make your >>>>>> solution more general. >>>>>> >>>>>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>>>>> or adding a separate method that returns "JDK-tools formatted" args. >>>>>> It seems a bit too limited to fix this only for your particular >>>>>> test. Would be nice to get it in to the testlibrary somehow. >>>>>> >>>>>> Bengt >>>>>> >>>>>> >>>>>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>>>>> Looks good. I wish we could abstract this away so that not every >>>>>>> test needs to do this work. >>>>>>> >>>>>>> /Staffan (mobile) >>>>>>> >>>>>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>>>>> arch) when running jmap in the test >>>>>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>> >>>>> >>>> >>> >> > From erik.helin at oracle.com Mon Mar 25 08:32:59 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 09:32:59 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <514C1EF8.9060303@oracle.com> References: <514C1EF8.9060303@oracle.com> Message-ID: <51500BBB.8070702@oracle.com> All, I have updated the change based on internal feedback. The changes between webrev.00 and webrev.01 are mostly in the test code: - The test uses correct @summary description - The test now uses the correct command line flags - The test is more documented to describe how the test code is run There is also a very minor change in the hotspot code. I am now using the operator != instead of operator > when comparing the missed count. This was done just to make the diff one line smaller :) Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ Thanks, Erik On 03/22/2013 10:06 AM, Erik Helin wrote: > Hi all, > > I have refactored the HeapInspection class to prepare for the > vm/gc/detailed/object_count_after_gc event. > > The refactoring mainly consists of breaking up the rather long > heap_inspect function to multiple small functions that can be reused. > > I also moved the public enums used to initialize KlassInfoTable and > KlassInfoHisto to private constants. Now they no longer have to be > passed as an argument to the constructor. > > I also added a test to ensure that my refactoring did not break anything > (the test is not that extensive but at least it ensures that the basic > stuff is working). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 > > Testing: > - JPRT > - A new jtreg test (see webrev) > > Thanks, > Erik From staffan.larsen at oracle.com Mon Mar 25 08:35:34 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Mar 2013 09:35:34 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <51500A75.5010408@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> <98626133-0e7f-4854-80f1-be415b711eb3@default> <5140F444.20808@oracle.com> <49558944-52CE-4DCF-8B0C-A07457CB0C78@oracle.com> <51500A75.5010408@oracle.com> Message-ID: <9709CAFF-3241-462F-9368-E78D60D11B05@oracle.com> Vert nice! /Staffan On 25 mar 2013, at 09:27, Erik Helin wrote: > All, > > I have updated the change to be more general. There is now a class called JDKToolLauncher that can be used to launch any JDK tool, not only jmap. > > Please see the description of the new class in the javadoc in the source file JDKToolLauncher.java. > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.04/ > > Thanks, > Erik > > On 03/18/2013 10:06 AM, Staffan Larsen wrote: >> Just a thought: JmapLauncher could benefit from being more general so that it could launch other JDK tools as well - there is nothing jmap-specific in the class. >> >> /Staffan >> >> On 13 mar 2013, at 22:48, Erik Helin wrote: >> >>> All, >>> >>> based on a discussion with Bengt and Christian, we decided to move the JmapLauncher into the existing testlibrary since it all tests are likely to benefit from it, not only GC tests. >>> >>> Please see new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.03/ >>> >>> Thanks, >>> Erik >>> >>> On 03/12/2013 01:14 PM, Christian T?rnqvist wrote: >>>> Hi Erik, >>>> >>>> The change looks good :) >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Erik Helin >>>> Sent: den 11 mars 2013 16:26 >>>> To: Staffan Larsen >>>> Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian T?rnqvist >>>> Subject: Re: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" >>>> >>>> All, >>>> >>>> I've updated the change quite a bit based on feedback from Bengt and Christian. >>>> >>>> The class JmapLauncher has moved to the newly created gc testlibrary. >>>> This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to contain utilities that can be used by all the gc jtreg tests. If there are code that is of interest for additional tests, then code can be easily be moved from the gc testlibrary to the general testlibrary. >>>> >>>> I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of this new gc testlibrary. >>>> >>>> Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/08/2013 01:34 PM, Staffan Larsen wrote: >>>>> Looks good to me. >>>>> >>>>> /Staffan >>>>> >>>>> On 8 mar 2013, at 13:36, Erik Helin wrote: >>>>> >>>>>> Bengt and Staffan, >>>>>> >>>>>> thanks for he feedback! >>>>>> >>>>>> I've updated the change to make use of the method getPlatformSpecificVMArgs() and also abstracted the jmap command generation slightly. >>>>>> >>>>>> I don't know if this new little class, JMapLauncher, should be part of the testlibrary or not, or if we should put parts of it in the testlibrary. Christian, maybe you can comment on this? >>>>>> >>>>>> Please see new webrev at: >>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Erik and Staffan, >>>>>>> >>>>>>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>>>>>> that returns "-d64" if necessary. You can't use this as is since you >>>>>>> need to get "J-d64" but I think we should do something to make your >>>>>>> solution more general. >>>>>>> >>>>>>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>>>>>> or adding a separate method that returns "JDK-tools formatted" args. >>>>>>> It seems a bit too limited to fix this only for your particular >>>>>>> test. Would be nice to get it in to the testlibrary somehow. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>>>>>> Looks good. I wish we could abstract this away so that not every >>>>>>>> test needs to do this work. >>>>>>>> >>>>>>>> /Staffan (mobile) >>>>>>>> >>>>>>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>>>>>> arch) when running jmap in the test >>>>>>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Erik >>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.schatzl at oracle.com Mon Mar 25 08:36:49 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Mar 2013 09:36:49 +0100 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <514CAABF.9010501@oracle.com> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> <1363947317.2689.27.camel@cirrus> <514CAABF.9010501@oracle.com> Message-ID: <1364200609.2703.3.camel@cirrus> Hi, On Fri, 2013-03-22 at 12:02 -0700, John Cuthbertson wrote: > Hi Thomas, > > Thanks for looking over the changes. Replies inline.... > > > Allowing a NULL VMThread would allow checking heap consistency right > > after Universe::genesis(). It is probably not expected that there are > > already issues about the heap at this stage, but since we're already > > verifying, I'd tend to prefer the option that verifies as much as > > possible. > > (Did not really check if it would really make a difference) > > [ long explanation that doing so is not that easy... ] > > Following this approach is not worth it. If we want to do then we will > need to do it in a VMOperation as a separate changeset. I agree. Thanks for clarification. > > seems unnecessary. We should either check VerifyGCStartAt == 0 or not > > I would not mind either way; but you still need the VerifyBeforeGC (or > > another flag) because otherwise the verification would practically be > > unconditional as the default value of VerifyGCStartAt is zero. > > In my response to Bengt - I said I think we have a few choices: > > * Add a new flag to verify the heap during VM startup. > * Rename and extend the existing VerifyOnExit(??) flag to cover > verifying during startup. > > * change the code to "VerifyBeforeGC && VerifyGCStartAt == 0" This one is probably the most reasonable for this fix as Bengt indicates. Thomas From thomas.schatzl at oracle.com Mon Mar 25 09:24:27 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Mar 2013 10:24:27 +0100 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <514CD9F6.3070902@oracle.com> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> <1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com> Message-ID: <1364203467.2703.41.camel@cirrus> Hi, On Fri, 2013-03-22 at 15:23 -0700, Jon Masamitsu wrote: > This comment is only correct if InitialHeapSize is not set on the > command line or at least that's my understanding. > > 2355 // Currently the minimum size and the initial heap sizes are the same. > > Until InitialHeapSize was introduced, the initial heap size was the > minimum heap size. The implementation unconditionally sets both minimum and initial heap size to the given value. The change only adds this comment (for clarification that this has been an intentional decision). I looked a little more into how -Xms is documented, and I actually found conflicting information: java -X output: -Xms "set initial Java heap size" Oracle documentation: "-Xms is minimum heap size (only)" http://docs.oracle.com/cd/E15523_01/web.1111/e13814/jvm_tuning.htm http://docs.oracle.com/cd/E19528-01/819-4742/abeik/index.html http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#generation_sizing http://docs.oracle.com/cd/E19957-01/817-2180-10/pt_chap5.html and InitialHeapSize documentation: "Initial heap size (in bytes); zero means OldSize + NewSize" Other documentation gathered from searching the web, paraphrasing: "Minimum heap size cannot be set, only initial heap size.", and the general recommendation to set -Xms to -Xmx. Since the documentation for both -Xms and InitialHeapSize match, this change modifies the code so that they use the same implementation. Assuming that the in-product documentation is the most current/valid one; I did not consider searching specifically for oracle documentation at that time. > Sometime during jdk7 development the default heap size for the >client VM was changed to use the same (or at least similar ergonomics >heap sizing as with the server VM) with the exception of windows >(maybe, not sure about the windows exception). I cannot find a Windows exception, but maybe I overlooked that. I will have another look. > The minimum heap size was not changed as far as I know. Part of >the ergonomics heap sizing is that the initial heap size is calculated >and is not the minimum heap size. The motivation for the initial heap >size change was faster start up (didn't have to go through GC's to get >a bigger heap). The motivation for the client VM using the ergonomics >heap sizing was easy of use. With the minimum heap size staying the >same, if the application did not need a heap that was as large as the >initial heap size, the heap sizing would shrink the heap back down. >That way any footprint increase would be transitory at start up > and the heap size would evolve to what it had been before (was the hope). > > The actual flag InitialHeapSize was introduced to give the user some > control over the InitialHeapSize if such control was really needed but >I don't think it was supposed to affect the minimum heap size. I understand the motivation of having a separate control to set the minimum and initial heap size. However the implementation and the documentation of these switches contradict to some degree. What is the expected behavior? One suggestion: -Xms sets only minimum heap size (and automatically adjust InitialHeapSize if not set manually; verify otherwise). Also change the documentation string. -XX:InitialHeapSize sets only initial heap size; if set on command line, check validity against minimum heap size at some point. Otherwise adapt to detected minimum heap size setting. If -Xms is not set, set minimum heap size to the same value. The current behavior, that -Xms sets both initial and minimum heap size is very unsatisfying and not easily discoverable (which was the cause for this CR). The order of switches would be important, in addition to -Xms doing something unexpected. Additionally the initial/minimum heap sizes are not synchronized, so a user also sometimes gets strange error messages. The documentation for -Xms via java -X also contradicts (or at least omits important information) both external documentation and actual behavior. What do you think? Thanks for looking at that, Thomas From bengt.rutisson at oracle.com Mon Mar 25 10:48:18 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Mar 2013 11:48:18 +0100 Subject: RFR (XS): 8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1" In-Reply-To: <51500A75.5010408@oracle.com> References: <51361FCE.30304@oracle.com> <78DE7648-6F09-4BD5-8A72-292AC6CF4F16@oracle.com> <513706E1.2070605@oracle.com> <5139DB53.3030001@oracle.com> <2173A61C-7DAD-4854-A4EF-406AD528732E@oracle.com> <513DF780.3040709@oracle.com> <98626133-0e7f-4854-80f1-be415b711eb3@default> <5140F444.20808@oracle.com> <49558944-52CE-4DCF-8B0C-A07457CB0C78@oracle.com> <51500A75.5010408@oracle.com> Message-ID: <51502B72.4010108@oracle.com> Hi Erik, Looks great! Thanks, Bengt On 3/25/13 9:27 AM, Erik Helin wrote: > All, > > I have updated the change to be more general. There is now a class > called JDKToolLauncher that can be used to launch any JDK tool, not > only jmap. > > Please see the description of the new class in the javadoc in the > source file JDKToolLauncher.java. > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8009408/webrev.04/ > > Thanks, > Erik > > On 03/18/2013 10:06 AM, Staffan Larsen wrote: >> Just a thought: JmapLauncher could benefit from being more general so >> that it could launch other JDK tools as well - there is nothing >> jmap-specific in the class. >> >> /Staffan >> >> On 13 mar 2013, at 22:48, Erik Helin wrote: >> >>> All, >>> >>> based on a discussion with Bengt and Christian, we decided to move >>> the JmapLauncher into the existing testlibrary since it all tests >>> are likely to benefit from it, not only GC tests. >>> >>> Please see new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.03/ >>> >>> Thanks, >>> Erik >>> >>> On 03/12/2013 01:14 PM, Christian T?rnqvist wrote: >>>> Hi Erik, >>>> >>>> The change looks good :) >>>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Erik Helin >>>> Sent: den 11 mars 2013 16:26 >>>> To: Staffan Larsen >>>> Cc: Bengt Rutisson; hotspot-gc-dev openjdk.java.net; Christian >>>> T?rnqvist >>>> Subject: Re: RFR (XS): 8009408: >>>> gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit >>>> code 1" >>>> >>>> All, >>>> >>>> I've updated the change quite a bit based on feedback from Bengt >>>> and Christian. >>>> >>>> The class JmapLauncher has moved to the newly created gc testlibrary. >>>> This gc testlibrary, com.oracle.java.testlibrary.gc, is meant to >>>> contain utilities that can be used by all the gc jtreg tests. If >>>> there are code that is of interest for additional tests, then code >>>> can be easily be moved from the gc testlibrary to the general >>>> testlibrary. >>>> >>>> I have updated the ClassMetaspaceSizeInJmapHeap.java to make use of >>>> this new gc testlibrary. >>>> >>>> Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.02/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/08/2013 01:34 PM, Staffan Larsen wrote: >>>>> Looks good to me. >>>>> >>>>> /Staffan >>>>> >>>>> On 8 mar 2013, at 13:36, Erik Helin wrote: >>>>> >>>>>> Bengt and Staffan, >>>>>> >>>>>> thanks for he feedback! >>>>>> >>>>>> I've updated the change to make use of the method >>>>>> getPlatformSpecificVMArgs() and also abstracted the jmap command >>>>>> generation slightly. >>>>>> >>>>>> I don't know if this new little class, JMapLauncher, should be >>>>>> part of the testlibrary or not, or if we should put parts of it >>>>>> in the testlibrary. Christian, maybe you can comment on this? >>>>>> >>>>>> Please see new webrev at: >>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>> On 03/06/2013 10:05 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Erik and Staffan, >>>>>>> >>>>>>> The ProcessTools class has the method getPlatformSpecificVMArgs() >>>>>>> that returns "-d64" if necessary. You can't use this as is since >>>>>>> you >>>>>>> need to get "J-d64" but I think we should do something to make your >>>>>>> solution more general. >>>>>>> >>>>>>> Either adding a possible prefix to the getPlatformSpecificVMArgs() >>>>>>> or adding a separate method that returns "JDK-tools formatted" >>>>>>> args. >>>>>>> It seems a bit too limited to fix this only for your particular >>>>>>> test. Would be nice to get it in to the testlibrary somehow. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>> On 3/5/13 5:55 PM, Staffan Larsen wrote: >>>>>>>> Looks good. I wish we could abstract this away so that not every >>>>>>>> test needs to do this work. >>>>>>>> >>>>>>>> /Staffan (mobile) >>>>>>>> >>>>>>>> On 5 mar 2013, at 17:39, Erik Helin wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> this change adds the option "-J-d64" or "-J-d32" (depending on >>>>>>>>> arch) when running jmap in the test >>>>>>>>> hotspot/test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~ehelin/8009408/webrev.00/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009408 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Erik >>>>>>> >>>>>> >>>>> >>>> >>> >> > From bengt.rutisson at oracle.com Mon Mar 25 10:58:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Mar 2013 11:58:06 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <51500BBB.8070702@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> Message-ID: <51502DBE.3040704@oracle.com> Hi Erik, Changes look good! One minor nit. I think the test contains the wrong bug number: * @bug 8004924 Bengt On 3/25/13 9:32 AM, Erik Helin wrote: > All, > > I have updated the change based on internal feedback. > > The changes between webrev.00 and webrev.01 are mostly in the test code: > - The test uses correct @summary description > - The test now uses the correct command line flags > - The test is more documented to describe how the test code is run > > There is also a very minor change in the hotspot code. I am now using > the operator != instead of operator > when comparing the missed count. > This was done just to make the diff one line smaller :) > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ > > Thanks, > Erik > > On 03/22/2013 10:06 AM, Erik Helin wrote: >> Hi all, >> >> I have refactored the HeapInspection class to prepare for the >> vm/gc/detailed/object_count_after_gc event. >> >> The refactoring mainly consists of breaking up the rather long >> heap_inspect function to multiple small functions that can be reused. >> >> I also moved the public enums used to initialize KlassInfoTable and >> KlassInfoHisto to private constants. Now they no longer have to be >> passed as an argument to the constructor. >> >> I also added a test to ensure that my refactoring did not break anything >> (the test is not that extensive but at least it ensures that the basic >> stuff is working). >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >> >> Testing: >> - JPRT >> - A new jtreg test (see webrev) >> >> Thanks, >> Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Mar 25 11:28:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Mar 2013 12:28:06 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <514C1C7A.7020204@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> Message-ID: <515034C6.1040202@oracle.com> Hi Erik, This looks good. One small nit. In VM_GC_HeapInspection::collect() you preserved the comment from VM_GC_HeapInspection::doit(). The comment talks about issuing a warning message, but the code to log that message is left in doit(). Could we update the comment to be more consistent with the new code? Thanks, Bengt On 3/22/13 9:55 AM, Erik Helin wrote: > All, > > based on internal feedback, this change has been updated. > > The event has been renamed to vm/gc/detailed/object_count_after_gc. > Furthermore, the part of the change that updated > heapInspection.cpp/hpp has been extracted to a separate change (also > out for review on hotspot-gc-dev at openjdk.java.net). > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ > > Thanks, > Erik > > On 03/16/2013 11:38 AM, Erik Helin wrote: >> Hi all, >> >> this change adds an event, vm/gc/detailed/class_count_after_gc, that >> sends information about the number of instances of each class on the >> heap (as well as size and the name of the class). >> >> The event is sent after the marking phase for all old collections and an >> object will be counted as live if the GC think that the object is live >> (this is only tricky in the case of a concurrent collection). >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From erik.helin at oracle.com Mon Mar 25 11:29:49 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 12:29:49 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <51502DBE.3040704@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> <51502DBE.3040704@oracle.com> Message-ID: <5150352D.6090407@oracle.com> Bengt, On 03/25/2013 11:58 AM, Bengt Rutisson wrote: > > Hi Erik, > > Changes look good! > > One minor nit. I think the test contains the wrong bug number: > > * @bug 8004924 Agree, I will fix. Thanks, Erik > Bengt > > On 3/25/13 9:32 AM, Erik Helin wrote: >> All, >> >> I have updated the change based on internal feedback. >> >> The changes between webrev.00 and webrev.01 are mostly in the test code: >> - The test uses correct @summary description >> - The test now uses the correct command line flags >> - The test is more documented to describe how the test code is run >> >> There is also a very minor change in the hotspot code. I am now using >> the operator != instead of operator > when comparing the missed count. >> This was done just to make the diff one line smaller :) >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ >> >> Thanks, >> Erik >> >> On 03/22/2013 10:06 AM, Erik Helin wrote: >>> Hi all, >>> >>> I have refactored the HeapInspection class to prepare for the >>> vm/gc/detailed/object_count_after_gc event. >>> >>> The refactoring mainly consists of breaking up the rather long >>> heap_inspect function to multiple small functions that can be reused. >>> >>> I also moved the public enums used to initialize KlassInfoTable and >>> KlassInfoHisto to private constants. Now they no longer have to be >>> passed as an argument to the constructor. >>> >>> I also added a test to ensure that my refactoring did not break anything >>> (the test is not that extensive but at least it ensures that the basic >>> stuff is working). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >>> >>> Testing: >>> - JPRT >>> - A new jtreg test (see webrev) >>> >>> Thanks, >>> Erik >> > > From erik.helin at oracle.com Mon Mar 25 11:33:15 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 12:33:15 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <515034C6.1040202@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> <515034C6.1040202@oracle.com> Message-ID: <515035FB.4020101@oracle.com> Bengt, On 03/25/2013 12:28 PM, Bengt Rutisson wrote: > > Hi Erik, > > This looks good. > > One small nit. In VM_GC_HeapInspection::collect() you preserved the > comment from VM_GC_HeapInspection::doit(). The comment talks about > issuing a warning message, but the code to log that message is left in > doit(). Could we update the comment to be more consistent with the new > code? I will update the comment. Thanks, Erik > Thanks, > Bengt > > On 3/22/13 9:55 AM, Erik Helin wrote: >> All, >> >> based on internal feedback, this change has been updated. >> >> The event has been renamed to vm/gc/detailed/object_count_after_gc. >> Furthermore, the part of the change that updated >> heapInspection.cpp/hpp has been extracted to a separate change (also >> out for review on hotspot-gc-dev at openjdk.java.net). >> >> New webrev located at: >> http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ >> >> Thanks, >> Erik >> >> On 03/16/2013 11:38 AM, Erik Helin wrote: >>> Hi all, >>> >>> this change adds an event, vm/gc/detailed/class_count_after_gc, that >>> sends information about the number of instances of each class on the >>> heap (as well as size and the name of the class). >>> >>> The event is sent after the marking phase for all old collections and an >>> object will be counted as live if the GC think that the object is live >>> (this is only tricky in the case of a concurrent collection). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik >> > From erik.helin at oracle.com Mon Mar 25 13:16:48 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 14:16:48 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <5150352D.6090407@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> <51502DBE.3040704@oracle.com> <5150352D.6090407@oracle.com> Message-ID: <51504E40.7050808@oracle.com> All, I have updated the change based on feedback from Bengt and Jesper. Differences between webrev.01 and webrev.02: - Added #else clause in HeapInspection::start_of_perm_gen to make sure that no compilers will isse any warnings. - Removed the variable need_epilogue in HeapInspection::instance_inspection, just kept the comment. - Updated the @bug annotation of the test to the correct bug number, 8010294. New webrev located at: http://cr.openjdk.java.net/~ehelin/8010294/webrev.02/ Thanks, Erik On 03/25/2013 12:29 PM, Erik Helin wrote: > Bengt, > > On 03/25/2013 11:58 AM, Bengt Rutisson wrote: >> >> Hi Erik, >> >> Changes look good! >> >> One minor nit. I think the test contains the wrong bug number: >> >> * @bug 8004924 > > Agree, I will fix. > > Thanks, > Erik > >> Bengt >> >> On 3/25/13 9:32 AM, Erik Helin wrote: >>> All, >>> >>> I have updated the change based on internal feedback. >>> >>> The changes between webrev.00 and webrev.01 are mostly in the test code: >>> - The test uses correct @summary description >>> - The test now uses the correct command line flags >>> - The test is more documented to describe how the test code is run >>> >>> There is also a very minor change in the hotspot code. I am now using >>> the operator != instead of operator > when comparing the missed count. >>> This was done just to make the diff one line smaller :) >>> >>> Please see new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ >>> >>> Thanks, >>> Erik >>> >>> On 03/22/2013 10:06 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> I have refactored the HeapInspection class to prepare for the >>>> vm/gc/detailed/object_count_after_gc event. >>>> >>>> The refactoring mainly consists of breaking up the rather long >>>> heap_inspect function to multiple small functions that can be reused. >>>> >>>> I also moved the public enums used to initialize KlassInfoTable and >>>> KlassInfoHisto to private constants. Now they no longer have to be >>>> passed as an argument to the constructor. >>>> >>>> I also added a test to ensure that my refactoring did not break >>>> anything >>>> (the test is not that extensive but at least it ensures that the basic >>>> stuff is working). >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >>>> >>>> Testing: >>>> - JPRT >>>> - A new jtreg test (see webrev) >>>> >>>> Thanks, >>>> Erik >>> >> >> > From mikael.gerdin at oracle.com Mon Mar 25 13:28:44 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 25 Mar 2013 14:28:44 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <51500BBB.8070702@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> Message-ID: <5150510C.4070008@oracle.com> Erik, On 2013-03-25 09:32, Erik Helin wrote: > All, > > I have updated the change based on internal feedback. > > The changes between webrev.00 and webrev.01 are mostly in the test code: > - The test uses correct @summary description > - The test now uses the correct command line flags > - The test is more documented to describe how the test code is run > > There is also a very minor change in the hotspot code. I am now using > the operator != instead of operator > when comparing the missed count. > This was done just to make the diff one line smaller :) > > Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ This looks good, I have some small comments but I'll leave it to you to decide if you want to fix them or not. When you're changing this line, would you mind adding a space before "true"? _elements = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(_histo_initial_size,true); Did you consider using SharedHeap::heap() instead of: SharedHeap* sh = (SharedHeap*)Universe::heap(); Either way, ship it. /Mikael > > Thanks, > Erik > > On 03/22/2013 10:06 AM, Erik Helin wrote: >> Hi all, >> >> I have refactored the HeapInspection class to prepare for the >> vm/gc/detailed/object_count_after_gc event. >> >> The refactoring mainly consists of breaking up the rather long >> heap_inspect function to multiple small functions that can be reused. >> >> I also moved the public enums used to initialize KlassInfoTable and >> KlassInfoHisto to private constants. Now they no longer have to be >> passed as an argument to the constructor. >> >> I also added a test to ensure that my refactoring did not break anything >> (the test is not that extensive but at least it ensures that the basic >> stuff is working). >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >> >> Testing: >> - JPRT >> - A new jtreg test (see webrev) >> >> Thanks, >> Erik > From nils.eliasson at oracle.com Mon Mar 25 13:34:57 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 25 Mar 2013 14:34:57 +0100 Subject: RFR(S): 8007701: Hotspot trace Allocation Events In-Reply-To: <514C542C.3090200@oracle.com> References: <51423640.4000506@oracle.com> <5149D4BF.8000704@oracle.com> <514C2069.2070008@oracle.com> <514C542C.3090200@oracle.com> Message-ID: <51505281.5060302@oracle.com> Hi Bengt, Well, collectedHeap already includes all kinds of gc-stuff - "gc_implementation/shared/gcTrace.hpp" for example. Anyway - I moved them out. Had to have both a cpp and a hpp file since collectedHeap can't include trace/tracing.hpp which the events require. C1-Allocations is covered when using the flag -XX:-FastTLABRefill (will be documented). And when running with G1 it is already default off (because of the barriers that is required). FastTLABRefill could probably be retired when proper regression anlysis has been done. Wouldn't miss the pages of platform dependent code. New rev: http://cr.openjdk.java.net/~neliasso/8007701/webrev.07/ //Nils Eliasson On 2013-03-22 13:53, Bengt Rutisson wrote: > > Hi Nils, > > Overall this looks good, but I have two questions. > > Could we add a new class (maybe called AllocTracer?) instead of adding > the two static send methods to GCTracer? It feels a bit wrong to have > the GCTracer handle things that don't happen during a GC. > > How do we handle the fact that this does not cover the C1 tlab > allocations? Is there a bug to track that? > > Thanks, > Bengt > > On 3/22/13 10:12 AM, Nils Eliasson wrote: >> Latest webrev after more feedback: >> >> http://cr.openjdk.java.net/~neliasso/8007701/webrev.06/ >> >> //N >> >> >> On 2013-03-20 16:24, Nils Eliasson wrote: >>> Thanks for your review Erik, >>> >>> Updated the webrev with your suggestions >>> - Moved alloction events to GCTrace >>> - Renamed class event field to "class" >>> >>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/ >>> http://bugs.sun.com/view_bug.do?bug_id=8007701 >>> >>> //Nils Eliasson >>> >>> >>> On 2013-03-14 21:42, Nils Eliasson wrote: >>>> Hi all, >>>> >>>> I would like a review for this change that introduces two new >>>> tracing events. >>>> >>>> "AllocationInNewTLAB" is sent for the first object in a new TLAB >>>> and gives a reasonably cheap and reasonably fair object sampling. >>>> "AllocationOutsideTLAB" is sent for each object that gets allocated >>>> outside the TLABs. (The object doesn't fit or would cause too much >>>> wasted free space if the tlab was discarded.) >>>> >>>> These events use the allocation slow path in CollectedHeap which is >>>> used by default in the template interpreter and the C2 compiler. It >>>> is also used for all TLAB refills in the C1-compiler if the flag >>>> -XX:-FastTLABRefill is supplied. >>>> >>>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ >>>> http://bugs.sun.com/view_bug.do?bug_id=8007701 >>>> >>>> The event code for AllocationOutsideTLAB had to be put in >>>> CollectedHeap.cpp since tracing.hpp can't be included into >>>> CollectedHeap.inline.hpp. >>>> >>>> Thanks, >>>> Nils Eliasson >>> >> > From erik.helin at oracle.com Mon Mar 25 13:36:37 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 14:36:37 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <5150510C.4070008@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> <5150510C.4070008@oracle.com> Message-ID: <515052E5.6010003@oracle.com> Hi Mikael, thanks for reviewing! On 03/25/2013 02:28 PM, Mikael Gerdin wrote: > Erik, > > > On 2013-03-25 09:32, Erik Helin wrote: >> All, >> >> I have updated the change based on internal feedback. >> >> The changes between webrev.00 and webrev.01 are mostly in the test code: >> - The test uses correct @summary description >> - The test now uses the correct command line flags >> - The test is more documented to describe how the test code is run >> >> There is also a very minor change in the hotspot code. I am now using >> the operator != instead of operator > when comparing the missed count. >> This was done just to make the diff one line smaller :) >> >> Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ > > This looks good, > I have some small comments but I'll leave it to you to decide if you > want to fix them or not. > > When you're changing this line, would you mind adding a space before > "true"? > _elements = new (ResourceObj::C_HEAP, mtInternal) > GrowableArray(_histo_initial_size,true); > Sure, I will add the space before I push. > Did you consider using > SharedHeap::heap() instead of: > SharedHeap* sh = (SharedHeap*)Universe::heap(); > Nope, did not know about this, thanks for the tip! I will update the code before I push. Thanks, Erik > Either way, ship it. > /Mikael > > >> >> Thanks, >> Erik >> >> On 03/22/2013 10:06 AM, Erik Helin wrote: >>> Hi all, >>> >>> I have refactored the HeapInspection class to prepare for the >>> vm/gc/detailed/object_count_after_gc event. >>> >>> The refactoring mainly consists of breaking up the rather long >>> heap_inspect function to multiple small functions that can be reused. >>> >>> I also moved the public enums used to initialize KlassInfoTable and >>> KlassInfoHisto to private constants. Now they no longer have to be >>> passed as an argument to the constructor. >>> >>> I also added a test to ensure that my refactoring did not break anything >>> (the test is not that extensive but at least it ensures that the basic >>> stuff is working). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >>> >>> Testing: >>> - JPRT >>> - A new jtreg test (see webrev) >>> >>> Thanks, >>> Erik >> From erik.helin at oracle.com Mon Mar 25 13:47:44 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 14:47:44 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <515035FB.4020101@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> <515034C6.1040202@oracle.com> <515035FB.4020101@oracle.com> Message-ID: <51505580.5040302@oracle.com> All, I have updated the change based on feedback from Bengt and Jesper. The differences between webrev.01 and webrev.02 are: - Updated the comment in VM_GC_HeapInspection. - Updated the label for the object count event. New webrev located at: http://cr.openjdk.java.net/~ehelin/8008920/webrev.02/ Thanks, Erik On 03/25/2013 12:33 PM, Erik Helin wrote: > Bengt, > > On 03/25/2013 12:28 PM, Bengt Rutisson wrote: >> >> Hi Erik, >> >> This looks good. >> >> One small nit. In VM_GC_HeapInspection::collect() you preserved the >> comment from VM_GC_HeapInspection::doit(). The comment talks about >> issuing a warning message, but the code to log that message is left in >> doit(). Could we update the comment to be more consistent with the new >> code? > > I will update the comment. > > Thanks, > Erik > >> Thanks, >> Bengt >> >> On 3/22/13 9:55 AM, Erik Helin wrote: >>> All, >>> >>> based on internal feedback, this change has been updated. >>> >>> The event has been renamed to vm/gc/detailed/object_count_after_gc. >>> Furthermore, the part of the change that updated >>> heapInspection.cpp/hpp has been extracted to a separate change (also >>> out for review on hotspot-gc-dev at openjdk.java.net). >>> >>> New webrev located at: >>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ >>> >>> Thanks, >>> Erik >>> >>> On 03/16/2013 11:38 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change adds an event, vm/gc/detailed/class_count_after_gc, that >>>> sends information about the number of instances of each class on the >>>> heap (as well as size and the name of the class). >>>> >>>> The event is sent after the marking phase for all old collections >>>> and an >>>> object will be counted as live if the GC think that the object is live >>>> (this is only tricky in the case of a concurrent collection). >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >>>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Erik >>> >> > From mikael.gerdin at oracle.com Mon Mar 25 14:01:53 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 25 Mar 2013 15:01:53 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <51505580.5040302@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> <515034C6.1040202@oracle.com> <515035FB.4020101@oracle.com> <51505580.5040302@oracle.com> Message-ID: <515058D1.7010705@oracle.com> Erik, On 2013-03-25 14:47, Erik Helin wrote: > All, > > I have updated the change based on feedback from Bengt and Jesper. > > The differences between webrev.01 and webrev.02 are: > - Updated the comment in VM_GC_HeapInspection. > - Updated the label for the object count event. > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8008920/webrev.02/ In concurrentMarkSweepGeneration.cpp: It would feel more appropriate to have the call to report_object_count_after_gc to before we _collectorState to Sweeping. The rest looks good to me. /Mikael > > Thanks, > Erik > > On 03/25/2013 12:33 PM, Erik Helin wrote: >> Bengt, >> >> On 03/25/2013 12:28 PM, Bengt Rutisson wrote: >>> >>> Hi Erik, >>> >>> This looks good. >>> >>> One small nit. In VM_GC_HeapInspection::collect() you preserved the >>> comment from VM_GC_HeapInspection::doit(). The comment talks about >>> issuing a warning message, but the code to log that message is left in >>> doit(). Could we update the comment to be more consistent with the new >>> code? >> >> I will update the comment. >> >> Thanks, >> Erik >> >>> Thanks, >>> Bengt >>> >>> On 3/22/13 9:55 AM, Erik Helin wrote: >>>> All, >>>> >>>> based on internal feedback, this change has been updated. >>>> >>>> The event has been renamed to vm/gc/detailed/object_count_after_gc. >>>> Furthermore, the part of the change that updated >>>> heapInspection.cpp/hpp has been extracted to a separate change (also >>>> out for review on hotspot-gc-dev at openjdk.java.net). >>>> >>>> New webrev located at: >>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/16/2013 11:38 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this change adds an event, vm/gc/detailed/class_count_after_gc, that >>>>> sends information about the number of instances of each class on the >>>>> heap (as well as size and the name of the class). >>>>> >>>>> The event is sent after the marking phase for all old collections >>>>> and an >>>>> object will be counted as live if the GC think that the object is live >>>>> (this is only tricky in the case of a concurrent collection). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Erik >>>> >>> >> > From jon.masamitsu at oracle.com Mon Mar 25 14:03:42 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 25 Mar 2013 07:03:42 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514D26D2.1030705@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> Message-ID: <5150593E.1080108@oracle.com> Thanks for the change. Looks good. Jon On 3/22/13 8:51 PM, Tao Mao wrote: > Thank you for review and suggestion. A new webrev is updated. > http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ > > Tao > > On 3/22/13 1:56 PM, Jon Masamitsu wrote: >> Tao, >> >> Changes look fine. I would remove the "likely" so that messages read >> like >> >> "and will be removed in a future release" >> >> Fewer words are better and the intent is still clear. >> >> Jon >> >> >> On 3/21/2013 4:23 PM, Tao Mao wrote: >>> A simple changeset. Need a reviewer! >>> >>> 8010518 Move deprecating CMSIncrementalMode from >>> Arguments::check_deprecated_gcs() to >>> Arguments::check_deprecated_gc_flags() >>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>> >>> webrev: >>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>> >>> changeset: >>> Cleanup suggested by Bengt. >> From erik.helin at oracle.com Mon Mar 25 14:12:56 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 25 Mar 2013 15:12:56 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <515058D1.7010705@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> <515034C6.1040202@oracle.com> <515035FB.4020101@oracle.com> <51505580.5040302@oracle.com> <515058D1.7010705@oracle.com> Message-ID: <51505B68.5020201@oracle.com> Hi Mikael, thanks for reviewing! On 03/25/2013 03:01 PM, Mikael Gerdin wrote: > Erik, > > On 2013-03-25 14:47, Erik Helin wrote: >> All, >> >> I have updated the change based on feedback from Bengt and Jesper. >> >> The differences between webrev.01 and webrev.02 are: >> - Updated the comment in VM_GC_HeapInspection. >> - Updated the label for the object count event. >> >> New webrev located at: >> http://cr.openjdk.java.net/~ehelin/8008920/webrev.02/ > > In concurrentMarkSweepGeneration.cpp: > It would feel more appropriate to have the call to > report_object_count_after_gc to before we _collectorState to Sweeping. Ok, I will move the code. > The rest looks good to me. Thanks! Erik > /Mikael > >> >> Thanks, >> Erik >> >> On 03/25/2013 12:33 PM, Erik Helin wrote: >>> Bengt, >>> >>> On 03/25/2013 12:28 PM, Bengt Rutisson wrote: >>>> >>>> Hi Erik, >>>> >>>> This looks good. >>>> >>>> One small nit. In VM_GC_HeapInspection::collect() you preserved the >>>> comment from VM_GC_HeapInspection::doit(). The comment talks about >>>> issuing a warning message, but the code to log that message is left in >>>> doit(). Could we update the comment to be more consistent with the new >>>> code? >>> >>> I will update the comment. >>> >>> Thanks, >>> Erik >>> >>>> Thanks, >>>> Bengt >>>> >>>> On 3/22/13 9:55 AM, Erik Helin wrote: >>>>> All, >>>>> >>>>> based on internal feedback, this change has been updated. >>>>> >>>>> The event has been renamed to vm/gc/detailed/object_count_after_gc. >>>>> Furthermore, the part of the change that updated >>>>> heapInspection.cpp/hpp has been extracted to a separate change (also >>>>> out for review on hotspot-gc-dev at openjdk.java.net). >>>>> >>>>> New webrev located at: >>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> On 03/16/2013 11:38 AM, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this change adds an event, vm/gc/detailed/class_count_after_gc, that >>>>>> sends information about the number of instances of each class on the >>>>>> heap (as well as size and the name of the class). >>>>>> >>>>>> The event is sent after the marking phase for all old collections >>>>>> and an >>>>>> object will be counted as live if the GC think that the object is >>>>>> live >>>>>> (this is only tricky in the case of a concurrent collection). >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >>>>>> >>>>>> Testing: >>>>>> JPRT >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>> >>>> >>> >> From stefan.karlsson at oracle.com Mon Mar 25 15:10:53 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 25 Mar 2013 15:10:53 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 46 new changesets Message-ID: <20130325151224.9C423483AC@hg.openjdk.java.net> Changeset: 39432a1cefdd Author: minqi Date: 2013-03-14 00:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/39432a1cefdd 8003348: SA can not read core file on OS Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin. Reviewed-by: sla, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/libproc.h ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_core.c ! agent/src/os/bsd/symtab.c ! agent/src/os/bsd/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! agent/src/share/native/sadis.c ! make/bsd/makefiles/saproc.make Changeset: 1fc4d4768b90 Author: coleenp Date: 2013-03-15 17:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1fc4d4768b90 8007725: NPG: Klass::restore_unshareable_info() triggers assert(k->java_mirror() == NULL) Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up. Reviewed-by: coleenp, acorn, hseigel, minqi Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp Changeset: 82f49e8e2c28 Author: zgu Date: 2013-03-15 11:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/82f49e8e2c28 8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Summary: Align up vm allocation size to os defined granularity Reviewed-by: dholmes, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: 919a5f9f36a9 Author: zgu Date: 2013-03-15 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/919a5f9f36a9 Merge Changeset: 82ab039b9680 Author: dcubed Date: 2013-03-17 08:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/82ab039b9680 Merge ! src/share/vm/memory/metaspace.cpp Changeset: 117bb0519114 Author: sla Date: 2013-03-19 13:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/117bb0519114 8009456: SA: typeToVtbl of BasicTypeDataBase should not be static Reviewed-by: coleenp, sla Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java Changeset: 686916dc0439 Author: sla Date: 2013-03-19 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/686916dc0439 8009457: SA: A small fix on "scanoops" command in CLHSDB Reviewed-by: sla, coleenp, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java Changeset: 47902e9acb3a Author: stefank Date: 2013-03-22 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/47902e9acb3a Merge ! src/share/vm/memory/metaspace.cpp Changeset: 9960dce2024f Author: kmo Date: 2013-03-14 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9960dce2024f 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Summary: add cases for _MSC_VER == 1600 and 1700 Reviewed-by: zgu ! src/share/vm/runtime/vm_version.cpp Changeset: a40807924950 Author: kmo Date: 2013-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a40807924950 Merge Changeset: f3d486462d36 Author: morris Date: 2013-03-15 18:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f3d486462d36 Merge Changeset: 96ef09c26978 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/96ef09c26978 8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp Summary: add guarantee() to as_instance_type() Reviewed-by: kvn, twisti ! src/share/vm/opto/type.cpp Changeset: 8b4ce9870fd6 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8b4ce9870fd6 8009156: [parfait] Null pointer deference in hotspot/src/share/vm/services/memoryService.cpp Summary: add guarantee() to add_generation_memory_pool() Reviewed-by: kvn, twisti ! src/share/vm/services/memoryService.cpp Changeset: 0a2deac0bbfb Author: morris Date: 2013-03-16 07:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0a2deac0bbfb 8008328: [partfait] Null pointer defererence in hotspot/src/cpu/x86/vm/frame_x86.inline.hpp Summary: add guarantee() to oop_result inlines Reviewed-by: kvn, twisti ! src/cpu/x86/vm/frame_x86.inline.hpp Changeset: 9ef47379df20 Author: morris Date: 2013-03-16 07:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9ef47379df20 8010144: [parfait] Null pointer deference in hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Summary: add null check to signal handler Reviewed-by: dcubed ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 8552f0992748 Author: kmo Date: 2013-03-15 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8552f0992748 8008796: SA: Oop.iterateFields() should support CompressedKlassPointers again Summary: add a missing change from JDK-7054512 so that Oop.iterateFields() works with UseCompressedKlassPointers Reviewed-by: coleenp, roland Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java Changeset: 592f9722c72e Author: kmo Date: 2013-03-16 21:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/592f9722c72e Merge Changeset: 4efac99a998b Author: iignatyev Date: 2013-03-18 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4efac99a998b 8008211: Some of WB tests on compiler fail Reviewed-by: kvn, vlivanov ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: a5de0cc2f91c Author: roland Date: 2013-03-18 13:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a5de0cc2f91c 8008555: Debugging code in compiled method sometimes leaks memory Summary: support for strings that have same life-time as code that uses them. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: 578d9044c463 Author: roland Date: 2013-03-18 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/578d9044c463 Merge Changeset: be4d5c6c1f79 Author: neliasso Date: 2013-03-19 10:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/be4d5c6c1f79 8010121: Remove definition of ShouldNotReachHere2(msg) Reviewed-by: kvn, stefank, rbackman, twisti Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: f15df3af32c5 Author: morris Date: 2013-03-19 07:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f15df3af32c5 8009172: [parfait] Null pointer deference in hotspot/src/share/vm/opto/output.cpp Summary: add guarantee() to DoScheduling() Reviewed-by: twisti, kvn ! src/share/vm/opto/output.cpp Changeset: 75a28f465a12 Author: morris Date: 2013-03-19 07:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/75a28f465a12 8008663: [parfait] Null pointer deference in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: add NULL checks for compiler name Reviewed-by: twisti, kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp Changeset: 80208f353616 Author: kvn Date: 2013-03-19 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/80208f353616 8010222: 8007439 disabled inlining of cold accessor methods Summary: added missing parenthesis Reviewed-by: jrose ! src/share/vm/opto/bytecodeInfo.cpp Changeset: 2eef6d34833b Author: morris Date: 2013-03-19 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2eef6d34833b 8009022: [parfait] Null pointer deference in hotspot/src/share/vm/oops/generateOopMap.cpp Summary: add guarantee() checks to merge_state_into_bb() Reviewed-by: kvn ! src/share/vm/oops/generateOopMap.cpp Changeset: 3b9368710f08 Author: morris Date: 2013-03-19 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3b9368710f08 8008811: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopopts.cpp Summary: add guarantee() checks Reviewed-by: kvn ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 1275835a4ccc Author: morris Date: 2013-03-19 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1275835a4ccc Merge Changeset: 41340544e182 Author: morris Date: 2013-03-20 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/41340544e182 8009248: [parfait] Null pointer deference in hotspot/src/share/vm/code/compiledIC.cpp Summary: add guarantee() to set_to_interpreted() Reviewed-by: kvn ! src/share/vm/code/compiledIC.cpp Changeset: 2dec1d9bfbe1 Author: morris Date: 2013-03-20 06:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2dec1d9bfbe1 8009565: [partfait] Null pointer deference in hotspot/src/share/vm/ci/ciEnv.cpp Summary: add guarantee() to get_instance_klass_for_declared_method_holder() Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp Changeset: 653d0346aa80 Author: morris Date: 2013-03-20 06:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/653d0346aa80 8009578: [parfait] Null pointer deference in hotspot/src/share/vm/classfile/defaultMethods.cpp Summary: add guarantee() to disqualify_method() Reviewed-by: kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: a59625d96f71 Author: morris Date: 2013-03-20 07:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a59625d96f71 8009181: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopTransform.cpp Summary: add guarantee() to insert_pre_post_loops() Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 98f3af397705 Author: twisti Date: 2013-03-20 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/98f3af397705 8006965: remove test_gamma and add dedicated test_* targets instead Reviewed-by: kvn, jcoomes ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make - make/test/Queens.java Changeset: 589aa23334ea Author: morris Date: 2013-03-21 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/589aa23334ea 8009584: [parfait] Null pointer deference in hotspot/src/cpu/x86/vm/relocInfo_x86.cpp Summary: added guarantee() to pd_address_in_code() Reviewed-by: kvn ! src/cpu/x86/vm/relocInfo_x86.cpp Changeset: c3c64a973559 Author: morris Date: 2013-03-21 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3c64a973559 8009593: [parfait] Null pointer deference in hotspot/src/share/vm/oops/constantPool.cpp Summary: added guarantee() to print_entry_on() Reviewed-by: kvn ! src/share/vm/oops/constantPool.cpp Changeset: 3536ea6bc4df Author: morris Date: 2013-03-21 21:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3536ea6bc4df Merge - make/test/Queens.java Changeset: 5855e849c7e6 Author: stefank Date: 2013-03-22 12:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5855e849c7e6 Merge Changeset: 499ccc15bbc8 Author: bpittore Date: 2013-03-15 15:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/499ccc15bbc8 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/runtime/thread.cpp Changeset: 9e62e72c59cc Author: bobv Date: 2013-03-17 06:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9e62e72c59cc Merge Changeset: 3be6a41ad358 Author: dholmes Date: 2013-03-18 19:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3be6a41ad358 8008783: Modifications needed to JPRT to allow for building hard float abi and new bundle changes Reviewed-by: twisti, collins, bobv, jwilhelm ! make/jprt.properties Changeset: 804663118c1f Author: jprovino Date: 2013-03-22 10:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/804663118c1f Merge Changeset: aca25026e2a4 Author: vladidan Date: 2013-03-22 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aca25026e2a4 Merge Changeset: 4f7380dca47e Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4f7380dca47e Added tag jdk8-b82 for changeset 3db4ab0e12f4 ! .hgtags Changeset: e3a41fc02348 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e3a41fc02348 Merge - make/test/Queens.java Changeset: 1c8db54ee9f3 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1c8db54ee9f3 Added tag hs25-b24 for changeset e3a41fc02348 ! .hgtags Changeset: 59a41e1357ab Author: amurillo Date: 2013-03-23 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/59a41e1357ab 8010498: new hotspot build - hs25-b25 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 338b3a9e29b5 Author: stefank Date: 2013-03-25 11:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/338b3a9e29b5 Merge ! src/share/vm/services/memoryService.cpp From john.cuthbertson at oracle.com Mon Mar 25 17:13:26 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 25 Mar 2013 10:13:26 -0700 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure In-Reply-To: <514DB2BF.8070602@oracle.com> References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com> <514C9C40.8070102@oracle.com> <514DB2BF.8070602@oracle.com> Message-ID: <515085B6.8040501@oracle.com> Hi Leonid, Generally I believe you need two reviewers with at least one "official" Reviewer (someone who has Reviewer status for the project you are pushing into) but it is OK to push a change with just one review from a Reviewer. It would be better to get another set of eyes - someone from the SQE team would be ideal (since this is a regression test), if you can. I would wait one more day and, if no one else reviews the test, you can go and push. JohnC On 3/23/2013 6:48 AM, Leonid Mesnik wrote: > John > > Thank you for review. Is it enough to push fix or I need another one? > > Leonid > On 03/22/2013 10:00 PM, John Cuthbertson wrote: >> Hi Leonid, >> >> This looks OK to me. >> >> JohnC >> >> On 3/22/2013 12:06 AM, Leonid Mesnik wrote: >>> Could anyone please review this small test fix. >>> >>> Leonid >>> On 03/20/2013 04:16 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review fix for 8009808 TEST-BUG : test case is >>>> using bash style tests. Default shell for jtreg is bourne. thus >>>> failure. >>>> >>>> I've completely rewritten test in java without major changes it >>>> test logic. >>>> I remove CMS so test could be run when CMS is not supported. Also I >>>> changed max memory to 128M to reduce memory load and increase >>>> number of GC log entries. >>>> >>>> Here is the link: >>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ >>>> >>>> >>> >>> >> > > From thomas.schatzl at oracle.com Mon Mar 25 17:28:25 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 25 Mar 2013 18:28:25 +0100 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <514CCC0C.4030403@oracle.com> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> <1363593549.2603.1.camel@cirrus> <514B8CC7.7060607@oracle.com> <1363934518.2463.48.camel@cirrus> <514CCC0C.4030403@oracle.com> Message-ID: <1364232505.2703.47.camel@cirrus> Hi Jon, On Fri, 2013-03-22 at 14:24 -0700, Jon Masamitsu wrote: > Thomas, > > Thanks for the extra effort. A comment not about correctness > but more for readability. > > > + if (is_allocatable(upper_limit)) { > > + *limit = upper_limit; > > + } else if (upper_limit < min_allocation_size) { > > + *limit = upper_limit; > > + } else if (!is_allocatable(min_allocation_size)) { > > + // we found that not even min_allocation_size is allocatable. Return it > > + // anyway. There is no point to search for a better value any more. > > + *limit = min_allocation_size; > > In the first "else if" if you changed it to (upper_limit <= > min_allocation_size) > can you eliminate the second "else if" like this > > + if (is_allocatable(upper_limit)) { > + *limit = upper_limit; > + } else if (upper_limit <= min_allocation_size) { > + *limit = upper_limit; > > And it might read more easily as > > + if (is_allocatable(upper_limit) || > +upper_limit <= min_allocation_size) { > + *limit = upper_limit; a new webrev with your suggested change is available at http://cr.openjdk.java.net/~tschatzl/7112912/webrev.2/ Again, the change passed jprt. Hth, Thomas From jon.masamitsu at oracle.com Mon Mar 25 18:20:25 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 25 Mar 2013 11:20:25 -0700 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <1364203467.2703.41.camel@cirrus> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> <1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus> Message-ID: <51509569.1020604@oracle.com> On 3/25/13 2:24 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2013-03-22 at 15:23 -0700, Jon Masamitsu wrote: >> This comment is only correct if InitialHeapSize is not set on the >> command line or at least that's my understanding. >> >> 2355 // Currently the minimum size and the initial heap sizes are the same. >> >> Until InitialHeapSize was introduced, the initial heap size was the >> minimum heap size. > The implementation unconditionally sets both minimum and initial heap > size to the given value. The change only adds this comment (for > clarification that this has been an intentional decision). After this change (adding InitialHeapSize) 2342 } else if (match_option(option, "-Xms", &tail) || match_option(option, "-XX:InitialHeapSize=", &tail)) { will there be a change in behavior when InitialHeapSize is set on the command line? Seems to me With change, InitialHeapSize becomes the minimum heap size. > > I looked a little more into how -Xms is documented, and I actually found > conflicting information: > > java -X output: > -Xms "set initial Java heap size" So the above matches the current behavior, yes? > > Oracle documentation: > > "-Xms is minimum heap size (only)" > > http://docs.oracle.com/cd/E15523_01/web.1111/e13814/jvm_tuning.htm The above is for jdk 5. > http://docs.oracle.com/cd/E19528-01/819-4742/abeik/index.html Don't know about this one above. > http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#generation_sizing Jdk 6 tuning guide so doesn't have the InitialHeapSize flag (I believe). > http://docs.oracle.com/cd/E19528-01/819-4742/abeik/index.html Don't know about this one above. > > and > > InitialHeapSize documentation: > > "Initial heap size (in bytes); zero means OldSize + NewSize" > > Other documentation gathered from searching the web, paraphrasing: > > "Minimum heap size cannot be set, only initial heap size.", and the > general recommendation to set -Xms to -Xmx. Don't recognize the above recommendation. Hope I didn't make it. > > > Since the documentation for both -Xms and InitialHeapSize match, this > change modifies the code so that they use the same implementation. > Assuming that the in-product documentation is the most current/valid > one; I did not consider searching specifically for oracle documentation > at that time. > >> Sometime during jdk7 development the default heap size for the >> client VM was changed to use the same (or at least similar ergonomics >> heap sizing as with the server VM) with the exception of windows >> (maybe, not sure about the windows exception). > I cannot find a Windows exception, but maybe I overlooked that. I will > have another look. There has in the past been an exception for windows that regardless of the memory size and number of cpus, windows machines were never "server class machines". I would have thought that this same exception would have been made for sizing the heap using the GC ergonomics. That was only for 32 bit windows. > >> The minimum heap size was not changed as far as I know. Part of >> the ergonomics heap sizing is that the initial heap size is calculated >> and is not the minimum heap size. The motivation for the initial heap >> size change was faster start up (didn't have to go through GC's to get >> a bigger heap). The motivation for the client VM using the ergonomics >> heap sizing was easy of use. With the minimum heap size staying the >> same, if the application did not need a heap that was as large as the >> initial heap size, the heap sizing would shrink the heap back down. >> That way any footprint increase would be transitory at start up >> and the heap size would evolve to what it had been before (was the hope). >> >> The actual flag InitialHeapSize was introduced to give the user some >> control over the InitialHeapSize if such control was really needed but >> I don't think it was supposed to affect the minimum heap size. > I understand the motivation of having a separate control to set the > minimum and initial heap size. > > However the implementation and the documentation of these switches > contradict to some degree. > > What is the expected behavior? My expectation is that InitialHeapSize sets a value that is different from the minimum heap size. That the minimum heap size be the same as in jdk6. That with jdk7 an initial heap size can be set or ergonomically calculated such that it is larger than the minimum. That sizing policy in the collectors shrink the size of the heap to its jdk6 minimum if the larger initial heap size is not needed. > > One suggestion: > > -Xms sets only minimum heap size (and automatically adjust > InitialHeapSize if not set manually; verify otherwise). Also change the > documentation string. Automatically adjust InitialHeapSize how? > > -XX:InitialHeapSize sets only initial heap size; if set on command > line, check validity against minimum heap size at some point. Otherwise > adapt to detected minimum heap size setting. If -Xms is not set, set > minimum heap size to the same value. The jdk6 minimum heap size (no flags on the command line) was about 4m. If the is not using its heap (releases lots of space and does a System.gc() for example), I think the size of the heap should shrink back down to something approaching this size. > > > > The current behavior, that -Xms sets both initial and minimum heap size > is very unsatisfying and not easily discoverable (which was the cause > for this CR). The order of switches would be important, in addition to > -Xms doing something unexpected. Additionally the initial/minimum heap > sizes are not synchronized, so a user also sometimes gets strange error > messages. > > The documentation for -Xms via java -X also contradicts (or at least > omits important information) both external documentation and actual > behavior. Since -Xms is a -X flag (e.g., is implemented by other JVM's) I've assumed that we are stuck with supporting the behavior as described. If it's not specified, we have some flexibility. Jon > > What do you think? > > Thanks for looking at that, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Mon Mar 25 18:48:55 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 25 Mar 2013 11:48:55 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <514F5F16.9080909@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> Message-ID: <51509C17.6080808@oracle.com> Thank you for pointing it out, Bengt. A new webrev is updated. http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ Please see inline. Tao On 3/24/13 1:16 PM, Bengt Rutisson wrote: > > Hi Tao, > > On 3/23/13 4:51 AM, Tao Mao wrote: >> Thank you for review and suggestion. A new webrev is updated. >> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ > > I like Jon's suggestion about removing the word "likely" but that > means that you need to update these tests: > > test/gc/startup_warnings/TestCMSIncrementalMode.java > test/gc/startup_warnings/TestIncGC.java Test files modified. > > Also, would it make sense to remove the word "likely" from the warning > messages in Arguments::check_deprecated_gcs() too? In that case you > need to update these tests as well: > > test/gc/startup_warnings/TestDefNewCMS.java > test/gc/startup_warnings/TestParNewSerialOld.java Have we made a decision to certainly remove these gc comb's in future? If so, it's OK to state so. Anyway, it would be better to resolve it with a separate CR. > > Bengt > >> >> Tao >> >> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>> Tao, >>> >>> Changes look fine. I would remove the "likely" so that messages >>> read like >>> >>> "and will be removed in a future release" >>> >>> Fewer words are better and the intent is still clear. >>> >>> Jon >>> >>> >>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>> A simple changeset. Need a reviewer! >>>> >>>> 8010518 Move deprecating CMSIncrementalMode from >>>> Arguments::check_deprecated_gcs() to >>>> Arguments::check_deprecated_gc_flags() >>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>> >>>> changeset: >>>> Cleanup suggested by Bengt. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Mon Mar 25 19:12:59 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 20:12:59 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <51504E40.7050808@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> <51502DBE.3040704@oracle.com> <5150352D.6090407@oracle.com> <51504E40.7050808@oracle.com> Message-ID: <5150A1BB.9000209@oracle.com> Looks good, Ship it! /Jesper Erik Helin skrev 25/3/13 2:16 PM: > All, > > I have updated the change based on feedback from Bengt and Jesper. > > Differences between webrev.01 and webrev.02: > - Added #else clause in HeapInspection::start_of_perm_gen to make sure > that no compilers will isse any warnings. > - Removed the variable need_epilogue in > HeapInspection::instance_inspection, just kept the comment. > - Updated the @bug annotation of the test to the correct bug number, > 8010294. > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8010294/webrev.02/ > > Thanks, > Erik > > On 03/25/2013 12:29 PM, Erik Helin wrote: >> Bengt, >> >> On 03/25/2013 11:58 AM, Bengt Rutisson wrote: >>> >>> Hi Erik, >>> >>> Changes look good! >>> >>> One minor nit. I think the test contains the wrong bug number: >>> >>> * @bug 8004924 >> >> Agree, I will fix. >> >> Thanks, >> Erik >> >>> Bengt >>> >>> On 3/25/13 9:32 AM, Erik Helin wrote: >>>> All, >>>> >>>> I have updated the change based on internal feedback. >>>> >>>> The changes between webrev.00 and webrev.01 are mostly in the test code: >>>> - The test uses correct @summary description >>>> - The test now uses the correct command line flags >>>> - The test is more documented to describe how the test code is run >>>> >>>> There is also a very minor change in the hotspot code. I am now using >>>> the operator != instead of operator > when comparing the missed count. >>>> This was done just to make the diff one line smaller :) >>>> >>>> Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/22/2013 10:06 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> I have refactored the HeapInspection class to prepare for the >>>>> vm/gc/detailed/object_count_after_gc event. >>>>> >>>>> The refactoring mainly consists of breaking up the rather long >>>>> heap_inspect function to multiple small functions that can be reused. >>>>> >>>>> I also moved the public enums used to initialize KlassInfoTable and >>>>> KlassInfoHisto to private constants. Now they no longer have to be >>>>> passed as an argument to the constructor. >>>>> >>>>> I also added a test to ensure that my refactoring did not break >>>>> anything >>>>> (the test is not that extensive but at least it ensures that the basic >>>>> stuff is working). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >>>>> >>>>> Testing: >>>>> - JPRT >>>>> - A new jtreg test (see webrev) >>>>> >>>>> Thanks, >>>>> Erik >>>> >>> >>> >> > From jesper.wilhelmsson at oracle.com Mon Mar 25 19:27:30 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Mar 2013 20:27:30 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <51505B68.5020201@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> <515034C6.1040202@oracle.com> <515035FB.4020101@oracle.com> <51505580.5040302@oracle.com> <515058D1.7010705@oracle.com> <51505B68.5020201@oracle.com> Message-ID: <5150A522.3010301@oracle.com> Looks good, Ship it! /Jesper Erik Helin skrev 25/3/13 3:12 PM: > Hi Mikael, > > thanks for reviewing! > > On 03/25/2013 03:01 PM, Mikael Gerdin wrote: >> Erik, >> >> On 2013-03-25 14:47, Erik Helin wrote: >>> All, >>> >>> I have updated the change based on feedback from Bengt and Jesper. >>> >>> The differences between webrev.01 and webrev.02 are: >>> - Updated the comment in VM_GC_HeapInspection. >>> - Updated the label for the object count event. >>> >>> New webrev located at: >>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.02/ >> >> In concurrentMarkSweepGeneration.cpp: >> It would feel more appropriate to have the call to >> report_object_count_after_gc to before we _collectorState to Sweeping. > > Ok, I will move the code. > >> The rest looks good to me. > > Thanks! > > Erik > >> /Mikael >> >>> >>> Thanks, >>> Erik >>> >>> On 03/25/2013 12:33 PM, Erik Helin wrote: >>>> Bengt, >>>> >>>> On 03/25/2013 12:28 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> This looks good. >>>>> >>>>> One small nit. In VM_GC_HeapInspection::collect() you preserved the >>>>> comment from VM_GC_HeapInspection::doit(). The comment talks about >>>>> issuing a warning message, but the code to log that message is left in >>>>> doit(). Could we update the comment to be more consistent with the new >>>>> code? >>>> >>>> I will update the comment. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> On 3/22/13 9:55 AM, Erik Helin wrote: >>>>>> All, >>>>>> >>>>>> based on internal feedback, this change has been updated. >>>>>> >>>>>> The event has been renamed to vm/gc/detailed/object_count_after_gc. >>>>>> Furthermore, the part of the change that updated >>>>>> heapInspection.cpp/hpp has been extracted to a separate change (also >>>>>> out for review on hotspot-gc-dev at openjdk.java.net). >>>>>> >>>>>> New webrev located at: >>>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>> On 03/16/2013 11:38 AM, Erik Helin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> this change adds an event, vm/gc/detailed/class_count_after_gc, that >>>>>>> sends information about the number of instances of each class on the >>>>>>> heap (as well as size and the name of the class). >>>>>>> >>>>>>> The event is sent after the marking phase for all old collections >>>>>>> and an >>>>>>> object will be counted as live if the GC think that the object is >>>>>>> live >>>>>>> (this is only tricky in the case of a concurrent collection). >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >>>>>>> >>>>>>> Testing: >>>>>>> JPRT >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>> >>>>> >>>> >>> > From bengt.rutisson at oracle.com Mon Mar 25 19:41:56 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Mar 2013 20:41:56 +0100 Subject: RFR(S): 8007701: Hotspot trace Allocation Events In-Reply-To: <51505281.5060302@oracle.com> References: <51423640.4000506@oracle.com> <5149D4BF.8000704@oracle.com> <514C2069.2070008@oracle.com> <514C542C.3090200@oracle.com> <51505281.5060302@oracle.com> Message-ID: <5150A884.3000300@oracle.com> Hi Nils, On 3/25/13 2:34 PM, Nils Eliasson wrote: > Hi Bengt, > > Well, collectedHeap already includes all kinds of gc-stuff - > "gc_implementation/shared/gcTrace.hpp" for example. Not sure I understand this comment, but that's ok. > > Anyway - I moved them out. Had to have both a cpp and a hpp file since > collectedHeap can't include trace/tracing.hpp which the events require. Thanks, I like this much better. One thought. If you make the send methods instance methods instead of static methods on the class you could stack allocate an AllocTracer in the top level functions and pass a reference to that instance to the sub methods instead of passing the klass. The AllocTracer would have to keep track of the klass. This would not reduce the number of parameters you need to pass around, but it kind of explains the purpose of why you need to pass it a bit. What do you think? > > C1-Allocations is covered when using the flag -XX:-FastTLABRefill > (will be documented). And when running with G1 it is already default > off (because of the barriers that is required). FastTLABRefill could > probably be retired when proper regression anlysis has been done. > Wouldn't miss the pages of platform dependent code. OK. Sounds like a good plan. Is there an RFE filed to retire FastTLABRefill? Thanks, Bengt > > > New rev: > http://cr.openjdk.java.net/~neliasso/8007701/webrev.07/ > > //Nils Eliasson > > > > > > On 2013-03-22 13:53, Bengt Rutisson wrote: >> >> Hi Nils, >> >> Overall this looks good, but I have two questions. >> >> Could we add a new class (maybe called AllocTracer?) instead of >> adding the two static send methods to GCTracer? It feels a bit wrong >> to have the GCTracer handle things that don't happen during a GC. >> >> How do we handle the fact that this does not cover the C1 tlab >> allocations? Is there a bug to track that? >> >> Thanks, >> Bengt >> >> On 3/22/13 10:12 AM, Nils Eliasson wrote: >>> Latest webrev after more feedback: >>> >>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.06/ >>> >>> //N >>> >>> >>> On 2013-03-20 16:24, Nils Eliasson wrote: >>>> Thanks for your review Erik, >>>> >>>> Updated the webrev with your suggestions >>>> - Moved alloction events to GCTrace >>>> - Renamed class event field to "class" >>>> >>>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/ >>>> http://bugs.sun.com/view_bug.do?bug_id=8007701 >>>> >>>> //Nils Eliasson >>>> >>>> >>>> On 2013-03-14 21:42, Nils Eliasson wrote: >>>>> Hi all, >>>>> >>>>> I would like a review for this change that introduces two new >>>>> tracing events. >>>>> >>>>> "AllocationInNewTLAB" is sent for the first object in a new TLAB >>>>> and gives a reasonably cheap and reasonably fair object sampling. >>>>> "AllocationOutsideTLAB" is sent for each object that gets >>>>> allocated outside the TLABs. (The object doesn't fit or would >>>>> cause too much wasted free space if the tlab was discarded.) >>>>> >>>>> These events use the allocation slow path in CollectedHeap which >>>>> is used by default in the template interpreter and the C2 >>>>> compiler. It is also used for all TLAB refills in the C1-compiler >>>>> if the flag -XX:-FastTLABRefill is supplied. >>>>> >>>>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/ >>>>> http://bugs.sun.com/view_bug.do?bug_id=8007701 >>>>> >>>>> The event code for AllocationOutsideTLAB had to be put in >>>>> CollectedHeap.cpp since tracing.hpp can't be included into >>>>> CollectedHeap.inline.hpp. >>>>> >>>>> Thanks, >>>>> Nils Eliasson >>>> >>> >> > From yumin.qi at oracle.com Mon Mar 25 22:32:08 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 15:32:08 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <514A29BC.7040105@oracle.com> References: <514A29BC.7040105@oracle.com> Message-ID: <5150D068.7020803@oracle.com> Hi, New webrev to use "-XX:+AssumMP" flag. Also add warning to recommend use this flag with "-XX:ParallelGCThreads" to remind user to avoid running with only one GC thread. This is verified by Oleksandr with the test case running on Linux which is not Zone configured. Same link. Thanks Yumin On 3/20/2013 2:27 PM, Yumin Qi wrote: > > 2178143: VM crashes if the number of bound CPUs changed during runtime. > > Situation: Customer first configure only one CPU online and turn > others offline to run java application, after java program started, > bring more CPUs back online. Since VM started on a single CPU, > os::is_MP() will return false, but after more CPUs available, OS will > schedule the app run on multiple CPUs, this caused SEGV in various > places where data consistency was broken. The solution is supply a > flag to assume it is running on MP, so lock is forced to be called. > > http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin From john.cuthbertson at oracle.com Mon Mar 25 23:04:07 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 25 Mar 2013 16:04:07 -0700 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <514FF8AF.5010806@oracle.com> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> <514CA0C3.3080306@oracle.com> <514FF8AF.5010806@oracle.com> Message-ID: <5150D7E7.10108@oracle.com> Hi Bengt, Thanks for looking again. A question inline... On 3/25/2013 12:11 AM, Bengt Rutisson wrote: > >> >>> >>> About the test. Great that you write a regression test for this! :) >>> >>> The @summary says that the test uses -XX:+VerifyDuringGC but the >>> command line is actually using -XX:+VerifyBeforeGC (which is >>> correct, I think). Also, would it make sense to have a separate test >>> that specifies -XX:+UseG1GC and checks the output that we expect to see? >> >> Yeah. Good catch. It should be with VerifyBeforeGC. Must have had >> marking on the brain. >> >> As for the test. I think we can check the output for "VerifyBefore" >> for all the collectors. I'll change the test. > > Great! I may have spoken too soon. Using ProcessBuilder, is there any way to pass the GC flags to the spawned java process? The spawned process is not being passed any additional flags that are passed to jtreg. For example: > /home/jcuthber/jtreg/jtreg/solaris/bin/jtreg \ > -jdk:/java/re/jdk/8/latest/binaries/solaris-i586/fastdebug \ > -vmoption:-XX:+UseG1GC \ > gc/TestVerifyBeforeGCDuringStartup.java does not pass -XX:+UseG1GC to the java process spawned by the test: > /* @test TestVerifyBeforeGCDuringStartup.java > * @key gc > * @bug 8010463 > * @summary Simple test run with -XX:+VerifyBeforeGC -XX:-UseTLAB to > verify 8010463 > * @library /testlibrary > */ > > import com.oracle.java.testlibrary.OutputAnalyzer; > import com.oracle.java.testlibrary.ProcessTools; > > public class TestVerifyBeforeGCDuringStartup { > public static void main(String args[]) throws Exception { > ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder("-XX:+UseG1GC", > "-XX:-UseTLAB", > "-XX:+UnlockDiagnosticVMOptions", > "-XX:+VerifyBeforeGC", > "-version"); > OutputAnalyzer output = new OutputAnalyzer(pb.start()); > output.shouldContain("[Verifying"); > output.shouldHaveExitValue(0); > } > } If I don't specify G1 in the argument list to ProcessBuilder, the test does not fail. >> 2. Use (VerifyBeforeGC && VerifyGCStartAt == 0) > > Right. I would prefer 1. but I'm fine with 2. Maybe 2. is more > reasonable change to do for this fix. Perhaps 1. should be its own change. I went with 2. I'll submit a new CR to use a new flag (and use a VMOperation). Thanks, JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd-2013 at eckenfels.net Mon Mar 25 23:07:02 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Tue, 26 Mar 2013 00:07:02 +0100 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5150D068.7020803@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> Message-ID: Hello, if I read this correctly, it will allow me to overwrite the asumption that the VM is started on multicore. But it will not avoid the crash if the flag is not set. Wouldnt it be safer to do something like this: if initial number of cores < 2 then start in "no parallel" mode which will block using parallel features unless you set "+AsumeMP"? Because otherwise you will still see random crashes and can only use the flag after the fact to avoid them. (if I understood the code correct). Gruss Bernd From john.cuthbertson at oracle.com Mon Mar 25 23:07:48 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 25 Mar 2013 16:07:48 -0700 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <1364200609.2703.3.camel@cirrus> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> <1363947317.2689.27.camel@cirrus> <514CAABF.9010501@oracle.com> <1364200609.2703.3.camel@cirrus> Message-ID: <5150D8C4.1060003@oracle.com> Hi Thomas, Thanks for the review. As I've mentioned earlier I have went with just changing the check. I will submit a new CR to add a new flag and perform the verification using a VMOperation. Cheers, JohnC On 3/25/2013 1:36 AM, Thomas Schatzl wrote: > Hi, > > On Fri, 2013-03-22 at 12:02 -0700, John Cuthbertson wrote: >> Hi Thomas, >> >> Thanks for looking over the changes. Replies inline.... >> >>> Allowing a NULL VMThread would allow checking heap consistency right >>> after Universe::genesis(). It is probably not expected that there are >>> already issues about the heap at this stage, but since we're already >>> verifying, I'd tend to prefer the option that verifies as much as >>> possible. >>> (Did not really check if it would really make a difference) >> [ long explanation that doing so is not that easy... ] >> >> Following this approach is not worth it. If we want to do then we will >> need to do it in a VMOperation as a separate changeset. > I agree. Thanks for clarification. > >>> seems unnecessary. We should either check VerifyGCStartAt == 0 or not >>> I would not mind either way; but you still need the VerifyBeforeGC (or >>> another flag) because otherwise the verification would practically be >>> unconditional as the default value of VerifyGCStartAt is zero. >> In my response to Bengt - I said I think we have a few choices: >> >> * Add a new flag to verify the heap during VM startup. >> * Rename and extend the existing VerifyOnExit(??) flag to cover >> verifying during startup. >> >> * change the code to "VerifyBeforeGC && VerifyGCStartAt == 0" > This one is probably the most reasonable for this fix as Bengt > indicates. > > Thomas > From yumin.qi at oracle.com Mon Mar 25 23:15:12 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 16:15:12 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5150D068.7020803@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> Message-ID: <5150DA80.4090907@oracle.com> It should be "AssumeMP". /Yumin On 3/25/2013 3:32 PM, Yumin Qi wrote: > Hi, > > New webrev to use "-XX:+AssumMP" flag. Also add warning to recommend > use this flag with "-XX:ParallelGCThreads" to remind user to avoid > running with only one GC thread. This is verified by Oleksandr with > the test case running on Linux which is not Zone configured. > > Same link. > > Thanks > Yumin > > On 3/20/2013 2:27 PM, Yumin Qi wrote: >> >> 2178143: VM crashes if the number of bound CPUs changed during runtime. >> >> Situation: Customer first configure only one CPU online and turn >> others offline to run java application, after java program started, >> bring more CPUs back online. Since VM started on a single CPU, >> os::is_MP() will return false, but after more CPUs available, OS will >> schedule the app run on multiple CPUs, this caused SEGV in various >> places where data consistency was broken. The solution is supply a >> flag to assume it is running on MP, so lock is forced to be called. >> >> http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin > From john.cuthbertson at oracle.com Mon Mar 25 23:35:05 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 25 Mar 2013 16:35:05 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <51509C17.6080808@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> Message-ID: <5150DF29.4020403@oracle.com> Hi Tao, This looks good to me. JohnC On 3/25/2013 11:48 AM, Tao Mao wrote: > Thank you for pointing it out, Bengt. A new webrev is updated. > http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ > > Please see inline. > Tao > > On 3/24/13 1:16 PM, Bengt Rutisson wrote: >> >> Hi Tao, >> >> On 3/23/13 4:51 AM, Tao Mao wrote: >>> Thank you for review and suggestion. A new webrev is updated. >>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >> >> I like Jon's suggestion about removing the word "likely" but that >> means that you need to update these tests: >> >> test/gc/startup_warnings/TestCMSIncrementalMode.java >> test/gc/startup_warnings/TestIncGC.java > Test files modified. >> >> Also, would it make sense to remove the word "likely" from the >> warning messages in Arguments::check_deprecated_gcs() too? In that >> case you need to update these tests as well: >> >> test/gc/startup_warnings/TestDefNewCMS.java >> test/gc/startup_warnings/TestParNewSerialOld.java > Have we made a decision to certainly remove these gc comb's in future? > If so, it's OK to state so. Anyway, it would be better to resolve it > with a separate CR. >> >> Bengt >> >>> >>> Tao >>> >>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>> Tao, >>>> >>>> Changes look fine. I would remove the "likely" so that messages >>>> read like >>>> >>>> "and will be removed in a future release" >>>> >>>> Fewer words are better and the intent is still clear. >>>> >>>> Jon >>>> >>>> >>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>> A simple changeset. Need a reviewer! >>>>> >>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>> Arguments::check_deprecated_gcs() to >>>>> Arguments::check_deprecated_gc_flags() >>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>> >>>>> changeset: >>>>> Cleanup suggested by Bengt. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Mon Mar 25 23:42:20 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 25 Mar 2013 16:42:20 -0700 Subject: RFR: Adding evacuation failed tracing event In-Reply-To: <514A4A73.6080704@oracle.com> References: <514A4A73.6080704@oracle.com> Message-ID: <5150E0DC.3010902@oracle.com> Hi Jesper, The changes for 8008916 look good. JohnC On 3/20/2013 4:46 PM, Jesper Wilhelmsson wrote: > Hi, > > I'm looking for a couple of reviews for this change. > > The change is to add evacuation failed tracing events to G1. Since the > evacuation failed is very similar to a regular promotion failed in > other young GCs, these events share most of the code. > > I have split the change into two parts: > > > 1) JDK-8009992: Prepare tracing of promotion failed for integration of > evacuation failed > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8009992/webrev/ > > This part refactors the promotion failed code to use a generic copy > failed class which is used as the base for the promotion failed handling. > > > 2) JDK-8008916: G1: Evacuation failed tracing event > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/ > > This part adds the new event for G1 evacuation failed. > > > Thanks, > /Jesper From tao.mao at oracle.com Mon Mar 25 23:46:48 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 25 Mar 2013 16:46:48 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <5150DF29.4020403@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> <5150DF29.4020403@oracle.com> Message-ID: <5150E1E8.701@oracle.com> Thank you for reviewing, John. Tao On 3/25/13 4:35 PM, John Cuthbertson wrote: > Hi Tao, > > This looks good to me. > > JohnC > > On 3/25/2013 11:48 AM, Tao Mao wrote: >> Thank you for pointing it out, Bengt. A new webrev is updated. >> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ >> >> Please see inline. >> Tao >> >> On 3/24/13 1:16 PM, Bengt Rutisson wrote: >>> >>> Hi Tao, >>> >>> On 3/23/13 4:51 AM, Tao Mao wrote: >>>> Thank you for review and suggestion. A new webrev is updated. >>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >>> >>> I like Jon's suggestion about removing the word "likely" but that >>> means that you need to update these tests: >>> >>> test/gc/startup_warnings/TestCMSIncrementalMode.java >>> test/gc/startup_warnings/TestIncGC.java >> Test files modified. >>> >>> Also, would it make sense to remove the word "likely" from the >>> warning messages in Arguments::check_deprecated_gcs() too? In that >>> case you need to update these tests as well: >>> >>> test/gc/startup_warnings/TestDefNewCMS.java >>> test/gc/startup_warnings/TestParNewSerialOld.java >> Have we made a decision to certainly remove these gc comb's in >> future? If so, it's OK to state so. Anyway, it would be better to >> resolve it with a separate CR. >>> >>> Bengt >>> >>>> >>>> Tao >>>> >>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>>> Tao, >>>>> >>>>> Changes look fine. I would remove the "likely" so that messages >>>>> read like >>>>> >>>>> "and will be removed in a future release" >>>>> >>>>> Fewer words are better and the intent is still clear. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>>> A simple changeset. Need a reviewer! >>>>>> >>>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>>> Arguments::check_deprecated_gcs() to >>>>>> Arguments::check_deprecated_gc_flags() >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>>> >>>>>> changeset: >>>>>> Cleanup suggested by Bengt. >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.qi at oracle.com Tue Mar 26 00:35:40 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 17:35:40 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> Message-ID: <5150ED5C.6090400@oracle.com> Bernd, The flag AssumeMP default is false, this is the confusion part, seems like it is running on a single CPU, in fact not, it will not change anything --- just like no flag before. If it is set, we think it is running on MP no matter underlying if it is. If number of cores <2 and turns on this flag, at same time, ParallelGCThreads not set, it will be assigned the number of cores, the result will be only one GC thread created. After more cores available, the number of GC threads will be still 1 since it is not dynamically changed. This is what we don't want to see. If the flag not turned on, everything is same as it was. Thanks Yumin On 3/25/2013 4:07 PM, Bernd Eckenfels wrote: > Hello, > > if I read this correctly, it will allow me to overwrite the asumption > that the VM is started on multicore. But it will not avoid the crash > if the flag is not set. > > Wouldnt it be safer to do something like this: > > > if initial number of cores < 2 then start in "no parallel" mode which > will block using parallel features unless you set "+AsumeMP"? > > Because otherwise you will still see random crashes and can only use > the flag after the fact to avoid them. (if I understood the code > correct). > > Gruss > Bernd From david.holmes at oracle.com Tue Mar 26 00:44:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2013 10:44:33 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5150DA80.4090907@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> Message-ID: <5150EF71.8040507@oracle.com> Hi Yumin, I have a few suggested changes. First in os.hpp I suggest return _processor_count > 1 || AssumeMP ; That way we don't bypass the assertion and don't encounter unnecessary overhead on the common path. In arguments.cpp: + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { + warning("With AssumeMP, recommend run with -XX:ParallelGCThreads=, where" + " num_of_gc_threads can be set to number of cores"); + } I'm not convinced issuing a warning is necessary or desirable here. With a uniprocessor startup will we even default to using parallel GC? The above should only be issued if using parallel GC - so better to move it into set_parallel_gc_flags(). In any case it isn't clear what the user should supply here. If they use the maximum expected number of cores initially then while they only have 1 core their VM may not even function adequately due to GC overhead. I think all you can say here is something like: warning("If the number of processors is expected to increase from one, then you should configure the number of parallel GC threads appropriately using -XX:ParallelGCThreads=N"); In globals.hpp: + product(bool, AssumeMP, false, \ + "Assume run on multiple processors always") \ Was there any discussion on making this default to true instead? Suggested re-wording: "Instruct the VM to assume multiple processors are available" Thanks, David On 26/03/2013 9:15 AM, Yumin Qi wrote: > It should be "AssumeMP". > > /Yumin > > On 3/25/2013 3:32 PM, Yumin Qi wrote: >> Hi, >> >> New webrev to use "-XX:+AssumMP" flag. Also add warning to recommend >> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >> running with only one GC thread. This is verified by Oleksandr with >> the test case running on Linux which is not Zone configured. >> >> Same link. >> >> Thanks >> Yumin >> >> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>> >>> 2178143: VM crashes if the number of bound CPUs changed during runtime. >>> >>> Situation: Customer first configure only one CPU online and turn >>> others offline to run java application, after java program started, >>> bring more CPUs back online. Since VM started on a single CPU, >>> os::is_MP() will return false, but after more CPUs available, OS will >>> schedule the app run on multiple CPUs, this caused SEGV in various >>> places where data consistency was broken. The solution is supply a >>> flag to assume it is running on MP, so lock is forced to be called. >>> >>> http://cr.openjdk.java.net/~minqi/2178143/ >>> >>> Thanks >>> Yumin >> > From jon.masamitsu at oracle.com Tue Mar 26 01:57:44 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 25 Mar 2013 18:57:44 -0700 Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <1364232505.2703.47.camel@cirrus> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> <1363593549.2603.1.camel@cirrus> <514B8CC7.7060607@oracle.com> <1363934518.2463.48.camel@cirrus> <514CCC0C.4030403@oracle.com> <1364232505.2703.47.camel@cirrus> Message-ID: <51510098.1090804@oracle.com> Thomas, Thanks for the changes. Looks fine. Jon On 3/25/2013 10:28 AM, Thomas Schatzl wrote: > Hi Jon, > > On Fri, 2013-03-22 at 14:24 -0700, Jon Masamitsu wrote: >> Thomas, >> >> Thanks for the extra effort. A comment not about correctness >> but more for readability. >> >>> + if (is_allocatable(upper_limit)) { >>> + *limit = upper_limit; >>> + } else if (upper_limit < min_allocation_size) { >>> + *limit = upper_limit; >>> + } else if (!is_allocatable(min_allocation_size)) { >>> + // we found that not even min_allocation_size is allocatable. Return it >>> + // anyway. There is no point to search for a better value any more. >>> + *limit = min_allocation_size; >> In the first "else if" if you changed it to (upper_limit <= >> min_allocation_size) >> can you eliminate the second "else if" like this >> >> + if (is_allocatable(upper_limit)) { >> + *limit = upper_limit; >> + } else if (upper_limit <= min_allocation_size) { >> + *limit = upper_limit; >> >> And it might read more easily as >> >> + if (is_allocatable(upper_limit) || >> +upper_limit <= min_allocation_size) { >> + *limit = upper_limit; > a new webrev with your suggested change is available at > > http://cr.openjdk.java.net/~tschatzl/7112912/webrev.2/ > > Again, the change passed jprt. > > Hth, > Thomas > > From jon.masamitsu at oracle.com Tue Mar 26 02:17:37 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 25 Mar 2013 19:17:37 -0700 Subject: Request for review (m) - 8008508: CMS does not correctly reduce heap size after a Full GC In-Reply-To: <514149CC.6000003@oracle.com> References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com> <514149CC.6000003@oracle.com> Message-ID: <51510541.5070509@oracle.com> I have reviews for the principle part of the change (webrev.02) (thanks JohnCu and Ramki) so will push that change. The second part (webrev02.1) is a refactoring to share code. I don't have any reviews for that so will not push it. Jon On 3/13/2013 8:53 PM, Jon Masamitsu wrote: > Ramki, > > I've replied to your coding comments below. > > All, > > I've update the webrev for all the changes so far. > > http://cr.openjdk.java.net/~jmasa/8008508/webrev.02/ > > I've also added two helper functions for compute_new_size() > so that code could be shared as appropriate. Just the > refactoring changes are in this webrev. > > http://cr.openjdk.java.net/~jmasa/8008508/webrev.02.1/ > > Thanks. > > Jon > > On 3/2/2013 12:42 AM, Srinivas Ramakrishna wrote: >> Hi Jon -- >> >> I'll give a couple of code-level comments, but there's a high-level >> comment at the end, which >> might be worth pondering over. >> >> On Tue, Feb 26, 2013 at 3:47 PM, Jon >> Masamitsu wrote: >>> I've updated the webrev for review comments (thanks, JohnCu) >>> >>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/ >>> >> concurrent MarkSweepGeneration.cpp: >> >> 949 // compute expansion delta needed for reaching desired free >> percentage >> 950 if (free_percentage < desired_free_percentage) { >> 951 size_t desired_capacity = (size_t)(used() / ((double) 1 - >> desired_free_percentage)); >> 952 assert(desired_capacity >= capacity(), "invalid expansion >> size"); >> 953 size_t expand_bytes = MAX2(desired_capacity - capacity(), >> MinHeapDeltaBytes); >> >> 954 if (expand_bytes > 0) { >> >> The if test at 954 (in your changed code) will always be true because >> MinHeapDeltaBytes > 0 >> and we are taking the max at line 953. > > Ok. MinHeapDeltaBytes is a product flag so it could be set to 0 but > other > collectors ignore that possibility so I'll take out the test. > > >> On reading your shrinking code further below at lines 989-994, it >> struck me that there's a small >> existing bug in the shrink/expand code here. It's probably more of a >> factor in the shrink code though >> because we can live with more free space than we'd ideally want, but >> not less than we ideally want, >> and we certainly do not want to chatter around the desired free >> percentage (hence the delta). >> >> Your shrinking arm looks like this:- >> >> 989 } else { >> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >> desired_free_percentage)); >> 991 assert(desired_capacity <= capacity(), "invalid expansion >> size"); >> 992 size_t shrink_bytes = MAX2(capacity() - desired_capacity, >> MinHeapDeltaBytes); >> 993 shrink_free_list_by(shrink_bytes); >> 994 } >> >> I'd modify it to:- >> >> 989 } else { >> 990 size_t desired_capacity = (size_t)(used() / ((double) 1 - >> desired_free_percentage)); >> 991 assert(desired_capacity <= capacity(), "invalid expansion >> size"); >> size_t shrink_bytes = capacity() - desired_capacity; >> // Don't shrink unless the delta is greater than the >> minimum shrink we want >> 992 if (shrink_bytes >= MinHeapDeltaBytes) { >> 993 shrink_free_list_by(shrink_bytes); >> } >> 994 } > > I changed the code as you suggested. Thanks for catching this. > >> Note the asymmetry between expansion and shrinking, where we expand by >> the min if we feel we are below the desired free, but we don't shrink >> even if we are above desired free unless the gap exceeds the min >> delta. > > Seems right. >> This seems to be the correct policy. (Of course none of that is moot >> until shrink_free_list_by() starts doing shrinking, but probably best >> to fix the policy now, so that it doesn't cause chatter later. >> >> concurrentMarkSweepGeneration.hpp: >> >> 1298 virtual void compute_new_size(); >> 1299 void compute_new_size_free_list(); >> >> I think it would be good to add a 1-line doc comment for each of the >> above methods. > > Added > > // Resize the generation after a compacting GC. The > // generation can be treated as a contiguous space > // after the compaction. > virtual void compute_new_size(); > // Resize the generation after a non-compacting > // collection. > void compute_new_size_free_list(); > > >> vmStructs.cpp: >> >> I think you also have to adjust the fields _capacity_at_prologue and >> _used_at_prologue into the superclass. I'd also move the decls up to >> CardGeneration, since that's how the original code is laid out. > > Done > >> Finally, a high level comment. While I see the reason for these >> mechanics, I worry a little bit >> about the somewhat schizophrenic expansion/shrinkage policy, as it >> swings between one policy >> used when we are presumably doing well and keeping up with the >> application's >> allocation/promotion rates and not running into concurrent mode >> failure, but then suddenly switching >> to a completely different expansion/shrinking policy when we do a >> compaction (presumably because >> we had a concurrent mode failure). I'd much rather have divorced the >> two, by using a more uniform >> policy specifically for CMS, perhaps predicated by whether this was >> happening after a >> compaction or not, but keeping it separate from the policy that might >> be used for stop-world >> kind of collectors (hence TenuredGeneraion). >> >> I'd appreciate it if you could give some thought to this final high >> level comment regarding the >> general policy approach taken here. (Also it is somewhat troubling to >> push policy so high up >> into the class hierarchy, so that every subclass must live with it; >> I'd much rather the policy >> were separated from the mechanics of what would be done when an >> expansion or shrinkage >> was needed.) >> >> -- ramki > From yumin.qi at oracle.com Tue Mar 26 03:56:38 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 20:56:38 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5150EF71.8040507@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> Message-ID: <51511C76.4070809@oracle.com> David, On 3/25/2013 5:44 PM, David Holmes wrote: > Hi Yumin, > > I have a few suggested changes. > > First in os.hpp I suggest > > return _processor_count > 1 || AssumeMP ; > > That way we don't bypass the assertion and don't encounter unnecessary > overhead on the common path. > Yes, will change. > In arguments.cpp: > > + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { > + warning("With AssumeMP, recommend run with > -XX:ParallelGCThreads=, where" > + " num_of_gc_threads can be set to number of cores"); > + } > > I'm not convinced issuing a warning is necessary or desirable here. > With a uniprocessor startup will we even default to using parallel GC? > The above should only be issued if using parallel GC - so better to > move it into set_parallel_gc_flags(). > > In any case it isn't clear what the user should supply here. If they > use the maximum expected number of cores initially then while they > only have 1 core their VM may not even function adequately due to GC > overhead. I think all you can say here is something like: > > warning("If the number of processors is expected to increase from one, > then you should configure the number of parallel GC threads > appropriately using -XX:ParallelGCThreads=N"); > I am giving a hint here to suggest about number of gc threads based on code. If customer want to use this flag, they should know it will affect GC. I will move this to set_parallel_gc_flags, which covers parnew and parallel. Thanks for pointing this, I did not notice serial gc not using ParallelGCThreads. > > In globals.hpp: > > + product(bool, AssumeMP, false, \ > + "Assume run on multiple processors always") \ > > Was there any discussion on making this default to true instead? > No discussion for it. I like to have false as default because if (in fact rarely) user run on a single cpu machine, keep it as used to be is better. > Suggested re-wording: > > "Instruct the VM to assume multiple processors are available" > Thanks Yumin > Thanks, > David > > On 26/03/2013 9:15 AM, Yumin Qi wrote: >> It should be "AssumeMP". >> >> /Yumin >> >> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>> Hi, >>> >>> New webrev to use "-XX:+AssumMP" flag. Also add warning to recommend >>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>> running with only one GC thread. This is verified by Oleksandr with >>> the test case running on Linux which is not Zone configured. >>> >>> Same link. >>> >>> Thanks >>> Yumin >>> >>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>> >>>> 2178143: VM crashes if the number of bound CPUs changed during >>>> runtime. >>>> >>>> Situation: Customer first configure only one CPU online and turn >>>> others offline to run java application, after java program started, >>>> bring more CPUs back online. Since VM started on a single CPU, >>>> os::is_MP() will return false, but after more CPUs available, OS will >>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>> places where data consistency was broken. The solution is supply a >>>> flag to assume it is running on MP, so lock is forced to be called. >>>> >>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>> >>>> Thanks >>>> Yumin >>> >> From bengt.rutisson at oracle.com Tue Mar 26 04:56:55 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Mar 2013 05:56:55 +0100 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <51509C17.6080808@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> Message-ID: <51512A97.2030600@oracle.com> Hi Tao, Thanks for updating the tests. Looks good to me. Have you tried running the tests? It is a very small change so it should be ok. But our testing process is very strange and it may be that these tests are not run until PIT testing, so running them once before pushing is a good idea to avoid unnecessary issues later on. Also, I see that you decided not to remove "likely" from the other messages in Arguments::check_deprecated_gcs(). Would you like to do that as a separate change or do you think we should leave those messages unchanged? Thanks, Bengt On 3/25/13 7:48 PM, Tao Mao wrote: > Thank you for pointing it out, Bengt. A new webrev is updated. > http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ > > Please see inline. > Tao > > On 3/24/13 1:16 PM, Bengt Rutisson wrote: >> >> Hi Tao, >> >> On 3/23/13 4:51 AM, Tao Mao wrote: >>> Thank you for review and suggestion. A new webrev is updated. >>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >> >> I like Jon's suggestion about removing the word "likely" but that >> means that you need to update these tests: >> >> test/gc/startup_warnings/TestCMSIncrementalMode.java >> test/gc/startup_warnings/TestIncGC.java > Test files modified. >> >> Also, would it make sense to remove the word "likely" from the >> warning messages in Arguments::check_deprecated_gcs() too? In that >> case you need to update these tests as well: >> >> test/gc/startup_warnings/TestDefNewCMS.java >> test/gc/startup_warnings/TestParNewSerialOld.java > Have we made a decision to certainly remove these gc comb's in future? > If so, it's OK to state so. Anyway, it would be better to resolve it > with a separate CR. >> >> Bengt >> >>> >>> Tao >>> >>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>> Tao, >>>> >>>> Changes look fine. I would remove the "likely" so that messages >>>> read like >>>> >>>> "and will be removed in a future release" >>>> >>>> Fewer words are better and the intent is still clear. >>>> >>>> Jon >>>> >>>> >>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>> A simple changeset. Need a reviewer! >>>>> >>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>> Arguments::check_deprecated_gcs() to >>>>> Arguments::check_deprecated_gc_flags() >>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>> >>>>> changeset: >>>>> Cleanup suggested by Bengt. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.qi at oracle.com Tue Mar 26 05:30:20 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 22:30:20 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5150EF71.8040507@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> Message-ID: <5151326C.8030002@oracle.com> David and All, Changed as suggested by David. David, I did not move the warning into set_parallel_gc_flags() since except for serial gc, all other GCs will check this flag, so I moved it into #if INCLUDE_ALL_GCS before call set GC flags. new webrev: http://cr.openjdk.java.net/~minqi/2178143/ Thanks Yumin On 3/25/2013 5:44 PM, David Holmes wrote: > Hi Yumin, > > I have a few suggested changes. > > First in os.hpp I suggest > > return _processor_count > 1 || AssumeMP ; > > That way we don't bypass the assertion and don't encounter unnecessary > overhead on the common path. > > In arguments.cpp: > > + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { > + warning("With AssumeMP, recommend run with > -XX:ParallelGCThreads=, where" > + " num_of_gc_threads can be set to number of cores"); > + } > > I'm not convinced issuing a warning is necessary or desirable here. > With a uniprocessor startup will we even default to using parallel GC? > The above should only be issued if using parallel GC - so better to > move it into set_parallel_gc_flags(). > > In any case it isn't clear what the user should supply here. If they > use the maximum expected number of cores initially then while they > only have 1 core their VM may not even function adequately due to GC > overhead. I think all you can say here is something like: > > warning("If the number of processors is expected to increase from one, > then you should configure the number of parallel GC threads > appropriately using -XX:ParallelGCThreads=N"); > > > In globals.hpp: > > + product(bool, AssumeMP, false, \ > + "Assume run on multiple processors always") \ > > Was there any discussion on making this default to true instead? > > Suggested re-wording: > > "Instruct the VM to assume multiple processors are available" > > Thanks, > David > > On 26/03/2013 9:15 AM, Yumin Qi wrote: >> It should be "AssumeMP". >> >> /Yumin >> >> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>> Hi, >>> >>> New webrev to use "-XX:+AssumMP" flag. Also add warning to recommend >>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>> running with only one GC thread. This is verified by Oleksandr with >>> the test case running on Linux which is not Zone configured. >>> >>> Same link. >>> >>> Thanks >>> Yumin >>> >>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>> >>>> 2178143: VM crashes if the number of bound CPUs changed during >>>> runtime. >>>> >>>> Situation: Customer first configure only one CPU online and turn >>>> others offline to run java application, after java program started, >>>> bring more CPUs back online. Since VM started on a single CPU, >>>> os::is_MP() will return false, but after more CPUs available, OS will >>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>> places where data consistency was broken. The solution is supply a >>>> flag to assume it is running on MP, so lock is forced to be called. >>>> >>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>> >>>> Thanks >>>> Yumin >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Mar 26 05:41:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2013 15:41:11 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151326C.8030002@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> Message-ID: <515134F7.4050007@oracle.com> On 26/03/2013 3:30 PM, Yumin Qi wrote: > David and All, > > Changed as suggested by David. > > David, I did not move the warning into set_parallel_gc_flags() since > except for serial gc, all other GCs will check this flag, so I moved it > into > #if INCLUDE_ALL_GCS > > before call set GC flags. I didn't realize all the other GCs would utilize ParallelGCThreads. Can we at least exclude it for serial GC case? Otherwise looks good. Thanks, David > new webrev: http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin > > > > On 3/25/2013 5:44 PM, David Holmes wrote: >> Hi Yumin, >> >> I have a few suggested changes. >> >> First in os.hpp I suggest >> >> return _processor_count > 1 || AssumeMP ; >> >> That way we don't bypass the assertion and don't encounter unnecessary >> overhead on the common path. >> >> In arguments.cpp: >> >> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >> + warning("With AssumeMP, recommend run with >> -XX:ParallelGCThreads=, where" >> + " num_of_gc_threads can be set to number of cores"); >> + } >> >> I'm not convinced issuing a warning is necessary or desirable here. >> With a uniprocessor startup will we even default to using parallel GC? >> The above should only be issued if using parallel GC - so better to >> move it into set_parallel_gc_flags(). >> >> In any case it isn't clear what the user should supply here. If they >> use the maximum expected number of cores initially then while they >> only have 1 core their VM may not even function adequately due to GC >> overhead. I think all you can say here is something like: >> >> warning("If the number of processors is expected to increase from one, >> then you should configure the number of parallel GC threads >> appropriately using -XX:ParallelGCThreads=N"); >> >> >> In globals.hpp: >> >> + product(bool, AssumeMP, false, \ >> + "Assume run on multiple processors always") \ >> >> Was there any discussion on making this default to true instead? >> >> Suggested re-wording: >> >> "Instruct the VM to assume multiple processors are available" >> >> Thanks, >> David >> >> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>> It should be "AssumeMP". >>> >>> /Yumin >>> >>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>> Hi, >>>> >>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to recommend >>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>> running with only one GC thread. This is verified by Oleksandr with >>>> the test case running on Linux which is not Zone configured. >>>> >>>> Same link. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>> >>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>> runtime. >>>>> >>>>> Situation: Customer first configure only one CPU online and turn >>>>> others offline to run java application, after java program started, >>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>> os::is_MP() will return false, but after more CPUs available, OS will >>>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>>> places where data consistency was broken. The solution is supply a >>>>> flag to assume it is running on MP, so lock is forced to be called. >>>>> >>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>> >>>>> Thanks >>>>> Yumin >>>> >>> > From yumin.qi at oracle.com Tue Mar 26 05:56:44 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 22:56:44 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <515134F7.4050007@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> Message-ID: <5151389C.6060806@oracle.com> David, On 3/25/2013 10:41 PM, David Holmes wrote: > On 26/03/2013 3:30 PM, Yumin Qi wrote: >> David and All, >> >> Changed as suggested by David. >> >> David, I did not move the warning into set_parallel_gc_flags() since >> except for serial gc, all other GCs will check this flag, so I moved it >> into >> #if INCLUDE_ALL_GCS >> >> before call set GC flags. > > I didn't realize all the other GCs would utilize ParallelGCThreads. > Can we at least exclude it for serial GC case? > Serial GC is set here: 3253 #if !INCLUDE_ALL_GCS 3254 force_serial_gc(); 3255 #endif // INCLUDE_ALL_GCS So after it moved into 3283 #if INCLUDE_ALL_GCS 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { 3285 warning("If the number of processors is expected to increase from one, then" 3286 " you should configure the number of parallel GC threads appropriately" 3287 " using -XX:ParallelGCThreads=N"); 3288 } 3289 // Set per-collector flags 3290 if (UseParallelGC || UseParallelOldGC) { 3291 set_parallel_gc_flags(); 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew check below 3293 set_cms_and_parnew_gc_flags(); 3294 } else if (UseParNewGC) { // skipped if CMS is set above 3295 set_parnew_gc_flags(); 3296 } else if (UseG1GC) { 3297 set_g1_gc_flags(); 3298 } 3299 check_deprecated_gcs(); 3300 #else // INCLUDE_ALL_GCS 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); 3302 #endif // INCLUDE_ALL_GCS It is excluded for serial GC. Thanks Yumin > Otherwise looks good. > > Thanks, > David > >> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin >> >> >> >> On 3/25/2013 5:44 PM, David Holmes wrote: >>> Hi Yumin, >>> >>> I have a few suggested changes. >>> >>> First in os.hpp I suggest >>> >>> return _processor_count > 1 || AssumeMP ; >>> >>> That way we don't bypass the assertion and don't encounter unnecessary >>> overhead on the common path. >>> >>> In arguments.cpp: >>> >>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>> + warning("With AssumeMP, recommend run with >>> -XX:ParallelGCThreads=, where" >>> + " num_of_gc_threads can be set to number of cores"); >>> + } >>> >>> I'm not convinced issuing a warning is necessary or desirable here. >>> With a uniprocessor startup will we even default to using parallel GC? >>> The above should only be issued if using parallel GC - so better to >>> move it into set_parallel_gc_flags(). >>> >>> In any case it isn't clear what the user should supply here. If they >>> use the maximum expected number of cores initially then while they >>> only have 1 core their VM may not even function adequately due to GC >>> overhead. I think all you can say here is something like: >>> >>> warning("If the number of processors is expected to increase from one, >>> then you should configure the number of parallel GC threads >>> appropriately using -XX:ParallelGCThreads=N"); >>> >>> >>> In globals.hpp: >>> >>> + product(bool, AssumeMP, false, \ >>> + "Assume run on multiple processors always") \ >>> >>> Was there any discussion on making this default to true instead? >>> >>> Suggested re-wording: >>> >>> "Instruct the VM to assume multiple processors are available" >>> >>> Thanks, >>> David >>> >>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>> It should be "AssumeMP". >>>> >>>> /Yumin >>>> >>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>> Hi, >>>>> >>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>> recommend >>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>> running with only one GC thread. This is verified by Oleksandr with >>>>> the test case running on Linux which is not Zone configured. >>>>> >>>>> Same link. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>> >>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>> runtime. >>>>>> >>>>>> Situation: Customer first configure only one CPU online and turn >>>>>> others offline to run java application, after java program started, >>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>> will >>>>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>>>> places where data consistency was broken. The solution is supply a >>>>>> flag to assume it is running on MP, so lock is forced to be called. >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>> >>>> >> From david.holmes at oracle.com Tue Mar 26 06:00:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2013 16:00:38 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151389C.6060806@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> Message-ID: <51513986.9030207@oracle.com> On 26/03/2013 3:56 PM, Yumin Qi wrote: > David, > > On 3/25/2013 10:41 PM, David Holmes wrote: >> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>> David and All, >>> >>> Changed as suggested by David. >>> >>> David, I did not move the warning into set_parallel_gc_flags() since >>> except for serial gc, all other GCs will check this flag, so I moved it >>> into >>> #if INCLUDE_ALL_GCS >>> >>> before call set GC flags. >> >> I didn't realize all the other GCs would utilize ParallelGCThreads. >> Can we at least exclude it for serial GC case? >> > > Serial GC is set here: INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we only have SerialGC. So you have excluded it for the case where SerialGC is the only GC built into the VM, but not for the case where all GCs are available and the user requests UseSerialGC. David ----- > 3253 #if !INCLUDE_ALL_GCS > 3254 force_serial_gc(); > 3255 #endif // INCLUDE_ALL_GCS > > So after it moved into > 3283 #if INCLUDE_ALL_GCS > 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { > 3285 warning("If the number of processors is expected to increase > from one, then" > 3286 " you should configure the number of parallel GC > threads appropriately" > 3287 " using -XX:ParallelGCThreads=N"); > 3288 } > 3289 // Set per-collector flags > 3290 if (UseParallelGC || UseParallelOldGC) { > 3291 set_parallel_gc_flags(); > 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew > check below > 3293 set_cms_and_parnew_gc_flags(); > 3294 } else if (UseParNewGC) { // skipped if CMS is set above > 3295 set_parnew_gc_flags(); > 3296 } else if (UseG1GC) { > 3297 set_g1_gc_flags(); > 3298 } > 3299 check_deprecated_gcs(); > 3300 #else // INCLUDE_ALL_GCS > 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); > 3302 #endif // INCLUDE_ALL_GCS > > It is excluded for serial GC. > > Thanks > Yumin > >> Otherwise looks good. >> >> Thanks, >> David >> >>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>> >>> Thanks >>> Yumin >>> >>> >>> >>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>> Hi Yumin, >>>> >>>> I have a few suggested changes. >>>> >>>> First in os.hpp I suggest >>>> >>>> return _processor_count > 1 || AssumeMP ; >>>> >>>> That way we don't bypass the assertion and don't encounter unnecessary >>>> overhead on the common path. >>>> >>>> In arguments.cpp: >>>> >>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>> + warning("With AssumeMP, recommend run with >>>> -XX:ParallelGCThreads=, where" >>>> + " num_of_gc_threads can be set to number of cores"); >>>> + } >>>> >>>> I'm not convinced issuing a warning is necessary or desirable here. >>>> With a uniprocessor startup will we even default to using parallel GC? >>>> The above should only be issued if using parallel GC - so better to >>>> move it into set_parallel_gc_flags(). >>>> >>>> In any case it isn't clear what the user should supply here. If they >>>> use the maximum expected number of cores initially then while they >>>> only have 1 core their VM may not even function adequately due to GC >>>> overhead. I think all you can say here is something like: >>>> >>>> warning("If the number of processors is expected to increase from one, >>>> then you should configure the number of parallel GC threads >>>> appropriately using -XX:ParallelGCThreads=N"); >>>> >>>> >>>> In globals.hpp: >>>> >>>> + product(bool, AssumeMP, false, \ >>>> + "Assume run on multiple processors always") \ >>>> >>>> Was there any discussion on making this default to true instead? >>>> >>>> Suggested re-wording: >>>> >>>> "Instruct the VM to assume multiple processors are available" >>>> >>>> Thanks, >>>> David >>>> >>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>> It should be "AssumeMP". >>>>> >>>>> /Yumin >>>>> >>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>> Hi, >>>>>> >>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>> recommend >>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>>> running with only one GC thread. This is verified by Oleksandr with >>>>>> the test case running on Linux which is not Zone configured. >>>>>> >>>>>> Same link. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>> >>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>> runtime. >>>>>>> >>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>> others offline to run java application, after java program started, >>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>> will >>>>>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>>>>> places where data consistency was broken. The solution is supply a >>>>>>> flag to assume it is running on MP, so lock is forced to be called. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>> >>>>> >>> > From yumin.qi at oracle.com Tue Mar 26 06:21:04 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 25 Mar 2013 23:21:04 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51513986.9030207@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> Message-ID: <51513E50.7000401@oracle.com> You are right, thanks! I misread the INCLUDE. new web in the same link. Thanks Yumin On 3/25/2013 11:00 PM, David Holmes wrote: > On 26/03/2013 3:56 PM, Yumin Qi wrote: >> David, >> >> On 3/25/2013 10:41 PM, David Holmes wrote: >>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>> David and All, >>>> >>>> Changed as suggested by David. >>>> >>>> David, I did not move the warning into set_parallel_gc_flags() since >>>> except for serial gc, all other GCs will check this flag, so I >>>> moved it >>>> into >>>> #if INCLUDE_ALL_GCS >>>> >>>> before call set GC flags. >>> >>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>> Can we at least exclude it for serial GC case? >>> >> >> Serial GC is set here: > > INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we only > have SerialGC. So you have excluded it for the case where SerialGC is > the only GC built into the VM, but not for the case where all GCs are > available and the user requests UseSerialGC. > > David > ----- > > >> 3253 #if !INCLUDE_ALL_GCS >> 3254 force_serial_gc(); >> 3255 #endif // INCLUDE_ALL_GCS >> >> So after it moved into >> 3283 #if INCLUDE_ALL_GCS >> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >> 3285 warning("If the number of processors is expected to increase >> from one, then" >> 3286 " you should configure the number of parallel GC >> threads appropriately" >> 3287 " using -XX:ParallelGCThreads=N"); >> 3288 } >> 3289 // Set per-collector flags >> 3290 if (UseParallelGC || UseParallelOldGC) { >> 3291 set_parallel_gc_flags(); >> 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew >> check below >> 3293 set_cms_and_parnew_gc_flags(); >> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >> 3295 set_parnew_gc_flags(); >> 3296 } else if (UseG1GC) { >> 3297 set_g1_gc_flags(); >> 3298 } >> 3299 check_deprecated_gcs(); >> 3300 #else // INCLUDE_ALL_GCS >> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >> 3302 #endif // INCLUDE_ALL_GCS >> >> It is excluded for serial GC. >> >> Thanks >> Yumin >> >>> Otherwise looks good. >>> >>> Thanks, >>> David >>> >>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> >>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>> Hi Yumin, >>>>> >>>>> I have a few suggested changes. >>>>> >>>>> First in os.hpp I suggest >>>>> >>>>> return _processor_count > 1 || AssumeMP ; >>>>> >>>>> That way we don't bypass the assertion and don't encounter >>>>> unnecessary >>>>> overhead on the common path. >>>>> >>>>> In arguments.cpp: >>>>> >>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>> + warning("With AssumeMP, recommend run with >>>>> -XX:ParallelGCThreads=, where" >>>>> + " num_of_gc_threads can be set to number of cores"); >>>>> + } >>>>> >>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>> With a uniprocessor startup will we even default to using parallel >>>>> GC? >>>>> The above should only be issued if using parallel GC - so better to >>>>> move it into set_parallel_gc_flags(). >>>>> >>>>> In any case it isn't clear what the user should supply here. If they >>>>> use the maximum expected number of cores initially then while they >>>>> only have 1 core their VM may not even function adequately due to GC >>>>> overhead. I think all you can say here is something like: >>>>> >>>>> warning("If the number of processors is expected to increase from >>>>> one, >>>>> then you should configure the number of parallel GC threads >>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>> >>>>> >>>>> In globals.hpp: >>>>> >>>>> + product(bool, AssumeMP, false, \ >>>>> + "Assume run on multiple processors always") \ >>>>> >>>>> Was there any discussion on making this default to true instead? >>>>> >>>>> Suggested re-wording: >>>>> >>>>> "Instruct the VM to assume multiple processors are available" >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>> It should be "AssumeMP". >>>>>> >>>>>> /Yumin >>>>>> >>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>> Hi, >>>>>>> >>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>> recommend >>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>>>> running with only one GC thread. This is verified by Oleksandr with >>>>>>> the test case running on Linux which is not Zone configured. >>>>>>> >>>>>>> Same link. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>> >>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>> runtime. >>>>>>>> >>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>> others offline to run java application, after java program >>>>>>>> started, >>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>> will >>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>>>>>> places where data consistency was broken. The solution is supply a >>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>> called. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Tue Mar 26 07:10:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Mar 2013 17:10:23 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51513E50.7000401@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> Message-ID: <515149DF.80401@oracle.com> Ship it! :) Thanks, David On 26/03/2013 4:21 PM, Yumin Qi wrote: > You are right, thanks! I misread the INCLUDE. > new web in the same link. > > Thanks > Yumin > > On 3/25/2013 11:00 PM, David Holmes wrote: >> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>> David, >>> >>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>> David and All, >>>>> >>>>> Changed as suggested by David. >>>>> >>>>> David, I did not move the warning into set_parallel_gc_flags() since >>>>> except for serial gc, all other GCs will check this flag, so I >>>>> moved it >>>>> into >>>>> #if INCLUDE_ALL_GCS >>>>> >>>>> before call set GC flags. >>>> >>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>> Can we at least exclude it for serial GC case? >>>> >>> >>> Serial GC is set here: >> >> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we only >> have SerialGC. So you have excluded it for the case where SerialGC is >> the only GC built into the VM, but not for the case where all GCs are >> available and the user requests UseSerialGC. >> >> David >> ----- >> >> >>> 3253 #if !INCLUDE_ALL_GCS >>> 3254 force_serial_gc(); >>> 3255 #endif // INCLUDE_ALL_GCS >>> >>> So after it moved into >>> 3283 #if INCLUDE_ALL_GCS >>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>> 3285 warning("If the number of processors is expected to increase >>> from one, then" >>> 3286 " you should configure the number of parallel GC >>> threads appropriately" >>> 3287 " using -XX:ParallelGCThreads=N"); >>> 3288 } >>> 3289 // Set per-collector flags >>> 3290 if (UseParallelGC || UseParallelOldGC) { >>> 3291 set_parallel_gc_flags(); >>> 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew >>> check below >>> 3293 set_cms_and_parnew_gc_flags(); >>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>> 3295 set_parnew_gc_flags(); >>> 3296 } else if (UseG1GC) { >>> 3297 set_g1_gc_flags(); >>> 3298 } >>> 3299 check_deprecated_gcs(); >>> 3300 #else // INCLUDE_ALL_GCS >>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>> 3302 #endif // INCLUDE_ALL_GCS >>> >>> It is excluded for serial GC. >>> >>> Thanks >>> Yumin >>> >>>> Otherwise looks good. >>>> >>>> Thanks, >>>> David >>>> >>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> >>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> I have a few suggested changes. >>>>>> >>>>>> First in os.hpp I suggest >>>>>> >>>>>> return _processor_count > 1 || AssumeMP ; >>>>>> >>>>>> That way we don't bypass the assertion and don't encounter >>>>>> unnecessary >>>>>> overhead on the common path. >>>>>> >>>>>> In arguments.cpp: >>>>>> >>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>> + warning("With AssumeMP, recommend run with >>>>>> -XX:ParallelGCThreads=, where" >>>>>> + " num_of_gc_threads can be set to number of cores"); >>>>>> + } >>>>>> >>>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>>> With a uniprocessor startup will we even default to using parallel >>>>>> GC? >>>>>> The above should only be issued if using parallel GC - so better to >>>>>> move it into set_parallel_gc_flags(). >>>>>> >>>>>> In any case it isn't clear what the user should supply here. If they >>>>>> use the maximum expected number of cores initially then while they >>>>>> only have 1 core their VM may not even function adequately due to GC >>>>>> overhead. I think all you can say here is something like: >>>>>> >>>>>> warning("If the number of processors is expected to increase from >>>>>> one, >>>>>> then you should configure the number of parallel GC threads >>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>> >>>>>> >>>>>> In globals.hpp: >>>>>> >>>>>> + product(bool, AssumeMP, false, \ >>>>>> + "Assume run on multiple processors always") \ >>>>>> >>>>>> Was there any discussion on making this default to true instead? >>>>>> >>>>>> Suggested re-wording: >>>>>> >>>>>> "Instruct the VM to assume multiple processors are available" >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>> It should be "AssumeMP". >>>>>>> >>>>>>> /Yumin >>>>>>> >>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>> recommend >>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>>>>> running with only one GC thread. This is verified by Oleksandr with >>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>> >>>>>>>> Same link. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>> >>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>> runtime. >>>>>>>>> >>>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>>> others offline to run java application, after java program >>>>>>>>> started, >>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>>> will >>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>>>>>>> places where data consistency was broken. The solution is supply a >>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>> called. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>> >>>>>>> >>>>> >>> > From erik.helin at oracle.com Tue Mar 26 10:14:31 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 26 Mar 2013 11:14:31 +0100 Subject: RFR (S) 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine In-Reply-To: <514B344F.9080307@oracle.com> References: <514B344F.9080307@oracle.com> Message-ID: <51517507.6020504@oracle.com> Mikael, the change looks good! Thanks, Erik On 03/21/2013 05:24 PM, Mikael Gerdin wrote: > Hi > > Please review the following change: > > When running a stress test that is repeatedly blocking GC from > triggering through the normal path we may get stuck in the allocation > path and stay in the allocation loop forever. > > In this case the problem seems to be that if some threads are repeatedly > entering and leaving JNI critical regions and thereby stressing the > GC_Locker an allocating thread may get stuck in the allocation loop and > never realize that the pending allocation is impossible due to heap usage. > > My suggested fix is to limit the amount of times we try to start GCs and > then simply give up and return NULL and fail the allocation, thereby > causing the caller to throw an OOME. > > Note that every time the counter is incremented because we return from > GC_Locker::stall_until_clear() the thread unlocking the GC_Locker has > actually triggered a GC. So we're not giving up without a fight. > > Public bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014552 > JIRA: https://jbs.oracle.com/bugs/browse/JDK-7014552 > Webrev: http://cr.openjdk.java.net/~mgerdin/7014552/webrev.0/ > > Thanks > /Mikael From bengt.rutisson at oracle.com Tue Mar 26 10:14:38 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Mar 2013 11:14:38 +0100 Subject: RFR (S) 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine In-Reply-To: <514B344F.9080307@oracle.com> References: <514B344F.9080307@oracle.com> Message-ID: <5151750E.6010709@oracle.com> Hi Mikael, Looks good! Bengt On 3/21/13 5:24 PM, Mikael Gerdin wrote: > Hi > > Please review the following change: > > When running a stress test that is repeatedly blocking GC from > triggering through the normal path we may get stuck in the allocation > path and stay in the allocation loop forever. > > In this case the problem seems to be that if some threads are > repeatedly entering and leaving JNI critical regions and thereby > stressing the GC_Locker an allocating thread may get stuck in the > allocation loop and never realize that the pending allocation is > impossible due to heap usage. > > My suggested fix is to limit the amount of times we try to start GCs > and then simply give up and return NULL and fail the allocation, > thereby causing the caller to throw an OOME. > > Note that every time the counter is incremented because we return from > GC_Locker::stall_until_clear() the thread unlocking the GC_Locker has > actually triggered a GC. So we're not giving up without a fight. > > Public bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014552 > JIRA: https://jbs.oracle.com/bugs/browse/JDK-7014552 > Webrev: http://cr.openjdk.java.net/~mgerdin/7014552/webrev.0/ > > Thanks > /Mikael From erik.helin at oracle.com Tue Mar 26 10:19:50 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 26 Mar 2013 11:19:50 +0100 Subject: RFR (S): 8008737: The trace event vm/gc/heap/summary is missing for CMS In-Reply-To: <5140C6FA.5030504@oracle.com> References: <5129E024.2040900@oracle.com> <5140C6FA.5030504@oracle.com> Message-ID: <51517646.8020807@oracle.com> All, I have updated the change based on internal feedback. The changes between webrev.02 and webrev.03 are: - Removed an unnecessary call to save_heap_summary in Initial_Mark. - The reporting and saving of heap summary events has been split into two functions: save_heap_summary and report_heap_summary. New webrev located at: http://cr.openjdk.java.net/~ehelin/8008737/webrev.03/ Thanks, Erik On 03/13/2013 07:35 PM, Erik Helin wrote: > All, > > the previous two changes, webrev.00 and webrev.01, did not ensure that > CMS collector had the heap lock when the call to capacity was being > done. This did not cause any error during testing, but it could lead to > strange bugs. I have therefore updated the change to take this into > account. > > The new change, webrev.02, ensures that the heap summary data is only > saved when the concurrent CMS collector has the heap lock. Since > "collect_in_background" can be aborted for various reasons, the heap > statistics are saved at three places for a concurrent CMS collection: > 1. Initial mark > 2. Final remark > 3. Resizing > > The heap summary that will be sent for a concurrent CMS collection > depend on how much progress the CMS background collector has done, the > most recent one will always be sent. > > The same is being done for a foreground CMS collection, but then it is > guaranteed that the heap summary will always be from the last save > point, Resizing, since a foreground CMS collection can not be aborted. > > Please see the new webrev located at: > http://cr.openjdk.java.net/~ehelin/8008737/webrev.02/ > > Thanks, > Erik > > On 02/24/2013 10:40 AM, Erik Helin wrote: >> Hi all, >> >> this change adds the trace event vm/gc/heap/summary to the CMS collector. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8008737/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008737 >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From mikael.gerdin at oracle.com Tue Mar 26 10:25:55 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Mar 2013 11:25:55 +0100 Subject: RFR (S): 8008737: The trace event vm/gc/heap/summary is missing for CMS In-Reply-To: <51517646.8020807@oracle.com> References: <5129E024.2040900@oracle.com> <5140C6FA.5030504@oracle.com> <51517646.8020807@oracle.com> Message-ID: <515177B3.90400@oracle.com> Erik, On 2013-03-26 11:19, Erik Helin wrote: > All, > > I have updated the change based on internal feedback. > > The changes between webrev.02 and webrev.03 are: > - Removed an unnecessary call to save_heap_summary in Initial_Mark. > - The reporting and saving of heap summary events has been split into > two functions: save_heap_summary and report_heap_summary. > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8008737/webrev.03/ This looks good to me. /Mikael > > Thanks, > Erik > > On 03/13/2013 07:35 PM, Erik Helin wrote: >> All, >> >> the previous two changes, webrev.00 and webrev.01, did not ensure that >> CMS collector had the heap lock when the call to capacity was being >> done. This did not cause any error during testing, but it could lead to >> strange bugs. I have therefore updated the change to take this into >> account. >> >> The new change, webrev.02, ensures that the heap summary data is only >> saved when the concurrent CMS collector has the heap lock. Since >> "collect_in_background" can be aborted for various reasons, the heap >> statistics are saved at three places for a concurrent CMS collection: >> 1. Initial mark >> 2. Final remark >> 3. Resizing >> >> The heap summary that will be sent for a concurrent CMS collection >> depend on how much progress the CMS background collector has done, the >> most recent one will always be sent. >> >> The same is being done for a foreground CMS collection, but then it is >> guaranteed that the heap summary will always be from the last save >> point, Resizing, since a foreground CMS collection can not be aborted. >> >> Please see the new webrev located at: >> http://cr.openjdk.java.net/~ehelin/8008737/webrev.02/ >> >> Thanks, >> Erik >> >> On 02/24/2013 10:40 AM, Erik Helin wrote: >>> Hi all, >>> >>> this change adds the trace event vm/gc/heap/summary to the CMS >>> collector. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8008737/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008737 >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik >> > From bengt.rutisson at oracle.com Tue Mar 26 10:26:34 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Mar 2013 11:26:34 +0100 Subject: RFR (M): 8008920: Tracing events for heap statistics In-Reply-To: <5150A522.3010301@oracle.com> References: <51444BB8.1050409@oracle.com> <514C1C7A.7020204@oracle.com> <515034C6.1040202@oracle.com> <515035FB.4020101@oracle.com> <51505580.5040302@oracle.com> <515058D1.7010705@oracle.com> <51505B68.5020201@oracle.com> <5150A522.3010301@oracle.com> Message-ID: <515177DA.8070601@oracle.com> Looks good. Bengt On 3/25/13 8:27 PM, Jesper Wilhelmsson wrote: > Looks good, > Ship it! > /Jesper > > Erik Helin skrev 25/3/13 3:12 PM: >> Hi Mikael, >> >> thanks for reviewing! >> >> On 03/25/2013 03:01 PM, Mikael Gerdin wrote: >>> Erik, >>> >>> On 2013-03-25 14:47, Erik Helin wrote: >>>> All, >>>> >>>> I have updated the change based on feedback from Bengt and Jesper. >>>> >>>> The differences between webrev.01 and webrev.02 are: >>>> - Updated the comment in VM_GC_HeapInspection. >>>> - Updated the label for the object count event. >>>> >>>> New webrev located at: >>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.02/ >>> >>> In concurrentMarkSweepGeneration.cpp: >>> It would feel more appropriate to have the call to >>> report_object_count_after_gc to before we _collectorState to Sweeping. >> >> Ok, I will move the code. >> >>> The rest looks good to me. >> >> Thanks! >> >> Erik >> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/25/2013 12:33 PM, Erik Helin wrote: >>>>> Bengt, >>>>> >>>>> On 03/25/2013 12:28 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Erik, >>>>>> >>>>>> This looks good. >>>>>> >>>>>> One small nit. In VM_GC_HeapInspection::collect() you preserved the >>>>>> comment from VM_GC_HeapInspection::doit(). The comment talks about >>>>>> issuing a warning message, but the code to log that message is >>>>>> left in >>>>>> doit(). Could we update the comment to be more consistent with >>>>>> the new >>>>>> code? >>>>> >>>>> I will update the comment. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> On 3/22/13 9:55 AM, Erik Helin wrote: >>>>>>> All, >>>>>>> >>>>>>> based on internal feedback, this change has been updated. >>>>>>> >>>>>>> The event has been renamed to vm/gc/detailed/object_count_after_gc. >>>>>>> Furthermore, the part of the change that updated >>>>>>> heapInspection.cpp/hpp has been extracted to a separate change >>>>>>> (also >>>>>>> out for review on hotspot-gc-dev at openjdk.java.net). >>>>>>> >>>>>>> New webrev located at: >>>>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>>> >>>>>>> On 03/16/2013 11:38 AM, Erik Helin wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> this change adds an event, vm/gc/detailed/class_count_after_gc, >>>>>>>> that >>>>>>>> sends information about the number of instances of each class >>>>>>>> on the >>>>>>>> heap (as well as size and the name of the class). >>>>>>>> >>>>>>>> The event is sent after the marking phase for all old collections >>>>>>>> and an >>>>>>>> object will be counted as live if the GC think that the object is >>>>>>>> live >>>>>>>> (this is only tricky in the case of a concurrent collection). >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~ehelin/8008920/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008920 >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>> >>>>>> >>>>> >>>> >> From bengt.rutisson at oracle.com Tue Mar 26 10:27:20 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Mar 2013 11:27:20 +0100 Subject: RFR (S): 8010294: Refactor HeapInspection to make it more reusable In-Reply-To: <51504E40.7050808@oracle.com> References: <514C1EF8.9060303@oracle.com> <51500BBB.8070702@oracle.com> <51502DBE.3040704@oracle.com> <5150352D.6090407@oracle.com> <51504E40.7050808@oracle.com> Message-ID: <51517808.9030205@oracle.com> Looks good. Bengt On 3/25/13 2:16 PM, Erik Helin wrote: > All, > > I have updated the change based on feedback from Bengt and Jesper. > > Differences between webrev.01 and webrev.02: > - Added #else clause in HeapInspection::start_of_perm_gen to make sure > that no compilers will isse any warnings. > - Removed the variable need_epilogue in > HeapInspection::instance_inspection, just kept the comment. > - Updated the @bug annotation of the test to the correct bug number, > 8010294. > > New webrev located at: > http://cr.openjdk.java.net/~ehelin/8010294/webrev.02/ > > Thanks, > Erik > > On 03/25/2013 12:29 PM, Erik Helin wrote: >> Bengt, >> >> On 03/25/2013 11:58 AM, Bengt Rutisson wrote: >>> >>> Hi Erik, >>> >>> Changes look good! >>> >>> One minor nit. I think the test contains the wrong bug number: >>> >>> * @bug 8004924 >> >> Agree, I will fix. >> >> Thanks, >> Erik >> >>> Bengt >>> >>> On 3/25/13 9:32 AM, Erik Helin wrote: >>>> All, >>>> >>>> I have updated the change based on internal feedback. >>>> >>>> The changes between webrev.00 and webrev.01 are mostly in the test >>>> code: >>>> - The test uses correct @summary description >>>> - The test now uses the correct command line flags >>>> - The test is more documented to describe how the test code is run >>>> >>>> There is also a very minor change in the hotspot code. I am now using >>>> the operator != instead of operator > when comparing the missed count. >>>> This was done just to make the diff one line smaller :) >>>> >>>> Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.01/ >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 03/22/2013 10:06 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> I have refactored the HeapInspection class to prepare for the >>>>> vm/gc/detailed/object_count_after_gc event. >>>>> >>>>> The refactoring mainly consists of breaking up the rather long >>>>> heap_inspect function to multiple small functions that can be reused. >>>>> >>>>> I also moved the public enums used to initialize KlassInfoTable and >>>>> KlassInfoHisto to private constants. Now they no longer have to be >>>>> passed as an argument to the constructor. >>>>> >>>>> I also added a test to ensure that my refactoring did not break >>>>> anything >>>>> (the test is not that extensive but at least it ensures that the >>>>> basic >>>>> stuff is working). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8010294/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010294 >>>>> >>>>> Testing: >>>>> - JPRT >>>>> - A new jtreg test (see webrev) >>>>> >>>>> Thanks, >>>>> Erik >>>> >>> >>> >> > From bengt.rutisson at oracle.com Tue Mar 26 10:30:32 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Mar 2013 11:30:32 +0100 Subject: RFR (S): 8008737: The trace event vm/gc/heap/summary is missing for CMS In-Reply-To: <515177B3.90400@oracle.com> References: <5129E024.2040900@oracle.com> <5140C6FA.5030504@oracle.com> <51517646.8020807@oracle.com> <515177B3.90400@oracle.com> Message-ID: <515178C8.1050403@oracle.com> On 3/26/13 11:25 AM, Mikael Gerdin wrote: > Erik, > > On 2013-03-26 11:19, Erik Helin wrote: >> All, >> >> I have updated the change based on internal feedback. >> >> The changes between webrev.02 and webrev.03 are: >> - Removed an unnecessary call to save_heap_summary in Initial_Mark. >> - The reporting and saving of heap summary events has been split into >> two functions: save_heap_summary and report_heap_summary. >> >> New webrev located at: >> http://cr.openjdk.java.net/~ehelin/8008737/webrev.03/ > > This looks good to me. Looks good to me too. Bengt > > /Mikael > >> >> Thanks, >> Erik >> >> On 03/13/2013 07:35 PM, Erik Helin wrote: >>> All, >>> >>> the previous two changes, webrev.00 and webrev.01, did not ensure that >>> CMS collector had the heap lock when the call to capacity was being >>> done. This did not cause any error during testing, but it could lead to >>> strange bugs. I have therefore updated the change to take this into >>> account. >>> >>> The new change, webrev.02, ensures that the heap summary data is only >>> saved when the concurrent CMS collector has the heap lock. Since >>> "collect_in_background" can be aborted for various reasons, the heap >>> statistics are saved at three places for a concurrent CMS collection: >>> 1. Initial mark >>> 2. Final remark >>> 3. Resizing >>> >>> The heap summary that will be sent for a concurrent CMS collection >>> depend on how much progress the CMS background collector has done, the >>> most recent one will always be sent. >>> >>> The same is being done for a foreground CMS collection, but then it is >>> guaranteed that the heap summary will always be from the last save >>> point, Resizing, since a foreground CMS collection can not be aborted. >>> >>> Please see the new webrev located at: >>> http://cr.openjdk.java.net/~ehelin/8008737/webrev.02/ >>> >>> Thanks, >>> Erik >>> >>> On 02/24/2013 10:40 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change adds the trace event vm/gc/heap/summary to the CMS >>>> collector. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8008737/webrev.00/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008737 >>>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Erik >>> >> From daniel.daugherty at oracle.com Tue Mar 26 12:50:21 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Mar 2013 06:50:21 -0600 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51513E50.7000401@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> Message-ID: <5151998D.5060201@oracle.com> > new webrev: http://cr.openjdk.java.net/~minqi/2178143/ Thumbs up. src/share/vm/runtime/arguments.cpp No comments. src/share/vm/runtime/globals.hpp If I followed the discussion over the default setting correctly, the default is false because we don't want to change the behavior for the single CPU case. I'm guessing that embedded is the primary use case for single CPU configs. We can (and should) revisit this in the future. src/share/vm/runtime/os.hpp No comments. Dan On 3/26/13 12:21 AM, Yumin Qi wrote: > You are right, thanks! I misread the INCLUDE. > new web in the same link. > > Thanks > Yumin > > On 3/25/2013 11:00 PM, David Holmes wrote: >> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>> David, >>> >>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>> David and All, >>>>> >>>>> Changed as suggested by David. >>>>> >>>>> David, I did not move the warning into set_parallel_gc_flags() since >>>>> except for serial gc, all other GCs will check this flag, so I >>>>> moved it >>>>> into >>>>> #if INCLUDE_ALL_GCS >>>>> >>>>> before call set GC flags. >>>> >>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>> Can we at least exclude it for serial GC case? >>>> >>> >>> Serial GC is set here: >> >> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we only >> have SerialGC. So you have excluded it for the case where SerialGC is >> the only GC built into the VM, but not for the case where all GCs are >> available and the user requests UseSerialGC. >> >> David >> ----- >> >> >>> 3253 #if !INCLUDE_ALL_GCS >>> 3254 force_serial_gc(); >>> 3255 #endif // INCLUDE_ALL_GCS >>> >>> So after it moved into >>> 3283 #if INCLUDE_ALL_GCS >>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>> 3285 warning("If the number of processors is expected to increase >>> from one, then" >>> 3286 " you should configure the number of parallel GC >>> threads appropriately" >>> 3287 " using -XX:ParallelGCThreads=N"); >>> 3288 } >>> 3289 // Set per-collector flags >>> 3290 if (UseParallelGC || UseParallelOldGC) { >>> 3291 set_parallel_gc_flags(); >>> 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew >>> check below >>> 3293 set_cms_and_parnew_gc_flags(); >>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>> 3295 set_parnew_gc_flags(); >>> 3296 } else if (UseG1GC) { >>> 3297 set_g1_gc_flags(); >>> 3298 } >>> 3299 check_deprecated_gcs(); >>> 3300 #else // INCLUDE_ALL_GCS >>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>> 3302 #endif // INCLUDE_ALL_GCS >>> >>> It is excluded for serial GC. >>> >>> Thanks >>> Yumin >>> >>>> Otherwise looks good. >>>> >>>> Thanks, >>>> David >>>> >>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> >>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> I have a few suggested changes. >>>>>> >>>>>> First in os.hpp I suggest >>>>>> >>>>>> return _processor_count > 1 || AssumeMP ; >>>>>> >>>>>> That way we don't bypass the assertion and don't encounter >>>>>> unnecessary >>>>>> overhead on the common path. >>>>>> >>>>>> In arguments.cpp: >>>>>> >>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>> + warning("With AssumeMP, recommend run with >>>>>> -XX:ParallelGCThreads=, where" >>>>>> + " num_of_gc_threads can be set to number of cores"); >>>>>> + } >>>>>> >>>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>>> With a uniprocessor startup will we even default to using >>>>>> parallel GC? >>>>>> The above should only be issued if using parallel GC - so better to >>>>>> move it into set_parallel_gc_flags(). >>>>>> >>>>>> In any case it isn't clear what the user should supply here. If they >>>>>> use the maximum expected number of cores initially then while they >>>>>> only have 1 core their VM may not even function adequately due to GC >>>>>> overhead. I think all you can say here is something like: >>>>>> >>>>>> warning("If the number of processors is expected to increase from >>>>>> one, >>>>>> then you should configure the number of parallel GC threads >>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>> >>>>>> >>>>>> In globals.hpp: >>>>>> >>>>>> + product(bool, AssumeMP, false, \ >>>>>> + "Assume run on multiple processors always") \ >>>>>> >>>>>> Was there any discussion on making this default to true instead? >>>>>> >>>>>> Suggested re-wording: >>>>>> >>>>>> "Instruct the VM to assume multiple processors are available" >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>> It should be "AssumeMP". >>>>>>> >>>>>>> /Yumin >>>>>>> >>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>> recommend >>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>>>>> running with only one GC thread. This is verified by Oleksandr >>>>>>>> with >>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>> >>>>>>>> Same link. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>> >>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>> runtime. >>>>>>>>> >>>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>>> others offline to run java application, after java program >>>>>>>>> started, >>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>>> will >>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>> various >>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>> supply a >>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>> called. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>> >>>>>>> >>>>> >>> > From mikael.gerdin at oracle.com Tue Mar 26 13:30:11 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Mar 2013 14:30:11 +0100 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure In-Reply-To: <514C0312.6000203@oracle.com> References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com> Message-ID: <5151A2E3.60507@oracle.com> Leonid, On 2013-03-22 08:06, Leonid Mesnik wrote: > Could anyone please review this small test fix. > > Leonid > On 03/20/2013 04:16 PM, Leonid Mesnik wrote: >> Hi >> >> Could you please review fix for 8009808 TEST-BUG : test case is using >> bash style tests. Default shell for jtreg is bourne. thus failure. >> >> I've completely rewritten test in java without major changes it test >> logic. >> I remove CMS so test could be run when CMS is not supported. Also I >> changed max memory to 128M to reduce memory load and increase number >> of GC log entries. Do you think it would be useful to run this test with different GCs? In that case you can pick up the test.vm.opts and test.java.opts system properties and add them to the java command line you launch. >> >> Here is the link: >> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ >> >> Are you sure about this: static final File currentDirectory = new File(System.getProperty("user.dir")); isn't user.dir the home directory? Current directory should be just "." Something like new File(".").getAbsoluteFile() should give you the current work dir. What is the relation between "numberOfFiles" and "minutesToRun"?? How do you know that running for 3 minutes will cause a log rotation? I know that you've just adapted the existing test but it seems strange to me. /Mikael > > From thomas.schatzl at oracle.com Tue Mar 26 13:56:23 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 26 Mar 2013 14:56:23 +0100 Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM In-Reply-To: <51509569.1020604@oracle.com> References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com> <1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus> <51509569.1020604@oracle.com> Message-ID: <1364306183.2847.52.camel@cirrus> Hi, On Mon, 2013-03-25 at 11:20 -0700, Jon Masamitsu wrote: > On 3/25/13 2:24 AM, Thomas Schatzl wrote: > > > Hi, > > > > The current behavior, that -Xms sets both initial and minimum heap size > > is very unsatisfying and not easily discoverable (which was the cause > > for this CR). The order of switches would be important, in addition to > > -Xms doing something unexpected. Additionally the initial/minimum heap > > sizes are not synchronized, so a user also sometimes gets strange error > > messages. > > > > The documentation for -Xms via java -X also contradicts (or at least > > omits important information) both external documentation and actual > > behavior. > > Since -Xms is a -X flag (e.g., is implemented by other > JVM's) I've assumed that we are stuck with supporting the > behavior as described. If it's not specified, we have some > flexibility. > At http://cr.openjdk.java.net/~tschatzl/8006088/webrev.3 there is a new webrev. It keeps the behavior that -Xms unconditionally sets both minimum and initial heap size. I could not find any document describing standard behavior, and the current behavior has been that way in the VM since its import into the current repository. Apart from that, this change - automatically adapts minimum heap size if only InitialHeapSize is given. This additional code is now needed as InitialHeapSize and -Xms have different behavior. Otherwise it is possible to get "Incompatible minimum and initial heap sizes specified" if only -XX:InitialHeapSize is specified with low values. - also allow specification of -Xms0 (i.e. size >= 0, not size > 0); this is a valid heap size specification, and means minimum/initial heap size = OldSize + NewSize. - improves the test cases (refactoring, new test cases) If you don't pass either -Xms or InitialHeapSize, the minimum/inital heap is ergonomically determined as before. Testing: jprt, manual testing Hth, Thomas From karen.kinnear at oracle.com Tue Mar 26 14:57:29 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 26 Mar 2013 10:57:29 -0400 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151998D.5060201@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151998D.5060201@oracle.com> Message-ID: <79B5A04B-1CC2-4066-90D9-9276F3691961@oracle.com> Yumin, Looks good. Thank you for simplifying the approach. thanks, Karen On Mar 26, 2013, at 8:50 AM, Daniel D. Daugherty wrote: > > new webrev: http://cr.openjdk.java.net/~minqi/2178143/ > > Thumbs up. > > src/share/vm/runtime/arguments.cpp > No comments. > > src/share/vm/runtime/globals.hpp > If I followed the discussion over the default setting correctly, > the default is false because we don't want to change the behavior > for the single CPU case. I'm guessing that embedded is the primary > use case for single CPU configs. We can (and should) revisit this > in the future. > > src/share/vm/runtime/os.hpp > No comments. > > Dan > > > On 3/26/13 12:21 AM, Yumin Qi wrote: >> You are right, thanks! I misread the INCLUDE. >> new web in the same link. >> >> Thanks >> Yumin >> >> On 3/25/2013 11:00 PM, David Holmes wrote: >>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>> David, >>>> >>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>> David and All, >>>>>> >>>>>> Changed as suggested by David. >>>>>> >>>>>> David, I did not move the warning into set_parallel_gc_flags() since >>>>>> except for serial gc, all other GCs will check this flag, so I moved it >>>>>> into >>>>>> #if INCLUDE_ALL_GCS >>>>>> >>>>>> before call set GC flags. >>>>> >>>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>>> Can we at least exclude it for serial GC case? >>>>> >>>> >>>> Serial GC is set here: >>> >>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we only have SerialGC. So you have excluded it for the case where SerialGC is the only GC built into the VM, but not for the case where all GCs are available and the user requests UseSerialGC. >>> >>> David >>> ----- >>> >>> >>>> 3253 #if !INCLUDE_ALL_GCS >>>> 3254 force_serial_gc(); >>>> 3255 #endif // INCLUDE_ALL_GCS >>>> >>>> So after it moved into >>>> 3283 #if INCLUDE_ALL_GCS >>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>> 3285 warning("If the number of processors is expected to increase >>>> from one, then" >>>> 3286 " you should configure the number of parallel GC >>>> threads appropriately" >>>> 3287 " using -XX:ParallelGCThreads=N"); >>>> 3288 } >>>> 3289 // Set per-collector flags >>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>> 3291 set_parallel_gc_flags(); >>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew >>>> check below >>>> 3293 set_cms_and_parnew_gc_flags(); >>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>> 3295 set_parnew_gc_flags(); >>>> 3296 } else if (UseG1GC) { >>>> 3297 set_g1_gc_flags(); >>>> 3298 } >>>> 3299 check_deprecated_gcs(); >>>> 3300 #else // INCLUDE_ALL_GCS >>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>> 3302 #endif // INCLUDE_ALL_GCS >>>> >>>> It is excluded for serial GC. >>>> >>>> Thanks >>>> Yumin >>>> >>>>> Otherwise looks good. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> I have a few suggested changes. >>>>>>> >>>>>>> First in os.hpp I suggest >>>>>>> >>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>> >>>>>>> That way we don't bypass the assertion and don't encounter unnecessary >>>>>>> overhead on the common path. >>>>>>> >>>>>>> In arguments.cpp: >>>>>>> >>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>> + warning("With AssumeMP, recommend run with >>>>>>> -XX:ParallelGCThreads=, where" >>>>>>> + " num_of_gc_threads can be set to number of cores"); >>>>>>> + } >>>>>>> >>>>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>>>> With a uniprocessor startup will we even default to using parallel GC? >>>>>>> The above should only be issued if using parallel GC - so better to >>>>>>> move it into set_parallel_gc_flags(). >>>>>>> >>>>>>> In any case it isn't clear what the user should supply here. If they >>>>>>> use the maximum expected number of cores initially then while they >>>>>>> only have 1 core their VM may not even function adequately due to GC >>>>>>> overhead. I think all you can say here is something like: >>>>>>> >>>>>>> warning("If the number of processors is expected to increase from one, >>>>>>> then you should configure the number of parallel GC threads >>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>> >>>>>>> >>>>>>> In globals.hpp: >>>>>>> >>>>>>> + product(bool, AssumeMP, false, \ >>>>>>> + "Assume run on multiple processors always") \ >>>>>>> >>>>>>> Was there any discussion on making this default to true instead? >>>>>>> >>>>>>> Suggested re-wording: >>>>>>> >>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>> It should be "AssumeMP". >>>>>>>> >>>>>>>> /Yumin >>>>>>>> >>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>> recommend >>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>>>>>> running with only one GC thread. This is verified by Oleksandr with >>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>> >>>>>>>>> Same link. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>> >>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>>> runtime. >>>>>>>>>> >>>>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>>>> others offline to run java application, after java program started, >>>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>>>> will >>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in various >>>>>>>>>> places where data consistency was broken. The solution is supply a >>>>>>>>>> flag to assume it is running on MP, so lock is forced to be called. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From erik.helin at oracle.com Tue Mar 26 15:03:16 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 26 Mar 2013 16:03:16 +0100 Subject: RFR (S): 8010818: NPG: Remove metaspace memory pools Message-ID: <5151B8B4.3040103@oracle.com> Hi all, I pushed "8000754: NPG: Implement a MemoryPool MXBean for Metaspace" last Friday (April 22). Unfortunately, the change triggered a couple of bugs: - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010719 8010719 : NPG: The metaspace memory pools acquires Metaspace allocation lock out of order with Service_lock - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010734 8010734 : NPG: The test MemoryTest.java needs to be updated to support metaspace - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010730 8010730 : NPG: Bad assert in JVM_ENTRY(jobject, jmm_GetMemoryUsage(JNIEnv* env, jboolean heap)) In order to not cause disturbance upstream (in hotspot-main), it is better to revert the change 8000754, since these bugs are only triggered due to the metaspace memory pools. The reverse patch was created by running: hg diff -r 4321 -r 4322 --reverse in the hotspot-gc/hotspot repistory. Webrev: http://cr.openjdk.java.net/~ehelin/8010818/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010818 Testing: - All tests that failed during nightly testing are now passing - JPRT Thanks, Erik From jon.masamitsu at oracle.com Tue Mar 26 15:03:36 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 26 Mar 2013 08:03:36 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51513E50.7000401@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> Message-ID: <5151B8C8.7060802@oracle.com> If I set AssumeMP on the command line and nothing else and am running on a platform where I get ParallelGCThreads > 1, am I going to see the warning? If yes, that seems too intrusive. I can see users hearing about the flag and deciding to include it always just to be safe. Jon On 3/25/13 11:21 PM, Yumin Qi wrote: > You are right, thanks! I misread the INCLUDE. > new web in the same link. > > Thanks > Yumin > > On 3/25/2013 11:00 PM, David Holmes wrote: >> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>> David, >>> >>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>> David and All, >>>>> >>>>> Changed as suggested by David. >>>>> >>>>> David, I did not move the warning into set_parallel_gc_flags() since >>>>> except for serial gc, all other GCs will check this flag, so I >>>>> moved it >>>>> into >>>>> #if INCLUDE_ALL_GCS >>>>> >>>>> before call set GC flags. >>>> >>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>> Can we at least exclude it for serial GC case? >>>> >>> >>> Serial GC is set here: >> >> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we only >> have SerialGC. So you have excluded it for the case where SerialGC is >> the only GC built into the VM, but not for the case where all GCs are >> available and the user requests UseSerialGC. >> >> David >> ----- >> >> >>> 3253 #if !INCLUDE_ALL_GCS >>> 3254 force_serial_gc(); >>> 3255 #endif // INCLUDE_ALL_GCS >>> >>> So after it moved into >>> 3283 #if INCLUDE_ALL_GCS >>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>> 3285 warning("If the number of processors is expected to increase >>> from one, then" >>> 3286 " you should configure the number of parallel GC >>> threads appropriately" >>> 3287 " using -XX:ParallelGCThreads=N"); >>> 3288 } >>> 3289 // Set per-collector flags >>> 3290 if (UseParallelGC || UseParallelOldGC) { >>> 3291 set_parallel_gc_flags(); >>> 3292 } else if (UseConcMarkSweepGC) { // should be done before ParNew >>> check below >>> 3293 set_cms_and_parnew_gc_flags(); >>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>> 3295 set_parnew_gc_flags(); >>> 3296 } else if (UseG1GC) { >>> 3297 set_g1_gc_flags(); >>> 3298 } >>> 3299 check_deprecated_gcs(); >>> 3300 #else // INCLUDE_ALL_GCS >>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>> 3302 #endif // INCLUDE_ALL_GCS >>> >>> It is excluded for serial GC. >>> >>> Thanks >>> Yumin >>> >>>> Otherwise looks good. >>>> >>>> Thanks, >>>> David >>>> >>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> >>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> I have a few suggested changes. >>>>>> >>>>>> First in os.hpp I suggest >>>>>> >>>>>> return _processor_count > 1 || AssumeMP ; >>>>>> >>>>>> That way we don't bypass the assertion and don't encounter >>>>>> unnecessary >>>>>> overhead on the common path. >>>>>> >>>>>> In arguments.cpp: >>>>>> >>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>> + warning("With AssumeMP, recommend run with >>>>>> -XX:ParallelGCThreads=, where" >>>>>> + " num_of_gc_threads can be set to number of cores"); >>>>>> + } >>>>>> >>>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>>> With a uniprocessor startup will we even default to using >>>>>> parallel GC? >>>>>> The above should only be issued if using parallel GC - so better to >>>>>> move it into set_parallel_gc_flags(). >>>>>> >>>>>> In any case it isn't clear what the user should supply here. If they >>>>>> use the maximum expected number of cores initially then while they >>>>>> only have 1 core their VM may not even function adequately due to GC >>>>>> overhead. I think all you can say here is something like: >>>>>> >>>>>> warning("If the number of processors is expected to increase from >>>>>> one, >>>>>> then you should configure the number of parallel GC threads >>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>> >>>>>> >>>>>> In globals.hpp: >>>>>> >>>>>> + product(bool, AssumeMP, false, \ >>>>>> + "Assume run on multiple processors always") \ >>>>>> >>>>>> Was there any discussion on making this default to true instead? >>>>>> >>>>>> Suggested re-wording: >>>>>> >>>>>> "Instruct the VM to assume multiple processors are available" >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>> It should be "AssumeMP". >>>>>>> >>>>>>> /Yumin >>>>>>> >>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>> recommend >>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to avoid >>>>>>>> running with only one GC thread. This is verified by Oleksandr >>>>>>>> with >>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>> >>>>>>>> Same link. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>> >>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>> runtime. >>>>>>>>> >>>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>>> others offline to run java application, after java program >>>>>>>>> started, >>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>>> will >>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>> various >>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>> supply a >>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>> called. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>> >>>>>>> >>>>> >>> > From anjul at anjul.com Tue Mar 26 05:35:47 2013 From: anjul at anjul.com (Anjul) Date: Mon, 25 Mar 2013 19:35:47 -1000 Subject: Can remapping/unmapping virtual memory make Java Garbage Collection go faster? Message-ID: Garbage collectors move data to eliminate holes in virtual memory both to make new allocations faster and to make it feasible to allocate large contiguous chunks. In modern 64-bit OSes two significant optimization possibilities seem to arise. One is to simply not do compaction. Instead, unmap pages that contain no live objects and keep allocating new objects to further and further areas of virtual memory by mapping pages in. On a 64-bit system this could be pretty sustainable. The other possibility is that if a large object does need to be compacted/moved to a different virtual address, then the pages that contain it could simply be remapped to a different area of virtual memory without copying any data. There would be extra work, relative to copying, for reorganizing the page tables, but I think that might be logarithmically smaller. This seems to ensure that there is no hole larger than a page. Sparsely occupied pages could be copied as usual or with some bookkeeping used for allocating small objects. Is there a problem in this scheme? Are there any JVMs out there that do this or are shortly expected to do so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Tue Mar 26 15:28:34 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Mar 2013 16:28:34 +0100 Subject: RFR (S): 8010818: NPG: Remove metaspace memory pools In-Reply-To: <5151B8B4.3040103@oracle.com> References: <5151B8B4.3040103@oracle.com> Message-ID: <5151BEA2.9080906@oracle.com> Erik, On 2013-03-26 16:03, Erik Helin wrote: > Hi all, > > I pushed "8000754: NPG: Implement a MemoryPool MXBean for Metaspace" > last Friday (April 22). Unfortunately, the change triggered a couple of > bugs: > > - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010719 > 8010719 : NPG: The metaspace memory pools acquires Metaspace > allocation lock out of order with Service_lock > - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010734 > 8010734 : NPG: The test MemoryTest.java needs to be updated to > support metaspace > - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010730 > 8010730 : NPG: Bad assert in JVM_ENTRY(jobject, > jmm_GetMemoryUsage(JNIEnv* env, jboolean heap)) > > In order to not cause disturbance upstream (in hotspot-main), it is > better to revert the change 8000754, since these bugs are only triggered > due to the metaspace memory pools. > > The reverse patch was created by running: > > hg diff -r 4321 -r 4322 --reverse > > in the hotspot-gc/hotspot repistory. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8010818/webrev.00/ Looks good to me. /m > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010818 > > Testing: > - All tests that failed during nightly testing are now passing > - JPRT > > Thanks, > Erik From bengt.rutisson at oracle.com Tue Mar 26 15:09:38 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Mar 2013 16:09:38 +0100 Subject: RFR(S): 8010463: G1: Crashes with -UseTLAB and heap verification In-Reply-To: <5150D7E7.10108@oracle.com> References: <514B8996.8030909@oracle.com> <514BFECC.8070206@oracle.com> <514CA0C3.3080306@oracle.com> <514FF8AF.5010806@oracle.com> <5150D7E7.10108@oracle.com> Message-ID: <5151BA32.5060508@oracle.com> Hi John, On 3/26/13 12:04 AM, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking again. A question inline... > > > On 3/25/2013 12:11 AM, Bengt Rutisson wrote: >> >>> >>>> >>>> About the test. Great that you write a regression test for this! :) >>>> >>>> The @summary says that the test uses -XX:+VerifyDuringGC but the >>>> command line is actually using -XX:+VerifyBeforeGC (which is >>>> correct, I think). Also, would it make sense to have a separate >>>> test that specifies -XX:+UseG1GC and checks the output that we >>>> expect to see? >>> >>> Yeah. Good catch. It should be with VerifyBeforeGC. Must have had >>> marking on the brain. >>> >>> As for the test. I think we can check the output for "VerifyBefore" >>> for all the collectors. I'll change the test. >> >> Great! > > I may have spoken too soon. Using ProcessBuilder, is there any way to > pass the GC flags to the spawned java process? The spawned process is > not being passed any additional flags that are passed to jtreg. For > example: > >> /home/jcuthber/jtreg/jtreg/solaris/bin/jtreg \ >> -jdk:/java/re/jdk/8/latest/binaries/solaris-i586/fastdebug \ >> -vmoption:-XX:+UseG1GC \ >> gc/TestVerifyBeforeGCDuringStartup.java > > does not pass -XX:+UseG1GC to the java process spawned by the test: > >> /* @test TestVerifyBeforeGCDuringStartup.java >> * @key gc >> * @bug 8010463 >> * @summary Simple test run with -XX:+VerifyBeforeGC -XX:-UseTLAB to >> verify 8010463 >> * @library /testlibrary >> */ >> >> import com.oracle.java.testlibrary.OutputAnalyzer; >> import com.oracle.java.testlibrary.ProcessTools; >> >> public class TestVerifyBeforeGCDuringStartup { >> public static void main(String args[]) throws Exception { >> ProcessBuilder pb = >> ProcessTools.createJavaProcessBuilder("-XX:+UseG1GC", >> "-XX:-UseTLAB", >> "-XX:+UnlockDiagnosticVMOptions", >> "-XX:+VerifyBeforeGC", "-version"); >> OutputAnalyzer output = new OutputAnalyzer(pb.start()); >> output.shouldContain("[Verifying"); >> output.shouldHaveExitValue(0); >> } >> } > > If I don't specify G1 in the argument list to ProcessBuilder, the test > does not fail. Hm. I am not that good with JTReg, but I think I have heard that you can get the different JTReg environment settings as system properties. Maybe there is a system property for the vmoption parameter that you can pick up and add to the spawned process? You probably want the system property corresponding to TESTVMOPTS. I'm not online right now, so I can't look at the JTReg documentation. > >>> 2. Use (VerifyBeforeGC && VerifyGCStartAt == 0) >> >> Right. I would prefer 1. but I'm fine with 2. Maybe 2. is more >> reasonable change to do for this fix. Perhaps 1. should be its own >> change. > > I went with 2. I'll submit a new CR to use a new flag (and use a > VMOperation). Sounds good. Thanks, Bengt > > Thanks, > > JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.qi at oracle.com Tue Mar 26 16:11:40 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 26 Mar 2013 09:11:40 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151B8C8.7060802@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> Message-ID: <5151C8BC.7050008@oracle.com> Jon, On 3/26/2013 8:03 AM, Jon Masamitsu wrote: > If I set AssumeMP on the command line and nothing else > and am running on a platform where I get ParallelGCThreads > 1, > am I going to see the warning? If yes, that seems too intrusive. > I can see users hearing about the flag and deciding to include > it always just to be safe. > Good question, let me check that. Thanks Yumin > > On 3/25/13 11:21 PM, Yumin Qi wrote: >> You are right, thanks! I misread the INCLUDE. >> new web in the same link. >> >> Thanks >> Yumin >> >> On 3/25/2013 11:00 PM, David Holmes wrote: >>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>> David, >>>> >>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>> David and All, >>>>>> >>>>>> Changed as suggested by David. >>>>>> >>>>>> David, I did not move the warning into set_parallel_gc_flags() since >>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>> moved it >>>>>> into >>>>>> #if INCLUDE_ALL_GCS >>>>>> >>>>>> before call set GC flags. >>>>> >>>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>>> Can we at least exclude it for serial GC case? >>>>> >>>> >>>> Serial GC is set here: >>> >>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>> only have SerialGC. So you have excluded it for the case where >>> SerialGC is the only GC built into the VM, but not for the case >>> where all GCs are available and the user requests UseSerialGC. >>> >>> David >>> ----- >>> >>> >>>> 3253 #if !INCLUDE_ALL_GCS >>>> 3254 force_serial_gc(); >>>> 3255 #endif // INCLUDE_ALL_GCS >>>> >>>> So after it moved into >>>> 3283 #if INCLUDE_ALL_GCS >>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>> 3285 warning("If the number of processors is expected to increase >>>> from one, then" >>>> 3286 " you should configure the number of parallel GC >>>> threads appropriately" >>>> 3287 " using -XX:ParallelGCThreads=N"); >>>> 3288 } >>>> 3289 // Set per-collector flags >>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>> 3291 set_parallel_gc_flags(); >>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>> ParNew >>>> check below >>>> 3293 set_cms_and_parnew_gc_flags(); >>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>> 3295 set_parnew_gc_flags(); >>>> 3296 } else if (UseG1GC) { >>>> 3297 set_g1_gc_flags(); >>>> 3298 } >>>> 3299 check_deprecated_gcs(); >>>> 3300 #else // INCLUDE_ALL_GCS >>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>> 3302 #endif // INCLUDE_ALL_GCS >>>> >>>> It is excluded for serial GC. >>>> >>>> Thanks >>>> Yumin >>>> >>>>> Otherwise looks good. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> I have a few suggested changes. >>>>>>> >>>>>>> First in os.hpp I suggest >>>>>>> >>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>> >>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>> unnecessary >>>>>>> overhead on the common path. >>>>>>> >>>>>>> In arguments.cpp: >>>>>>> >>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>> + warning("With AssumeMP, recommend run with >>>>>>> -XX:ParallelGCThreads=, where" >>>>>>> + " num_of_gc_threads can be set to number of cores"); >>>>>>> + } >>>>>>> >>>>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>>>> With a uniprocessor startup will we even default to using >>>>>>> parallel GC? >>>>>>> The above should only be issued if using parallel GC - so better to >>>>>>> move it into set_parallel_gc_flags(). >>>>>>> >>>>>>> In any case it isn't clear what the user should supply here. If >>>>>>> they >>>>>>> use the maximum expected number of cores initially then while they >>>>>>> only have 1 core their VM may not even function adequately due >>>>>>> to GC >>>>>>> overhead. I think all you can say here is something like: >>>>>>> >>>>>>> warning("If the number of processors is expected to increase >>>>>>> from one, >>>>>>> then you should configure the number of parallel GC threads >>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>> >>>>>>> >>>>>>> In globals.hpp: >>>>>>> >>>>>>> + product(bool, AssumeMP, false, \ >>>>>>> + "Assume run on multiple processors always") \ >>>>>>> >>>>>>> Was there any discussion on making this default to true instead? >>>>>>> >>>>>>> Suggested re-wording: >>>>>>> >>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>> It should be "AssumeMP". >>>>>>>> >>>>>>>> /Yumin >>>>>>>> >>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>> recommend >>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>> avoid >>>>>>>>> running with only one GC thread. This is verified by Oleksandr >>>>>>>>> with >>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>> >>>>>>>>> Same link. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>> >>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>>> runtime. >>>>>>>>>> >>>>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>>>> others offline to run java application, after java program >>>>>>>>>> started, >>>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>>>> will >>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>> various >>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>> supply a >>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>> called. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From john.cuthbertson at oracle.com Tue Mar 26 17:31:56 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 26 Mar 2013 10:31:56 -0700 Subject: RFR (S) 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine In-Reply-To: <514B344F.9080307@oracle.com> References: <514B344F.9080307@oracle.com> Message-ID: <5151DB8C.9000907@oracle.com> Hi Mikael, The changes look good to me. Ship it. JohnC On 3/21/2013 9:24 AM, Mikael Gerdin wrote: > Hi > > Please review the following change: > > When running a stress test that is repeatedly blocking GC from > triggering through the normal path we may get stuck in the allocation > path and stay in the allocation loop forever. > > In this case the problem seems to be that if some threads are > repeatedly entering and leaving JNI critical regions and thereby > stressing the GC_Locker an allocating thread may get stuck in the > allocation loop and never realize that the pending allocation is > impossible due to heap usage. > > My suggested fix is to limit the amount of times we try to start GCs > and then simply give up and return NULL and fail the allocation, > thereby causing the caller to throw an OOME. > > Note that every time the counter is incremented because we return from > GC_Locker::stall_until_clear() the thread unlocking the GC_Locker has > actually triggered a GC. So we're not giving up without a fight. > > Public bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014552 > JIRA: https://jbs.oracle.com/bugs/browse/JDK-7014552 > Webrev: http://cr.openjdk.java.net/~mgerdin/7014552/webrev.0/ > > Thanks > /Mikael From yumin.qi at oracle.com Tue Mar 26 19:17:19 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 26 Mar 2013 12:17:19 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151B8C8.7060802@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> Message-ID: <5151F43F.7000102@oracle.com> Hi, Jon I made a change to the warning condition and move it after GC flags are set. I think at this time, ParallelGCThreads has a value != 0. Please take a look if it is right. The This is the new webrev: http://javaweb.us.oracle.com/~yqi/webrev/2178143/ Tested with platform of ncpus > 1 and no ParallelGCThreads set with turning on AssumeMP. The warning is gone. Also tested with ncpus = 1 and the warning is on too. Thanks Yumin On 3/26/2013 8:03 AM, Jon Masamitsu wrote: > If I set AssumeMP on the command line and nothing else > and am running on a platform where I get ParallelGCThreads > 1, > am I going to see the warning? If yes, that seems too intrusive. > I can see users hearing about the flag and deciding to include > it always just to be safe. > > Jon > > On 3/25/13 11:21 PM, Yumin Qi wrote: >> You are right, thanks! I misread the INCLUDE. >> new web in the same link. >> >> Thanks >> Yumin >> >> On 3/25/2013 11:00 PM, David Holmes wrote: >>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>> David, >>>> >>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>> David and All, >>>>>> >>>>>> Changed as suggested by David. >>>>>> >>>>>> David, I did not move the warning into set_parallel_gc_flags() since >>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>> moved it >>>>>> into >>>>>> #if INCLUDE_ALL_GCS >>>>>> >>>>>> before call set GC flags. >>>>> >>>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>>> Can we at least exclude it for serial GC case? >>>>> >>>> >>>> Serial GC is set here: >>> >>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>> only have SerialGC. So you have excluded it for the case where >>> SerialGC is the only GC built into the VM, but not for the case >>> where all GCs are available and the user requests UseSerialGC. >>> >>> David >>> ----- >>> >>> >>>> 3253 #if !INCLUDE_ALL_GCS >>>> 3254 force_serial_gc(); >>>> 3255 #endif // INCLUDE_ALL_GCS >>>> >>>> So after it moved into >>>> 3283 #if INCLUDE_ALL_GCS >>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>> 3285 warning("If the number of processors is expected to increase >>>> from one, then" >>>> 3286 " you should configure the number of parallel GC >>>> threads appropriately" >>>> 3287 " using -XX:ParallelGCThreads=N"); >>>> 3288 } >>>> 3289 // Set per-collector flags >>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>> 3291 set_parallel_gc_flags(); >>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>> ParNew >>>> check below >>>> 3293 set_cms_and_parnew_gc_flags(); >>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>> 3295 set_parnew_gc_flags(); >>>> 3296 } else if (UseG1GC) { >>>> 3297 set_g1_gc_flags(); >>>> 3298 } >>>> 3299 check_deprecated_gcs(); >>>> 3300 #else // INCLUDE_ALL_GCS >>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>> 3302 #endif // INCLUDE_ALL_GCS >>>> >>>> It is excluded for serial GC. >>>> >>>> Thanks >>>> Yumin >>>> >>>>> Otherwise looks good. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> I have a few suggested changes. >>>>>>> >>>>>>> First in os.hpp I suggest >>>>>>> >>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>> >>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>> unnecessary >>>>>>> overhead on the common path. >>>>>>> >>>>>>> In arguments.cpp: >>>>>>> >>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>> + warning("With AssumeMP, recommend run with >>>>>>> -XX:ParallelGCThreads=, where" >>>>>>> + " num_of_gc_threads can be set to number of cores"); >>>>>>> + } >>>>>>> >>>>>>> I'm not convinced issuing a warning is necessary or desirable here. >>>>>>> With a uniprocessor startup will we even default to using >>>>>>> parallel GC? >>>>>>> The above should only be issued if using parallel GC - so better to >>>>>>> move it into set_parallel_gc_flags(). >>>>>>> >>>>>>> In any case it isn't clear what the user should supply here. If >>>>>>> they >>>>>>> use the maximum expected number of cores initially then while they >>>>>>> only have 1 core their VM may not even function adequately due >>>>>>> to GC >>>>>>> overhead. I think all you can say here is something like: >>>>>>> >>>>>>> warning("If the number of processors is expected to increase >>>>>>> from one, >>>>>>> then you should configure the number of parallel GC threads >>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>> >>>>>>> >>>>>>> In globals.hpp: >>>>>>> >>>>>>> + product(bool, AssumeMP, false, \ >>>>>>> + "Assume run on multiple processors always") \ >>>>>>> >>>>>>> Was there any discussion on making this default to true instead? >>>>>>> >>>>>>> Suggested re-wording: >>>>>>> >>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>> It should be "AssumeMP". >>>>>>>> >>>>>>>> /Yumin >>>>>>>> >>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>> recommend >>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>> avoid >>>>>>>>> running with only one GC thread. This is verified by Oleksandr >>>>>>>>> with >>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>> >>>>>>>>> Same link. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>> >>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>>> runtime. >>>>>>>>>> >>>>>>>>>> Situation: Customer first configure only one CPU online and turn >>>>>>>>>> others offline to run java application, after java program >>>>>>>>>> started, >>>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>>> os::is_MP() will return false, but after more CPUs available, OS >>>>>>>>>> will >>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>> various >>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>> supply a >>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>> called. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From mikael.gerdin at oracle.com Tue Mar 26 19:34:02 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Mar 2013 20:34:02 +0100 Subject: RFR (S) 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine In-Reply-To: <5151DB8C.9000907@oracle.com> References: <514B344F.9080307@oracle.com> <5151DB8C.9000907@oracle.com> Message-ID: <5151F82A.4000304@oracle.com> Thanks Bengt, Erik and John for the reviews. I'll go ahead and push this tomorrow. /Mikael On 2013-03-26 18:31, John Cuthbertson wrote: > Hi Mikael, > > The changes look good to me. Ship it. > > JohnC > > On 3/21/2013 9:24 AM, Mikael Gerdin wrote: >> Hi >> >> Please review the following change: >> >> When running a stress test that is repeatedly blocking GC from >> triggering through the normal path we may get stuck in the allocation >> path and stay in the allocation loop forever. >> >> In this case the problem seems to be that if some threads are >> repeatedly entering and leaving JNI critical regions and thereby >> stressing the GC_Locker an allocating thread may get stuck in the >> allocation loop and never realize that the pending allocation is >> impossible due to heap usage. >> >> My suggested fix is to limit the amount of times we try to start GCs >> and then simply give up and return NULL and fail the allocation, >> thereby causing the caller to throw an OOME. >> >> Note that every time the counter is incremented because we return from >> GC_Locker::stall_until_clear() the thread unlocking the GC_Locker has >> actually triggered a GC. So we're not giving up without a fight. >> >> Public bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014552 >> JIRA: https://jbs.oracle.com/bugs/browse/JDK-7014552 >> Webrev: http://cr.openjdk.java.net/~mgerdin/7014552/webrev.0/ >> >> Thanks >> /Mikael > From daniel.daugherty at oracle.com Tue Mar 26 19:42:13 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Mar 2013 13:42:13 -0600 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151F43F.7000102@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> Message-ID: <5151FA15.1000104@oracle.com> On 3/26/13 1:17 PM, Yumin Qi wrote: > Hi, Jon > > I made a change to the warning condition and move it after GC flags > are set. I think at this time, ParallelGCThreads has a value != 0. > Please take a look if it is right. The This is the new webrev: > > http://javaweb.us.oracle.com/~yqi/webrev/2178143/ This webrev isn't accessible outside Oracle... Dan > > Tested with platform of ncpus > 1 and no ParallelGCThreads set with > turning on AssumeMP. The warning is gone. > Also tested with ncpus = 1 and the warning is on too. > > Thanks > Yumin > > On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >> If I set AssumeMP on the command line and nothing else >> and am running on a platform where I get ParallelGCThreads > 1, >> am I going to see the warning? If yes, that seems too intrusive. >> I can see users hearing about the flag and deciding to include >> it always just to be safe. >> >> Jon >> >> On 3/25/13 11:21 PM, Yumin Qi wrote: >>> You are right, thanks! I misread the INCLUDE. >>> new web in the same link. >>> >>> Thanks >>> Yumin >>> >>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>> David, >>>>> >>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>> David and All, >>>>>>> >>>>>>> Changed as suggested by David. >>>>>>> >>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>> since >>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>> moved it >>>>>>> into >>>>>>> #if INCLUDE_ALL_GCS >>>>>>> >>>>>>> before call set GC flags. >>>>>> >>>>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>>>> Can we at least exclude it for serial GC case? >>>>>> >>>>> >>>>> Serial GC is set here: >>>> >>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>> only have SerialGC. So you have excluded it for the case where >>>> SerialGC is the only GC built into the VM, but not for the case >>>> where all GCs are available and the user requests UseSerialGC. >>>> >>>> David >>>> ----- >>>> >>>> >>>>> 3253 #if !INCLUDE_ALL_GCS >>>>> 3254 force_serial_gc(); >>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>> >>>>> So after it moved into >>>>> 3283 #if INCLUDE_ALL_GCS >>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>> 3285 warning("If the number of processors is expected to increase >>>>> from one, then" >>>>> 3286 " you should configure the number of parallel GC >>>>> threads appropriately" >>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>> 3288 } >>>>> 3289 // Set per-collector flags >>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>> 3291 set_parallel_gc_flags(); >>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>> ParNew >>>>> check below >>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>> 3295 set_parnew_gc_flags(); >>>>> 3296 } else if (UseG1GC) { >>>>> 3297 set_g1_gc_flags(); >>>>> 3298 } >>>>> 3299 check_deprecated_gcs(); >>>>> 3300 #else // INCLUDE_ALL_GCS >>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>> >>>>> It is excluded for serial GC. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>>> Otherwise looks good. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>> Hi Yumin, >>>>>>>> >>>>>>>> I have a few suggested changes. >>>>>>>> >>>>>>>> First in os.hpp I suggest >>>>>>>> >>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>> >>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>> unnecessary >>>>>>>> overhead on the common path. >>>>>>>> >>>>>>>> In arguments.cpp: >>>>>>>> >>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>> cores"); >>>>>>>> + } >>>>>>>> >>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>> here. >>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>> parallel GC? >>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>> better to >>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>> >>>>>>>> In any case it isn't clear what the user should supply here. If >>>>>>>> they >>>>>>>> use the maximum expected number of cores initially then while they >>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>> to GC >>>>>>>> overhead. I think all you can say here is something like: >>>>>>>> >>>>>>>> warning("If the number of processors is expected to increase >>>>>>>> from one, >>>>>>>> then you should configure the number of parallel GC threads >>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>> >>>>>>>> >>>>>>>> In globals.hpp: >>>>>>>> >>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>> >>>>>>>> Was there any discussion on making this default to true instead? >>>>>>>> >>>>>>>> Suggested re-wording: >>>>>>>> >>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>> It should be "AssumeMP". >>>>>>>>> >>>>>>>>> /Yumin >>>>>>>>> >>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>> recommend >>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>> avoid >>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>> Oleksandr with >>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>> >>>>>>>>>> Same link. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>> >>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed during >>>>>>>>>>> runtime. >>>>>>>>>>> >>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>> turn >>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>> started, >>>>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>> available, OS >>>>>>>>>>> will >>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>> various >>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>> supply a >>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>> called. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From yumin.qi at oracle.com Tue Mar 26 19:44:35 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 26 Mar 2013 12:44:35 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151FA15.1000104@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> Message-ID: <5151FAA3.8090402@oracle.com> Sorry, copied wrong link. It is at same link. http://cr.openjdk.java.net/~minqi/2178143/ Thanks Yumin On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: > > On 3/26/13 1:17 PM, Yumin Qi wrote: >> Hi, Jon >> >> I made a change to the warning condition and move it after GC flags >> are set. I think at this time, ParallelGCThreads has a value != 0. >> Please take a look if it is right. The This is the new webrev: >> >> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ > > This webrev isn't accessible outside Oracle... > > Dan > > >> >> Tested with platform of ncpus > 1 and no ParallelGCThreads set with >> turning on AssumeMP. The warning is gone. >> Also tested with ncpus = 1 and the warning is on too. >> >> Thanks >> Yumin >> >> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>> If I set AssumeMP on the command line and nothing else >>> and am running on a platform where I get ParallelGCThreads > 1, >>> am I going to see the warning? If yes, that seems too intrusive. >>> I can see users hearing about the flag and deciding to include >>> it always just to be safe. >>> >>> Jon >>> >>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>> You are right, thanks! I misread the INCLUDE. >>>> new web in the same link. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>> David, >>>>>> >>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>> David and All, >>>>>>>> >>>>>>>> Changed as suggested by David. >>>>>>>> >>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>> since >>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>> moved it >>>>>>>> into >>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> before call set GC flags. >>>>>>> >>>>>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>>>>> Can we at least exclude it for serial GC case? >>>>>>> >>>>>> >>>>>> Serial GC is set here: >>>>> >>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>> only have SerialGC. So you have excluded it for the case where >>>>> SerialGC is the only GC built into the VM, but not for the case >>>>> where all GCs are available and the user requests UseSerialGC. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>> 3254 force_serial_gc(); >>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>> >>>>>> So after it moved into >>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>> 3285 warning("If the number of processors is expected to >>>>>> increase >>>>>> from one, then" >>>>>> 3286 " you should configure the number of parallel GC >>>>>> threads appropriately" >>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>> 3288 } >>>>>> 3289 // Set per-collector flags >>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>> 3291 set_parallel_gc_flags(); >>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>> ParNew >>>>>> check below >>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>> 3295 set_parnew_gc_flags(); >>>>>> 3296 } else if (UseG1GC) { >>>>>> 3297 set_g1_gc_flags(); >>>>>> 3298 } >>>>>> 3299 check_deprecated_gcs(); >>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>> >>>>>> It is excluded for serial GC. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>>> Otherwise looks good. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>> Hi Yumin, >>>>>>>>> >>>>>>>>> I have a few suggested changes. >>>>>>>>> >>>>>>>>> First in os.hpp I suggest >>>>>>>>> >>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>> >>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>> unnecessary >>>>>>>>> overhead on the common path. >>>>>>>>> >>>>>>>>> In arguments.cpp: >>>>>>>>> >>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>> cores"); >>>>>>>>> + } >>>>>>>>> >>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>> here. >>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>> parallel GC? >>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>> better to >>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>> >>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>> If they >>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>> they >>>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>>> to GC >>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>> >>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>> from one, >>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>> >>>>>>>>> >>>>>>>>> In globals.hpp: >>>>>>>>> >>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>> >>>>>>>>> Was there any discussion on making this default to true instead? >>>>>>>>> >>>>>>>>> Suggested re-wording: >>>>>>>>> >>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>> It should be "AssumeMP". >>>>>>>>>> >>>>>>>>>> /Yumin >>>>>>>>>> >>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>> recommend >>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>>> avoid >>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>> Oleksandr with >>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>> >>>>>>>>>>> Same link. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>> during >>>>>>>>>>>> runtime. >>>>>>>>>>>> >>>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>>> turn >>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>> started, >>>>>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>> available, OS >>>>>>>>>>>> will >>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>> various >>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>> supply a >>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>>> called. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Tue Mar 26 21:16:40 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 26 Mar 2013 14:16:40 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151FAA3.8090402@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> Message-ID: <51521038.7010805@oracle.com> Yumin, Looks good. Thanks. Jon On 03/26/13 12:44, Yumin Qi wrote: > Sorry, copied wrong link. It is at same link. > > http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin > > On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >> >> On 3/26/13 1:17 PM, Yumin Qi wrote: >>> Hi, Jon >>> >>> I made a change to the warning condition and move it after GC >>> flags are set. I think at this time, ParallelGCThreads has a value >>> != 0. Please take a look if it is right. The This is the new webrev: >>> >>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >> >> This webrev isn't accessible outside Oracle... >> >> Dan >> >> >>> >>> Tested with platform of ncpus > 1 and no ParallelGCThreads set >>> with turning on AssumeMP. The warning is gone. >>> Also tested with ncpus = 1 and the warning is on too. >>> >>> Thanks >>> Yumin >>> >>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>> If I set AssumeMP on the command line and nothing else >>>> and am running on a platform where I get ParallelGCThreads > 1, >>>> am I going to see the warning? If yes, that seems too intrusive. >>>> I can see users hearing about the flag and deciding to include >>>> it always just to be safe. >>>> >>>> Jon >>>> >>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>> You are right, thanks! I misread the INCLUDE. >>>>> new web in the same link. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>> David, >>>>>>> >>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>> David and All, >>>>>>>>> >>>>>>>>> Changed as suggested by David. >>>>>>>>> >>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>> since >>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>> moved it >>>>>>>>> into >>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>> >>>>>>>>> before call set GC flags. >>>>>>>> >>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>> ParallelGCThreads. >>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>> >>>>>>> >>>>>>> Serial GC is set here: >>>>>> >>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>> only have SerialGC. So you have excluded it for the case where >>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>> 3254 force_serial_gc(); >>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>> >>>>>>> So after it moved into >>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>> 3285 warning("If the number of processors is expected to >>>>>>> increase >>>>>>> from one, then" >>>>>>> 3286 " you should configure the number of parallel GC >>>>>>> threads appropriately" >>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>> 3288 } >>>>>>> 3289 // Set per-collector flags >>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>> 3291 set_parallel_gc_flags(); >>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>> ParNew >>>>>>> check below >>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>> 3295 set_parnew_gc_flags(); >>>>>>> 3296 } else if (UseG1GC) { >>>>>>> 3297 set_g1_gc_flags(); >>>>>>> 3298 } >>>>>>> 3299 check_deprecated_gcs(); >>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>> >>>>>>> It is excluded for serial GC. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>>> Otherwise looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>> Hi Yumin, >>>>>>>>>> >>>>>>>>>> I have a few suggested changes. >>>>>>>>>> >>>>>>>>>> First in os.hpp I suggest >>>>>>>>>> >>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>> >>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>> unnecessary >>>>>>>>>> overhead on the common path. >>>>>>>>>> >>>>>>>>>> In arguments.cpp: >>>>>>>>>> >>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>> cores"); >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>> here. >>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>> parallel GC? >>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>> better to >>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>> >>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>> If they >>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>> they >>>>>>>>>> only have 1 core their VM may not even function adequately >>>>>>>>>> due to GC >>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>> >>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>> from one, >>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In globals.hpp: >>>>>>>>>> >>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>> >>>>>>>>>> Was there any discussion on making this default to true instead? >>>>>>>>>> >>>>>>>>>> Suggested re-wording: >>>>>>>>>> >>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>> >>>>>>>>>>> /Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>> recommend >>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user >>>>>>>>>>>> to avoid >>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>> Oleksandr with >>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>> >>>>>>>>>>>> Same link. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>> during >>>>>>>>>>>>> runtime. >>>>>>>>>>>>> >>>>>>>>>>>>> Situation: Customer first configure only one CPU online >>>>>>>>>>>>> and turn >>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>> started, >>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>> CPU, >>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>> available, OS >>>>>>>>>>>>> will >>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>> various >>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>> supply a >>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to >>>>>>>>>>>>> be called. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From yumin.qi at oracle.com Tue Mar 26 21:18:17 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 26 Mar 2013 14:18:17 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51521038.7010805@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51521038.7010805@oracle.com> Message-ID: <51521099.6010306@oracle.com> Thanks Jon. Yumin On 3/26/2013 2:16 PM, Jon Masamitsu wrote: > Yumin, > > Looks good. Thanks. > > Jon > > On 03/26/13 12:44, Yumin Qi wrote: >> Sorry, copied wrong link. It is at same link. >> >> http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin >> >> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>> >>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>> Hi, Jon >>>> >>>> I made a change to the warning condition and move it after GC >>>> flags are set. I think at this time, ParallelGCThreads has a value >>>> != 0. Please take a look if it is right. The This is the new webrev: >>>> >>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>> >>> This webrev isn't accessible outside Oracle... >>> >>> Dan >>> >>> >>>> >>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set >>>> with turning on AssumeMP. The warning is gone. >>>> Also tested with ncpus = 1 and the warning is on too. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>> If I set AssumeMP on the command line and nothing else >>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>> am I going to see the warning? If yes, that seems too intrusive. >>>>> I can see users hearing about the flag and deciding to include >>>>> it always just to be safe. >>>>> >>>>> Jon >>>>> >>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>> You are right, thanks! I misread the INCLUDE. >>>>>> new web in the same link. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>> David and All, >>>>>>>>>> >>>>>>>>>> Changed as suggested by David. >>>>>>>>>> >>>>>>>>>> David, I did not move the warning into >>>>>>>>>> set_parallel_gc_flags() since >>>>>>>>>> except for serial gc, all other GCs will check this flag, so >>>>>>>>>> I moved it >>>>>>>>>> into >>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>> >>>>>>>>>> before call set GC flags. >>>>>>>>> >>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>> ParallelGCThreads. >>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>> >>>>>>>> >>>>>>>> Serial GC is set here: >>>>>>> >>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>> 3254 force_serial_gc(); >>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> So after it moved into >>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>> increase >>>>>>>> from one, then" >>>>>>>> 3286 " you should configure the number of parallel GC >>>>>>>> threads appropriately" >>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>> 3288 } >>>>>>>> 3289 // Set per-collector flags >>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>> before ParNew >>>>>>>> check below >>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>> 3298 } >>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> It is excluded for serial GC. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>>> Otherwise looks good. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>> Hi Yumin, >>>>>>>>>>> >>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>> >>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>> >>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>> >>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>> unnecessary >>>>>>>>>>> overhead on the common path. >>>>>>>>>>> >>>>>>>>>>> In arguments.cpp: >>>>>>>>>>> >>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>> cores"); >>>>>>>>>>> + } >>>>>>>>>>> >>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>> desirable here. >>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>> parallel GC? >>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>> better to >>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>> >>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>> If they >>>>>>>>>>> use the maximum expected number of cores initially then >>>>>>>>>>> while they >>>>>>>>>>> only have 1 core their VM may not even function adequately >>>>>>>>>>> due to GC >>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>> >>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>> from one, >>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In globals.hpp: >>>>>>>>>>> >>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>> >>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>> instead? >>>>>>>>>>> >>>>>>>>>>> Suggested re-wording: >>>>>>>>>>> >>>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>> >>>>>>>>>>>> /Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>>> recommend >>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user >>>>>>>>>>>>> to avoid >>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>>> >>>>>>>>>>>>> Same link. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>> during >>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Situation: Customer first configure only one CPU online >>>>>>>>>>>>>> and turn >>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>> program started, >>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>> will >>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV >>>>>>>>>>>>>> in various >>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>> supply a >>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to >>>>>>>>>>>>>> be called. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From tao.mao at oracle.com Tue Mar 26 22:18:01 2013 From: tao.mao at oracle.com (Tao Mao) Date: Tue, 26 Mar 2013 15:18:01 -0700 (PDT) Subject: RFR (S): 7112912:Message "Error occurred during initialization of VM" on boxes with lots of RAM In-Reply-To: <1364232505.2703.47.camel@cirrus> References: <1363180662.2535.79.camel@cirrus> <5140D048.6030600@oracle.com> <1363291903.2489.24.camel@cirrus> <1363593549.2603.1.camel@cirrus> <514B8CC7.7060607@oracle.com> <1363934518.2463.48.camel@cirrus> <514CCC0C.4030403@oracle.com> <1364232505.2703.47.camel@cirrus> Message-ID: <51521E99.5060101@oracle.com> Looks good. Ship it~ Tao On 3/25/13 10:28 AM, Thomas Schatzl wrote: > Hi Jon, > > On Fri, 2013-03-22 at 14:24 -0700, Jon Masamitsu wrote: >> Thomas, >> >> Thanks for the extra effort. A comment not about correctness >> but more for readability. >> >>> + if (is_allocatable(upper_limit)) { >>> + *limit = upper_limit; >>> + } else if (upper_limit< min_allocation_size) { >>> + *limit = upper_limit; >>> + } else if (!is_allocatable(min_allocation_size)) { >>> + // we found that not even min_allocation_size is allocatable. Return it >>> + // anyway. There is no point to search for a better value any more. >>> + *limit = min_allocation_size; >> In the first "else if" if you changed it to (upper_limit<= >> min_allocation_size) >> can you eliminate the second "else if" like this >> >> + if (is_allocatable(upper_limit)) { >> + *limit = upper_limit; >> + } else if (upper_limit<= min_allocation_size) { >> + *limit = upper_limit; >> >> And it might read more easily as >> >> + if (is_allocatable(upper_limit) || >> +upper_limit<= min_allocation_size) { >> + *limit = upper_limit; > a new webrev with your suggested change is available at > > http://cr.openjdk.java.net/~tschatzl/7112912/webrev.2/ > > Again, the change passed jprt. > > Hth, > Thomas > > From jesper.wilhelmsson at oracle.com Tue Mar 26 22:40:29 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 26 Mar 2013 23:40:29 +0100 Subject: Can remapping/unmapping virtual memory make Java Garbage Collection go faster? In-Reply-To: References: Message-ID: <515223DD.6080509@oracle.com> Hi Anjul, Similar things have been done before. The example I come to think about right now is the mapping collector [1], but I know there have been other work on this as well. /Jesper [1] http://dl.acm.org/citation.cfm?id=1346281.1346294&coll=DL&dl=GUIDE&CFID=197206966&CFTOKEN=64021895 Anjul skrev 26/3/13 6:35 AM: > Garbage collectors move data to eliminate holes in virtual memory both to make > new allocations faster and to make it feasible to allocate large contiguous chunks. > > In modern 64-bit OSes two significant optimization possibilities seem to arise. > One is to simply not do compaction. Instead, unmap pages that contain no live > objects and keep allocating new objects to further and further areas of virtual > memory by mapping pages in. On a 64-bit system this could be pretty sustainable. > The other possibility is that if a large object does need to be compacted/moved > to a different virtual address, then the pages that contain it could simply be > remapped to a different area of virtual memory without copying any data. > > There would be extra work, relative to copying, for reorganizing the page > tables, but I think that might be logarithmically smaller. > > This seems to ensure that there is no hole larger than a page. Sparsely occupied > pages could be copied as usual or with some bookkeeping used for allocating > small objects. > > Is there a problem in this scheme? Are there any JVMs out there that do this or > are shortly expected to do so? > From todd at cloudera.com Tue Mar 26 22:51:39 2013 From: todd at cloudera.com (Todd Lipcon) Date: Tue, 26 Mar 2013 15:51:39 -0700 Subject: Can remapping/unmapping virtual memory make Java Garbage Collection go faster? In-Reply-To: <515223DD.6080509@oracle.com> References: <515223DD.6080509@oracle.com> Message-ID: The Azul concurrent collector also makes heavy use of virtual memory tricks. The downside of implementing these methods is typically that mucking with VM mappings can be very inefficient: there's a process-wide lock involved, and it also causes TLB shootdowns to invalidate prior mappings. So, doing it fine grained costs a lot, and you need to be relatively clever to get good performance. (Azul uses a kernel module with bulk remap operations and the ability to multiply map physical memory to multiple virtual locations at the same time). I highly recommend reading the paper, though: http://dl.acm.org/citation.cfm?id=1993491&dl=ACM&coll=DL&CFID=197266941&CFTOKEN=89353319 -Todd On Tue, Mar 26, 2013 at 3:40 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Hi Anjul, > > Similar things have been done before. The example I come to think about > right now is the mapping collector [1], but I know there have been other > work on this as well. > /Jesper > > [1] http://dl.acm.org/citation.**cfm?id=1346281.1346294&coll=** > DL&dl=GUIDE&CFID=197206966&**CFTOKEN=64021895 > > > > Anjul skrev 26/3/13 6:35 AM: > > Garbage collectors move data to eliminate holes in virtual memory both to >> make >> new allocations faster and to make it feasible to allocate large >> contiguous chunks. >> >> In modern 64-bit OSes two significant optimization possibilities seem to >> arise. >> One is to simply not do compaction. Instead, unmap pages that contain no >> live >> objects and keep allocating new objects to further and further areas of >> virtual >> memory by mapping pages in. On a 64-bit system this could be pretty >> sustainable. >> The other possibility is that if a large object does need to be >> compacted/moved >> to a different virtual address, then the pages that contain it could >> simply be >> remapped to a different area of virtual memory without copying any data. >> >> There would be extra work, relative to copying, for reorganizing the page >> tables, but I think that might be logarithmically smaller. >> >> This seems to ensure that there is no hole larger than a page. Sparsely >> occupied >> pages could be copied as usual or with some bookkeeping used for >> allocating >> small objects. >> >> Is there a problem in this scheme? Are there any JVMs out there that do >> this or >> are shortly expected to do so? >> >> -- Todd Lipcon Software Engineer, Cloudera -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Mar 26 23:26:24 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 27 Mar 2013 10:26:24 +1100 Subject: Can remapping/unmapping virtual memory make Java Garbage Collection go faster? In-Reply-To: References: <515223DD.6080509@oracle.com> Message-ID: <9BEB6EAB-4006-4E0A-8652-D3F9C2EDA3B1@cs.purdue.edu> Indeed. Compressor also does similar tricks. Both the Azul concurrent collector and Compressor are described in our recent book: "The Garbage Collection Handbook", coauthored with Richard Jones and Eliot Moss. Both the papers referred to below are also definitely worth a read. Plus more on Pauseless and Zing at http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Mar 27, 2013, at 9:51 AM, Todd Lipcon wrote: > The Azul concurrent collector also makes heavy use of virtual memory tricks. > > The downside of implementing these methods is typically that mucking with VM mappings can be very inefficient: there's a process-wide lock involved, and it also causes TLB shootdowns to invalidate prior mappings. So, doing it fine grained costs a lot, and you need to be relatively clever to get good performance. (Azul uses a kernel module with bulk remap operations and the ability to multiply map physical memory to multiple virtual locations at the same time). > > I highly recommend reading the paper, though: http://dl.acm.org/citation.cfm?id=1993491&dl=ACM&coll=DL&CFID=197266941&CFTOKEN=89353319 > > -Todd > > On Tue, Mar 26, 2013 at 3:40 PM, Jesper Wilhelmsson wrote: > Hi Anjul, > > Similar things have been done before. The example I come to think about right now is the mapping collector [1], but I know there have been other work on this as well. > /Jesper > > [1] http://dl.acm.org/citation.cfm?id=1346281.1346294&coll=DL&dl=GUIDE&CFID=197206966&CFTOKEN=64021895 > > > > Anjul skrev 26/3/13 6:35 AM: > > Garbage collectors move data to eliminate holes in virtual memory both to make > new allocations faster and to make it feasible to allocate large contiguous chunks. > > In modern 64-bit OSes two significant optimization possibilities seem to arise. > One is to simply not do compaction. Instead, unmap pages that contain no live > objects and keep allocating new objects to further and further areas of virtual > memory by mapping pages in. On a 64-bit system this could be pretty sustainable. > The other possibility is that if a large object does need to be compacted/moved > to a different virtual address, then the pages that contain it could simply be > remapped to a different area of virtual memory without copying any data. > > There would be extra work, relative to copying, for reorganizing the page > tables, but I think that might be logarithmically smaller. > > This seems to ensure that there is no hole larger than a page. Sparsely occupied > pages could be copied as usual or with some bookkeeping used for allocating > small objects. > > Is there a problem in this scheme? Are there any JVMs out there that do this or > are shortly expected to do so? > > > > > -- > Todd Lipcon > Software Engineer, Cloudera -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Mar 27 02:49:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2013 12:49:33 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5151FAA3.8090402@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> Message-ID: <51525E3D.6080600@oracle.com> Well now you have confused me. I thought checking FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user has not attempted manage the number of GC threads even though they recognize the number of processors may start at 1 and increase later). I do not understand the new <2 test - maybe I really only want 1, if I asked for that why should I get a warning ??? But, this is a GC warning (and I think it is misplaced anyway) so if Jon is happy with this behaviour so be it. Cheers, David On 27/03/2013 5:44 AM, Yumin Qi wrote: > Sorry, copied wrong link. It is at same link. > > http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin > > On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >> >> On 3/26/13 1:17 PM, Yumin Qi wrote: >>> Hi, Jon >>> >>> I made a change to the warning condition and move it after GC flags >>> are set. I think at this time, ParallelGCThreads has a value != 0. >>> Please take a look if it is right. The This is the new webrev: >>> >>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >> >> This webrev isn't accessible outside Oracle... >> >> Dan >> >> >>> >>> Tested with platform of ncpus > 1 and no ParallelGCThreads set with >>> turning on AssumeMP. The warning is gone. >>> Also tested with ncpus = 1 and the warning is on too. >>> >>> Thanks >>> Yumin >>> >>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>> If I set AssumeMP on the command line and nothing else >>>> and am running on a platform where I get ParallelGCThreads > 1, >>>> am I going to see the warning? If yes, that seems too intrusive. >>>> I can see users hearing about the flag and deciding to include >>>> it always just to be safe. >>>> >>>> Jon >>>> >>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>> You are right, thanks! I misread the INCLUDE. >>>>> new web in the same link. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>> David, >>>>>>> >>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>> David and All, >>>>>>>>> >>>>>>>>> Changed as suggested by David. >>>>>>>>> >>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>> since >>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>> moved it >>>>>>>>> into >>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>> >>>>>>>>> before call set GC flags. >>>>>>>> >>>>>>>> I didn't realize all the other GCs would utilize ParallelGCThreads. >>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>> >>>>>>> >>>>>>> Serial GC is set here: >>>>>> >>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>> only have SerialGC. So you have excluded it for the case where >>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>> 3254 force_serial_gc(); >>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>> >>>>>>> So after it moved into >>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>> 3285 warning("If the number of processors is expected to >>>>>>> increase >>>>>>> from one, then" >>>>>>> 3286 " you should configure the number of parallel GC >>>>>>> threads appropriately" >>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>> 3288 } >>>>>>> 3289 // Set per-collector flags >>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>> 3291 set_parallel_gc_flags(); >>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>> ParNew >>>>>>> check below >>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>> 3295 set_parnew_gc_flags(); >>>>>>> 3296 } else if (UseG1GC) { >>>>>>> 3297 set_g1_gc_flags(); >>>>>>> 3298 } >>>>>>> 3299 check_deprecated_gcs(); >>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>> >>>>>>> It is excluded for serial GC. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>>> Otherwise looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>> Hi Yumin, >>>>>>>>>> >>>>>>>>>> I have a few suggested changes. >>>>>>>>>> >>>>>>>>>> First in os.hpp I suggest >>>>>>>>>> >>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>> >>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>> unnecessary >>>>>>>>>> overhead on the common path. >>>>>>>>>> >>>>>>>>>> In arguments.cpp: >>>>>>>>>> >>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>> cores"); >>>>>>>>>> + } >>>>>>>>>> >>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>> here. >>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>> parallel GC? >>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>> better to >>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>> >>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>> If they >>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>> they >>>>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>>>> to GC >>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>> >>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>> from one, >>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In globals.hpp: >>>>>>>>>> >>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>> >>>>>>>>>> Was there any discussion on making this default to true instead? >>>>>>>>>> >>>>>>>>>> Suggested re-wording: >>>>>>>>>> >>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>> >>>>>>>>>>> /Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>> recommend >>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>>>> avoid >>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>> Oleksandr with >>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>> >>>>>>>>>>>> Same link. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>> during >>>>>>>>>>>>> runtime. >>>>>>>>>>>>> >>>>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>>>> turn >>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>> started, >>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single CPU, >>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>> available, OS >>>>>>>>>>>>> will >>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>> various >>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>> supply a >>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>>>> called. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From yumin.qi at oracle.com Wed Mar 27 04:06:35 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 26 Mar 2013 21:06:35 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51525E3D.6080600@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> Message-ID: <5152704B.9090302@oracle.com> David, On 3/26/2013 7:49 PM, David Holmes wrote: > Well now you have confused me. I thought checking > FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user > has not attempted manage the number of GC threads even though they > recognize the number of processors may start at 1 and increase later). > I do not understand the new <2 test - maybe I really only want 1, if I > asked for that why should I get a warning ??? > The previous code is issuing the warning before gc set flags (includes ParallelGCThreads), we don't want with AssumeMP turned on, running on a MP issues the warning since ParallelGCThreads will be not 1 but the number of calculation based on ncpus. So I moved the check code after GC set flags. After GC set flags, ParallelGCThreads is not the default value (0) so I check if it is < 2. If users really want to run with single CPU with -XX:+AssumeMP, giving a warning is reasonable (this is our intention here) --- there is possibility they will increase number of cpus even they don't, that is OK. Thanks Yumin > But, this is a GC warning (and I think it is misplaced anyway) so if > Jon is happy with this behaviour so be it. > > Cheers, > David > > On 27/03/2013 5:44 AM, Yumin Qi wrote: >> Sorry, copied wrong link. It is at same link. >> >> http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin >> >> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>> >>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>> Hi, Jon >>>> >>>> I made a change to the warning condition and move it after GC flags >>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>> Please take a look if it is right. The This is the new webrev: >>>> >>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>> >>> This webrev isn't accessible outside Oracle... >>> >>> Dan >>> >>> >>>> >>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set with >>>> turning on AssumeMP. The warning is gone. >>>> Also tested with ncpus = 1 and the warning is on too. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>> If I set AssumeMP on the command line and nothing else >>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>> am I going to see the warning? If yes, that seems too intrusive. >>>>> I can see users hearing about the flag and deciding to include >>>>> it always just to be safe. >>>>> >>>>> Jon >>>>> >>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>> You are right, thanks! I misread the INCLUDE. >>>>>> new web in the same link. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>> David and All, >>>>>>>>>> >>>>>>>>>> Changed as suggested by David. >>>>>>>>>> >>>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>>> since >>>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>>> moved it >>>>>>>>>> into >>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>> >>>>>>>>>> before call set GC flags. >>>>>>>>> >>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>> ParallelGCThreads. >>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>> >>>>>>>> >>>>>>>> Serial GC is set here: >>>>>>> >>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>> 3254 force_serial_gc(); >>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> So after it moved into >>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>> increase >>>>>>>> from one, then" >>>>>>>> 3286 " you should configure the number of parallel GC >>>>>>>> threads appropriately" >>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>> 3288 } >>>>>>>> 3289 // Set per-collector flags >>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>>> ParNew >>>>>>>> check below >>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>> 3298 } >>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> It is excluded for serial GC. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>>> Otherwise looks good. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>> Hi Yumin, >>>>>>>>>>> >>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>> >>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>> >>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>> >>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>> unnecessary >>>>>>>>>>> overhead on the common path. >>>>>>>>>>> >>>>>>>>>>> In arguments.cpp: >>>>>>>>>>> >>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>> cores"); >>>>>>>>>>> + } >>>>>>>>>>> >>>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>>> here. >>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>> parallel GC? >>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>> better to >>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>> >>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>> If they >>>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>>> they >>>>>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>>>>> to GC >>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>> >>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>> from one, >>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In globals.hpp: >>>>>>>>>>> >>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>> >>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>> instead? >>>>>>>>>>> >>>>>>>>>>> Suggested re-wording: >>>>>>>>>>> >>>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>> >>>>>>>>>>>> /Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>>> recommend >>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>>>>> avoid >>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>>> >>>>>>>>>>>>> Same link. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>> during >>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>>>>> turn >>>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>>> started, >>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>> will >>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>>> various >>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>> supply a >>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>>>>> called. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From jon.masamitsu at oracle.com Wed Mar 27 04:13:47 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 26 Mar 2013 21:13:47 -0700 Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions Message-ID: <515271FB.9090203@oracle.com> Replace the use of a method that calculated the total capacity of the Metaspaces by iterating over all the Metaspaces by maintaining the sum of Metaspace capacities as the Metachunks are allocated to each Metaspace. Also maintain a sum for each Metaspace as the Metachunks are allocated to that Metaspace. Change should_expand() and compute_new_space() to calculate quantities in bytes. Remove calls to methods that calculated totals for "used" and "free" by iterating over the Metaspaces in product mode. In some cases substitute the use of capacity for used. http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/ Thanks. Jon From jon.masamitsu at oracle.com Wed Mar 27 04:19:44 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 26 Mar 2013 21:19:44 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51525E3D.6080600@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> Message-ID: <51527360.9050604@oracle.com> On 3/26/2013 7:49 PM, David Holmes wrote: > Well now you have confused me. I thought checking > FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user > has not attempted manage the number of GC threads even though they > recognize the number of processors may start at 1 and increase later). > I do not understand the new <2 test - maybe I really only want 1, if I > asked for that why should I get a warning ??? > > But, this is a GC warning (and I think it is misplaced anyway) so if > Jon is happy with this behaviour so be it. David, By "misplaced" do you mean that no warning should be issued at all? Jon > > Cheers, > David > > On 27/03/2013 5:44 AM, Yumin Qi wrote: >> Sorry, copied wrong link. It is at same link. >> >> http://cr.openjdk.java.net/~minqi/2178143/ >> >> Thanks >> Yumin >> >> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>> >>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>> Hi, Jon >>>> >>>> I made a change to the warning condition and move it after GC flags >>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>> Please take a look if it is right. The This is the new webrev: >>>> >>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>> >>> This webrev isn't accessible outside Oracle... >>> >>> Dan >>> >>> >>>> >>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set with >>>> turning on AssumeMP. The warning is gone. >>>> Also tested with ncpus = 1 and the warning is on too. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>> If I set AssumeMP on the command line and nothing else >>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>> am I going to see the warning? If yes, that seems too intrusive. >>>>> I can see users hearing about the flag and deciding to include >>>>> it always just to be safe. >>>>> >>>>> Jon >>>>> >>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>> You are right, thanks! I misread the INCLUDE. >>>>>> new web in the same link. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>> David and All, >>>>>>>>>> >>>>>>>>>> Changed as suggested by David. >>>>>>>>>> >>>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>>> since >>>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>>> moved it >>>>>>>>>> into >>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>> >>>>>>>>>> before call set GC flags. >>>>>>>>> >>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>> ParallelGCThreads. >>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>> >>>>>>>> >>>>>>>> Serial GC is set here: >>>>>>> >>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>> 3254 force_serial_gc(); >>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> So after it moved into >>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>> increase >>>>>>>> from one, then" >>>>>>>> 3286 " you should configure the number of parallel GC >>>>>>>> threads appropriately" >>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>> 3288 } >>>>>>>> 3289 // Set per-collector flags >>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>>> ParNew >>>>>>>> check below >>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>> 3298 } >>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>> >>>>>>>> It is excluded for serial GC. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>>> Otherwise looks good. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>> Hi Yumin, >>>>>>>>>>> >>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>> >>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>> >>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>> >>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>> unnecessary >>>>>>>>>>> overhead on the common path. >>>>>>>>>>> >>>>>>>>>>> In arguments.cpp: >>>>>>>>>>> >>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>> cores"); >>>>>>>>>>> + } >>>>>>>>>>> >>>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>>> here. >>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>> parallel GC? >>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>> better to >>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>> >>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>> If they >>>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>>> they >>>>>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>>>>> to GC >>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>> >>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>> from one, >>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In globals.hpp: >>>>>>>>>>> >>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>> >>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>> instead? >>>>>>>>>>> >>>>>>>>>>> Suggested re-wording: >>>>>>>>>>> >>>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>> >>>>>>>>>>>> /Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>>> recommend >>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>>>>> avoid >>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>>> >>>>>>>>>>>>> Same link. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>> during >>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>>>>> turn >>>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>>> started, >>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>> will >>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>>> various >>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>> supply a >>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>>>>> called. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Wed Mar 27 04:47:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2013 14:47:50 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51527360.9050604@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <51527360.9050604@oracle.com> Message-ID: <515279F6.4090803@oracle.com> On 27/03/2013 2:19 PM, Jon Masamitsu wrote: > > On 3/26/2013 7:49 PM, David Holmes wrote: >> Well now you have confused me. I thought checking >> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user >> has not attempted manage the number of GC threads even though they >> recognize the number of processors may start at 1 and increase later). >> I do not understand the new <2 test - maybe I really only want 1, if I >> asked for that why should I get a warning ??? >> >> But, this is a GC warning (and I think it is misplaced anyway) so if >> Jon is happy with this behaviour so be it. > David, > > By "misplaced" do you mean that no warning should be issued at all? Yes. I don't think it really serves a useful purpose. There are numerous thread related settings that will be wrongly provisioned if the VM starts with 1 processor and later gets N. I don't see that ParallelGCThreads is particularly special in that regard. Plus I'm not even sure that given such circumstances the user will be able to know what a reasonable value to assign to it is (the policies by which processors get added/removed to a "domain" may be beyond the control or knowledge of the user starting the application). AssumeMP avoids crashes but to get reasonable behaviour from the application requires dynamic adaptation in the VM. Cheers, David > Jon >> >> Cheers, >> David >> >> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>> Sorry, copied wrong link. It is at same link. >>> >>> http://cr.openjdk.java.net/~minqi/2178143/ >>> >>> Thanks >>> Yumin >>> >>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>> >>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>> Hi, Jon >>>>> >>>>> I made a change to the warning condition and move it after GC flags >>>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>>> Please take a look if it is right. The This is the new webrev: >>>>> >>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>> >>>> This webrev isn't accessible outside Oracle... >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set with >>>>> turning on AssumeMP. The warning is gone. >>>>> Also tested with ncpus = 1 and the warning is on too. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>> If I set AssumeMP on the command line and nothing else >>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>> am I going to see the warning? If yes, that seems too intrusive. >>>>>> I can see users hearing about the flag and deciding to include >>>>>> it always just to be safe. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>> new web in the same link. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>> David, >>>>>>>>> >>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>> David and All, >>>>>>>>>>> >>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>> >>>>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>>>> since >>>>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>>>> moved it >>>>>>>>>>> into >>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>> >>>>>>>>>>> before call set GC flags. >>>>>>>>>> >>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>> ParallelGCThreads. >>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Serial GC is set here: >>>>>>>> >>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>> 3254 force_serial_gc(); >>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>> >>>>>>>>> So after it moved into >>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>> increase >>>>>>>>> from one, then" >>>>>>>>> 3286 " you should configure the number of parallel GC >>>>>>>>> threads appropriately" >>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>> 3288 } >>>>>>>>> 3289 // Set per-collector flags >>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>>>> ParNew >>>>>>>>> check below >>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>> 3298 } >>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>> >>>>>>>>> It is excluded for serial GC. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>>> Otherwise looks good. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>> >>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>> >>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>> >>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>> >>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>> unnecessary >>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>> >>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>> >>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>> cores"); >>>>>>>>>>>> + } >>>>>>>>>>>> >>>>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>>>> here. >>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>> parallel GC? >>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>> better to >>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>> >>>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>>> If they >>>>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>>>> they >>>>>>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>>>>>> to GC >>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>> >>>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>>> from one, >>>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>> >>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>> >>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>> instead? >>>>>>>>>>>> >>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>> >>>>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>> >>>>>>>>>>>>> /Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>>>> recommend >>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>>>>>> avoid >>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>>> during >>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>>>> various >>>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Wed Mar 27 04:54:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2013 14:54:18 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <5152704B.9090302@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> Message-ID: <51527B7A.1020709@oracle.com> On 27/03/2013 2:06 PM, Yumin Qi wrote: > David, > > On 3/26/2013 7:49 PM, David Holmes wrote: >> Well now you have confused me. I thought checking >> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user >> has not attempted manage the number of GC threads even though they >> recognize the number of processors may start at 1 and increase later). >> I do not understand the new <2 test - maybe I really only want 1, if I >> asked for that why should I get a warning ??? >> > The previous code is issuing the warning before gc set flags (includes > ParallelGCThreads), we don't want with AssumeMP turned on, running on a > MP issues the warning since ParallelGCThreads will be not 1 but the > number of calculation based on ncpus. So I moved the check code after > GC set flags. After GC set flags, ParallelGCThreads is not the default > value (0) so I check if it is < 2. I was overlooking the case where you use +AssumeMP but have multiple processors anyway. But if I explicitly set ParallelGCThreads=1 then I don't expect to get a warning. Not sure we can distinguish these cases though. Again I leave this to you and Jon to finalize. Thanks, David > If users really want to run with single CPU with -XX:+AssumeMP, giving a > warning is reasonable (this is our intention here) --- there is > possibility they will increase number of cpus even they don't, that is OK. > > Thanks > Yumin >> But, this is a GC warning (and I think it is misplaced anyway) so if >> Jon is happy with this behaviour so be it. >> >> Cheers, >> David >> >> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>> Sorry, copied wrong link. It is at same link. >>> >>> http://cr.openjdk.java.net/~minqi/2178143/ >>> >>> Thanks >>> Yumin >>> >>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>> >>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>> Hi, Jon >>>>> >>>>> I made a change to the warning condition and move it after GC flags >>>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>>> Please take a look if it is right. The This is the new webrev: >>>>> >>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>> >>>> This webrev isn't accessible outside Oracle... >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set with >>>>> turning on AssumeMP. The warning is gone. >>>>> Also tested with ncpus = 1 and the warning is on too. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>> If I set AssumeMP on the command line and nothing else >>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>> am I going to see the warning? If yes, that seems too intrusive. >>>>>> I can see users hearing about the flag and deciding to include >>>>>> it always just to be safe. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>> new web in the same link. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>> David, >>>>>>>>> >>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>> David and All, >>>>>>>>>>> >>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>> >>>>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>>>> since >>>>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>>>> moved it >>>>>>>>>>> into >>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>> >>>>>>>>>>> before call set GC flags. >>>>>>>>>> >>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>> ParallelGCThreads. >>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Serial GC is set here: >>>>>>>> >>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>> 3254 force_serial_gc(); >>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>> >>>>>>>>> So after it moved into >>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>> increase >>>>>>>>> from one, then" >>>>>>>>> 3286 " you should configure the number of parallel GC >>>>>>>>> threads appropriately" >>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>> 3288 } >>>>>>>>> 3289 // Set per-collector flags >>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>>>> ParNew >>>>>>>>> check below >>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>> 3298 } >>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>> >>>>>>>>> It is excluded for serial GC. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>>> Otherwise looks good. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>> >>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>> >>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>> >>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>> >>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>> unnecessary >>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>> >>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>> >>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>> cores"); >>>>>>>>>>>> + } >>>>>>>>>>>> >>>>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>>>> here. >>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>> parallel GC? >>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>> better to >>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>> >>>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>>> If they >>>>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>>>> they >>>>>>>>>>>> only have 1 core their VM may not even function adequately due >>>>>>>>>>>> to GC >>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>> >>>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>>> from one, >>>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>> >>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>> >>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>> instead? >>>>>>>>>>>> >>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>> >>>>>>>>>>>> "Instruct the VM to assume multiple processors are available" >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>> >>>>>>>>>>>>> /Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add warning to >>>>>>>>>>>>>> recommend >>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind user to >>>>>>>>>>>>>> avoid >>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>> the test case running on Linux which is not Zone configured. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>>> during >>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Situation: Customer first configure only one CPU online and >>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>>>> various >>>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced to be >>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From stefan.karlsson at oracle.com Wed Mar 27 09:31:05 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Mar 2013 10:31:05 +0100 Subject: RFR (S): 8010818: NPG: Remove metaspace memory pools In-Reply-To: <5151B8B4.3040103@oracle.com> References: <5151B8B4.3040103@oracle.com> Message-ID: <5152BC59.2040109@oracle.com> Looks good. StefanK On 03/26/2013 04:03 PM, Erik Helin wrote: > Hi all, > > I pushed "8000754: NPG: Implement a MemoryPool MXBean for Metaspace" > last Friday (April 22). Unfortunately, the change triggered a couple > of bugs: > > - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010719 > 8010719 : NPG: The metaspace memory pools acquires Metaspace > allocation lock out of order with Service_lock > - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010734 > 8010734 : NPG: The test MemoryTest.java needs to be updated to > support metaspace > - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010730 > 8010730 : NPG: Bad assert in JVM_ENTRY(jobject, > jmm_GetMemoryUsage(JNIEnv* env, jboolean heap)) > > In order to not cause disturbance upstream (in hotspot-main), it is > better to revert the change 8000754, since these bugs are only > triggered due to the metaspace memory pools. > > The reverse patch was created by running: > > hg diff -r 4321 -r 4322 --reverse > > in the hotspot-gc/hotspot repistory. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8010818/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010818 > > Testing: > - All tests that failed during nightly testing are now passing > - JPRT > > Thanks, > Erik From erik.helin at oracle.com Wed Mar 27 09:23:59 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 27 Mar 2013 10:23:59 +0100 Subject: RFR (S): 8010818: NPG: Remove metaspace memory pools In-Reply-To: <5152BC59.2040109@oracle.com> References: <5151B8B4.3040103@oracle.com> <5152BC59.2040109@oracle.com> Message-ID: <5152BAAF.4020509@oracle.com> Thanks! Erik On 03/27/2013 10:31 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 03/26/2013 04:03 PM, Erik Helin wrote: >> Hi all, >> >> I pushed "8000754: NPG: Implement a MemoryPool MXBean for Metaspace" >> last Friday (April 22). Unfortunately, the change triggered a couple >> of bugs: >> >> - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010719 >> 8010719 : NPG: The metaspace memory pools acquires Metaspace >> allocation lock out of order with Service_lock >> - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010734 >> 8010734 : NPG: The test MemoryTest.java needs to be updated to >> support metaspace >> - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010730 >> 8010730 : NPG: Bad assert in JVM_ENTRY(jobject, >> jmm_GetMemoryUsage(JNIEnv* env, jboolean heap)) >> >> In order to not cause disturbance upstream (in hotspot-main), it is >> better to revert the change 8000754, since these bugs are only >> triggered due to the metaspace memory pools. >> >> The reverse patch was created by running: >> >> hg diff -r 4321 -r 4322 --reverse >> >> in the hotspot-gc/hotspot repistory. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8010818/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010818 >> >> Testing: >> - All tests that failed during nightly testing are now passing >> - JPRT >> >> Thanks, >> Erik > From erik.helin at oracle.com Wed Mar 27 15:46:48 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Wed, 27 Mar 2013 15:46:48 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8010818: NPG: Remove metaspace memory pools Message-ID: <20130327154655.661FA48419@hg.openjdk.java.net> Changeset: 42e370795a39 Author: ehelin Date: 2013-03-27 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/42e370795a39 8010818: NPG: Remove metaspace memory pools Reviewed-by: mgerdin, stefank ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp - test/gc/metaspace/TestMetaspaceMemoryPools.java From yumin.qi at oracle.com Wed Mar 27 16:41:11 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 27 Mar 2013 09:41:11 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51527B7A.1020709@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> Message-ID: <51532127.1080002@oracle.com> so the warning should be if (AssumeMP && !UseSerialGC) { if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { warning("If the number of processors is expected to increase from one, then" " you should configure the number of parallel GC threads appropriately" " using -XX:ParallelGCThreads=N"); } } So the warning will only be issued when AssumeMP turned on and the ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not the default value 0, so the warning will not be triggered. I will do a test. Is this better? Thanks Yumin On 3/26/2013 9:54 PM, David Holmes wrote: > On 27/03/2013 2:06 PM, Yumin Qi wrote: >> David, >> >> On 3/26/2013 7:49 PM, David Holmes wrote: >>> Well now you have confused me. I thought checking >>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user >>> has not attempted manage the number of GC threads even though they >>> recognize the number of processors may start at 1 and increase later). >>> I do not understand the new <2 test - maybe I really only want 1, if I >>> asked for that why should I get a warning ??? >>> >> The previous code is issuing the warning before gc set flags (includes >> ParallelGCThreads), we don't want with AssumeMP turned on, running on a >> MP issues the warning since ParallelGCThreads will be not 1 but the >> number of calculation based on ncpus. So I moved the check code after >> GC set flags. After GC set flags, ParallelGCThreads is not the default >> value (0) so I check if it is < 2. > > I was overlooking the case where you use +AssumeMP but have multiple > processors anyway. But if I explicitly set ParallelGCThreads=1 then I > don't expect to get a warning. Not sure we can distinguish these cases > though. > > Again I leave this to you and Jon to finalize. > > Thanks, > David > >> If users really want to run with single CPU with -XX:+AssumeMP, giving a >> warning is reasonable (this is our intention here) --- there is >> possibility they will increase number of cpus even they don't, that >> is OK. >> >> Thanks >> Yumin >>> But, this is a GC warning (and I think it is misplaced anyway) so if >>> Jon is happy with this behaviour so be it. >>> >>> Cheers, >>> David >>> >>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>> Sorry, copied wrong link. It is at same link. >>>> >>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>> >>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>> Hi, Jon >>>>>> >>>>>> I made a change to the warning condition and move it after GC >>>>>> flags >>>>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>>>> Please take a look if it is right. The This is the new webrev: >>>>>> >>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>> >>>>> This webrev isn't accessible outside Oracle... >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set >>>>>> with >>>>>> turning on AssumeMP. The warning is gone. >>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>> am I going to see the warning? If yes, that seems too intrusive. >>>>>>> I can see users hearing about the flag and deciding to include >>>>>>> it always just to be safe. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>> new web in the same link. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>> David and All, >>>>>>>>>>>> >>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>> >>>>>>>>>>>> David, I did not move the warning into set_parallel_gc_flags() >>>>>>>>>>>> since >>>>>>>>>>>> except for serial gc, all other GCs will check this flag, so I >>>>>>>>>>>> moved it >>>>>>>>>>>> into >>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>> >>>>>>>>>>>> before call set GC flags. >>>>>>>>>>> >>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Serial GC is set here: >>>>>>>>> >>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>> >>>>>>>>>> So after it moved into >>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>> increase >>>>>>>>>> from one, then" >>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>> parallel GC >>>>>>>>>> threads appropriately" >>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>> 3288 } >>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done before >>>>>>>>>> ParNew >>>>>>>>>> check below >>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set above >>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>> 3298 } >>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>> >>>>>>>>>> It is excluded for serial GC. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>>> Otherwise looks good. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>> >>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>> >>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>> >>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>> >>>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>>> unnecessary >>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>> >>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>> >>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>>> cores"); >>>>>>>>>>>>> + } >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or desirable >>>>>>>>>>>>> here. >>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>> better to >>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>> >>>>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>>>> If they >>>>>>>>>>>>> use the maximum expected number of cores initially then while >>>>>>>>>>>>> they >>>>>>>>>>>>> only have 1 core their VM may not even function adequately >>>>>>>>>>>>> due >>>>>>>>>>>>> to GC >>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>> >>>>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>>>> from one, >>>>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>> >>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>> instead? >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>> >>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>> available" >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU online >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>> others offline to run java application, after java program >>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused SEGV in >>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced >>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From jon.masamitsu at oracle.com Wed Mar 27 18:17:13 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 27 Mar 2013 11:17:13 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51532127.1080002@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> Message-ID: <515337A9.9090509@oracle.com> Yumin, How about adding PrintGCDetails to the guard? if (AssumeMP && !UseSerialGC && PrintGCDetails) {. Jon On 3/27/2013 9:41 AM, Yumin Qi wrote: > so the warning should be > > if (AssumeMP && !UseSerialGC) { > if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { > warning("If the number of processors is expected to increase > from one, then" > " you should configure the number of parallel GC threads > appropriately" > " using -XX:ParallelGCThreads=N"); > } > } > > So the warning will only be issued when AssumeMP turned on and the > ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not the > default value 0, so the warning will not be triggered. I will do a test. > > Is this better? > > Thanks > Yumin > > On 3/26/2013 9:54 PM, David Holmes wrote: >> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>> David, >>> >>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>> Well now you have confused me. I thought checking >>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the user >>>> has not attempted manage the number of GC threads even though they >>>> recognize the number of processors may start at 1 and increase later). >>>> I do not understand the new <2 test - maybe I really only want 1, if I >>>> asked for that why should I get a warning ??? >>>> >>> The previous code is issuing the warning before gc set flags (includes >>> ParallelGCThreads), we don't want with AssumeMP turned on, running on a >>> MP issues the warning since ParallelGCThreads will be not 1 but the >>> number of calculation based on ncpus. So I moved the check code after >>> GC set flags. After GC set flags, ParallelGCThreads is not the default >>> value (0) so I check if it is < 2. >> >> I was overlooking the case where you use +AssumeMP but have multiple >> processors anyway. But if I explicitly set ParallelGCThreads=1 then I >> don't expect to get a warning. Not sure we can distinguish these >> cases though. >> >> Again I leave this to you and Jon to finalize. >> >> Thanks, >> David >> >>> If users really want to run with single CPU with -XX:+AssumeMP, >>> giving a >>> warning is reasonable (this is our intention here) --- there is >>> possibility they will increase number of cpus even they don't, that >>> is OK. >>> >>> Thanks >>> Yumin >>>> But, this is a GC warning (and I think it is misplaced anyway) so if >>>> Jon is happy with this behaviour so be it. >>>> >>>> Cheers, >>>> David >>>> >>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>> Sorry, copied wrong link. It is at same link. >>>>> >>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>> Hi, Jon >>>>>>> >>>>>>> I made a change to the warning condition and move it after GC >>>>>>> flags >>>>>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>> >>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>> >>>>>> This webrev isn't accessible outside Oracle... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads set >>>>>>> with >>>>>>> turning on AssumeMP. The warning is gone. >>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>> intrusive. >>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>> it always just to be safe. >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>> new web in the same link. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>> David, >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>> David and All, >>>>>>>>>>>>> >>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>> >>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>> since >>>>>>>>>>>>> except for serial gc, all other GCs will check this flag, >>>>>>>>>>>>> so I >>>>>>>>>>>>> moved it >>>>>>>>>>>>> into >>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>> >>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>> >>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Serial GC is set here: >>>>>>>>>> >>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. Otherwise we >>>>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>> >>>>>>>>>>> So after it moved into >>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>> increase >>>>>>>>>>> from one, then" >>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>> parallel GC >>>>>>>>>>> threads appropriately" >>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>> 3288 } >>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>> before >>>>>>>>>>> ParNew >>>>>>>>>>> check below >>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set >>>>>>>>>>> above >>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>> 3298 } >>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>> >>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>> >>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>> >>>>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>> + } >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>> desirable >>>>>>>>>>>>>> here. >>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>> better to >>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> In any case it isn't clear what the user should supply here. >>>>>>>>>>>>>> If they >>>>>>>>>>>>>> use the maximum expected number of cores initially then >>>>>>>>>>>>>> while >>>>>>>>>>>>>> they >>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>> to GC >>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>> >>>>>>>>>>>>>> warning("If the number of processors is expected to increase >>>>>>>>>>>>>> from one, >>>>>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>> instead? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>> available" >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a single >>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>> places where data consistency was broken. The solution is >>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced >>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From yumin.qi at oracle.com Wed Mar 27 19:22:01 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 27 Mar 2013 12:22:01 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <515337A9.9090509@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> <515337A9.9090509@oracle.com> Message-ID: <515346D9.6010801@oracle.com> Jon, The warning is for a immediate attention, with PrintGCDetail, that requires it set on in command line, right? I also found that with default setting (no GC flavor set), no setting for ParallelGCThreads, it will be 0. so with java -XX:+AssumeMP -version, it will give warning, this is not right. // Set per-collector flags if (UseParallelGC || UseParallelOldGC) { set_parallel_gc_flags(); } else if (UseConcMarkSweepGC) { // should be done before ParNew check below set_cms_and_parnew_gc_flags(); } else if (UseParNewGC) { // skipped if CMS is set above set_parnew_gc_flags(); } else if (UseG1GC) { set_g1_gc_flags(); } check_deprecated_gcs(); check_deprecated_gc_flags(); With default GC (Btw, what is the default GC collector?), ParallelGCThreads = 0. So I will change code to: if (AssumeMP && !UseSerialGC) { if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { warning("If the number of processors is expected to increase from one, then" " you should configure the number of parallel GC threads appropriately" " using -XX:ParallelGCThreads=N"); } } Will send another webrev after test. Thanks Yumin On 3/27/2013 11:17 AM, Jon Masamitsu wrote: > Yumin, > > How about adding PrintGCDetails to the guard? > > if (AssumeMP && !UseSerialGC && PrintGCDetails) {. > > Jon > > On 3/27/2013 9:41 AM, Yumin Qi wrote: >> so the warning should be >> >> if (AssumeMP && !UseSerialGC) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { >> warning("If the number of processors is expected to increase >> from one, then" >> " you should configure the number of parallel GC >> threads appropriately" >> " using -XX:ParallelGCThreads=N"); >> } >> } >> >> So the warning will only be issued when AssumeMP turned on and the >> ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not >> the default value 0, so the warning will not be triggered. I will do >> a test. >> >> Is this better? >> >> Thanks >> Yumin >> >> On 3/26/2013 9:54 PM, David Holmes wrote: >>> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>>> David, >>>> >>>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>>> Well now you have confused me. I thought checking >>>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the >>>>> user >>>>> has not attempted manage the number of GC threads even though they >>>>> recognize the number of processors may start at 1 and increase >>>>> later). >>>>> I do not understand the new <2 test - maybe I really only want 1, >>>>> if I >>>>> asked for that why should I get a warning ??? >>>>> >>>> The previous code is issuing the warning before gc set flags (includes >>>> ParallelGCThreads), we don't want with AssumeMP turned on, running >>>> on a >>>> MP issues the warning since ParallelGCThreads will be not 1 but the >>>> number of calculation based on ncpus. So I moved the check code after >>>> GC set flags. After GC set flags, ParallelGCThreads is not the >>>> default >>>> value (0) so I check if it is < 2. >>> >>> I was overlooking the case where you use +AssumeMP but have multiple >>> processors anyway. But if I explicitly set ParallelGCThreads=1 then >>> I don't expect to get a warning. Not sure we can distinguish these >>> cases though. >>> >>> Again I leave this to you and Jon to finalize. >>> >>> Thanks, >>> David >>> >>>> If users really want to run with single CPU with -XX:+AssumeMP, >>>> giving a >>>> warning is reasonable (this is our intention here) --- there is >>>> possibility they will increase number of cpus even they don't, that >>>> is OK. >>>> >>>> Thanks >>>> Yumin >>>>> But, this is a GC warning (and I think it is misplaced anyway) so if >>>>> Jon is happy with this behaviour so be it. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>>> Sorry, copied wrong link. It is at same link. >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>>> >>>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>>> Hi, Jon >>>>>>>> >>>>>>>> I made a change to the warning condition and move it after GC >>>>>>>> flags >>>>>>>> are set. I think at this time, ParallelGCThreads has a value != 0. >>>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>>> >>>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>>> >>>>>>> This webrev isn't accessible outside Oracle... >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads >>>>>>>> set with >>>>>>>> turning on AssumeMP. The warning is gone. >>>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>>> intrusive. >>>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>>> it always just to be safe. >>>>>>>>> >>>>>>>>> Jon >>>>>>>>> >>>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>>> new web in the same link. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>>> David, >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>>> David and All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>>> since >>>>>>>>>>>>>> except for serial gc, all other GCs will check this flag, >>>>>>>>>>>>>> so I >>>>>>>>>>>>>> moved it >>>>>>>>>>>>>> into >>>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>>> >>>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Serial GC is set here: >>>>>>>>>>> >>>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. >>>>>>>>>>> Otherwise we >>>>>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>>>>> SerialGC is the only GC built into the VM, but not for the case >>>>>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>> >>>>>>>>>>>> So after it moved into >>>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>>> increase >>>>>>>>>>>> from one, then" >>>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>>> parallel GC >>>>>>>>>>>> threads appropriately" >>>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>>> 3288 } >>>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>>> before >>>>>>>>>>>> ParNew >>>>>>>>>>>> check below >>>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set >>>>>>>>>>>> above >>>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>>> 3298 } >>>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>> >>>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>>> better to >>>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In any case it isn't clear what the user should supply >>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>> If they >>>>>>>>>>>>>>> use the maximum expected number of cores initially then >>>>>>>>>>>>>>> while >>>>>>>>>>>>>>> they >>>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>>> to GC >>>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> warning("If the number of processors is expected to >>>>>>>>>>>>>>> increase >>>>>>>>>>>>>>> from one, >>>>>>>>>>>>>>> then you should configure the number of parallel GC threads >>>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>>> available" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs changed >>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a >>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>>> places where data consistency was broken. The >>>>>>>>>>>>>>>>>> solution is >>>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is forced >>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > From yumin.qi at oracle.com Wed Mar 27 19:40:43 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 27 Mar 2013 12:40:43 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <515346D9.6010801@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> <515337A9.9090509@oracle.com> <515346D9.6010801@oracle.com> Message-ID: <51534B3B.8020209@oracle.com> new webrev at same link: http://cr.openjdk.java.net/~minqi/2178143/ Thanks Yumin On 3/27/2013 12:22 PM, Yumin Qi wrote: > Jon, > > The warning is for a immediate attention, with PrintGCDetail, that > requires it set on in command line, right? > > I also found that with default setting (no GC flavor set), no > setting for ParallelGCThreads, it will be 0. > > so with java -XX:+AssumeMP -version, it will give warning, this is > not right. > > // Set per-collector flags > if (UseParallelGC || UseParallelOldGC) { > set_parallel_gc_flags(); > } else if (UseConcMarkSweepGC) { // should be done before ParNew > check below > set_cms_and_parnew_gc_flags(); > } else if (UseParNewGC) { // skipped if CMS is set above > set_parnew_gc_flags(); > } else if (UseG1GC) { > set_g1_gc_flags(); > } > check_deprecated_gcs(); > check_deprecated_gc_flags(); > > With default GC (Btw, what is the default GC collector?), > ParallelGCThreads = 0. > > > > So I will change code to: > > if (AssumeMP && !UseSerialGC) { > if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { > warning("If the number of processors is expected to increase > from one, then" > " you should configure the number of parallel GC threads > appropriately" > " using -XX:ParallelGCThreads=N"); > } > } > > Will send another webrev after test. > > Thanks > Yumin > > On 3/27/2013 11:17 AM, Jon Masamitsu wrote: >> Yumin, >> >> How about adding PrintGCDetails to the guard? >> >> if (AssumeMP && !UseSerialGC && PrintGCDetails) {. >> >> Jon >> >> On 3/27/2013 9:41 AM, Yumin Qi wrote: >>> so the warning should be >>> >>> if (AssumeMP && !UseSerialGC) { >>> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { >>> warning("If the number of processors is expected to increase >>> from one, then" >>> " you should configure the number of parallel GC >>> threads appropriately" >>> " using -XX:ParallelGCThreads=N"); >>> } >>> } >>> >>> So the warning will only be issued when AssumeMP turned on and the >>> ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not >>> the default value 0, so the warning will not be triggered. I will do >>> a test. >>> >>> Is this better? >>> >>> Thanks >>> Yumin >>> >>> On 3/26/2013 9:54 PM, David Holmes wrote: >>>> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>>>> David, >>>>> >>>>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>>>> Well now you have confused me. I thought checking >>>>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the >>>>>> user >>>>>> has not attempted manage the number of GC threads even though they >>>>>> recognize the number of processors may start at 1 and increase >>>>>> later). >>>>>> I do not understand the new <2 test - maybe I really only want 1, >>>>>> if I >>>>>> asked for that why should I get a warning ??? >>>>>> >>>>> The previous code is issuing the warning before gc set flags >>>>> (includes >>>>> ParallelGCThreads), we don't want with AssumeMP turned on, running >>>>> on a >>>>> MP issues the warning since ParallelGCThreads will be not 1 but the >>>>> number of calculation based on ncpus. So I moved the check code >>>>> after >>>>> GC set flags. After GC set flags, ParallelGCThreads is not the >>>>> default >>>>> value (0) so I check if it is < 2. >>>> >>>> I was overlooking the case where you use +AssumeMP but have >>>> multiple processors anyway. But if I explicitly set >>>> ParallelGCThreads=1 then I don't expect to get a warning. Not sure >>>> we can distinguish these cases though. >>>> >>>> Again I leave this to you and Jon to finalize. >>>> >>>> Thanks, >>>> David >>>> >>>>> If users really want to run with single CPU with -XX:+AssumeMP, >>>>> giving a >>>>> warning is reasonable (this is our intention here) --- there is >>>>> possibility they will increase number of cpus even they don't, >>>>> that is OK. >>>>> >>>>> Thanks >>>>> Yumin >>>>>> But, this is a GC warning (and I think it is misplaced anyway) so if >>>>>> Jon is happy with this behaviour so be it. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>>>> Sorry, copied wrong link. It is at same link. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>>>> Hi, Jon >>>>>>>>> >>>>>>>>> I made a change to the warning condition and move it after >>>>>>>>> GC flags >>>>>>>>> are set. I think at this time, ParallelGCThreads has a value >>>>>>>>> != 0. >>>>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>>>> >>>>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>>>> >>>>>>>> This webrev isn't accessible outside Oracle... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads >>>>>>>>> set with >>>>>>>>> turning on AssumeMP. The warning is gone. >>>>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>>>> intrusive. >>>>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>>>> it always just to be safe. >>>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>>>> new web in the same link. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>>>> David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> David and All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> except for serial gc, all other GCs will check this >>>>>>>>>>>>>>> flag, so I >>>>>>>>>>>>>>> moved it >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Serial GC is set here: >>>>>>>>>>>> >>>>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. >>>>>>>>>>>> Otherwise we >>>>>>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>>>>>> SerialGC is the only GC built into the VM, but not for the >>>>>>>>>>>> case >>>>>>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>> >>>>>>>>>>>>> So after it moved into >>>>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>>>> increase >>>>>>>>>>>>> from one, then" >>>>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>>>> parallel GC >>>>>>>>>>>>> threads appropriately" >>>>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>> 3288 } >>>>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>>>> before >>>>>>>>>>>>> ParNew >>>>>>>>>>>>> check below >>>>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set >>>>>>>>>>>>> above >>>>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>>>> 3298 } >>>>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>> >>>>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>>>> better to >>>>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In any case it isn't clear what the user should supply >>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>> If they >>>>>>>>>>>>>>>> use the maximum expected number of cores initially then >>>>>>>>>>>>>>>> while >>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>>>> to GC >>>>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> warning("If the number of processors is expected to >>>>>>>>>>>>>>>> increase >>>>>>>>>>>>>>>> from one, >>>>>>>>>>>>>>>> then you should configure the number of parallel GC >>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>>>> available" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs >>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a >>>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>>>> places where data consistency was broken. The >>>>>>>>>>>>>>>>>>> solution is >>>>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is >>>>>>>>>>>>>>>>>>> forced to be >>>>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > From jon.masamitsu at oracle.com Wed Mar 27 20:25:13 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 27 Mar 2013 13:25:13 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <515346D9.6010801@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> <515337A9.9090509@oracle.com> <515346D9.6010801@oracle.com> Message-ID: <515355A9.8000203@oracle.com> Yumin, I suggest the addition of PrintGCDetails to address some of David's concern that basically the warning is not needed. If the user adds PrintGCDetails to the command line, I think it is an indication that the user cares about GC so will want to see the warning. But I'm willing to leave it out if you think every user deserves the warning. Jon On 3/27/2013 12:22 PM, Yumin Qi wrote: > Jon, > > The warning is for a immediate attention, with PrintGCDetail, that > requires it set on in command line, right? > > I also found that with default setting (no GC flavor set), no > setting for ParallelGCThreads, it will be 0. > > so with java -XX:+AssumeMP -version, it will give warning, this is > not right. > > // Set per-collector flags > if (UseParallelGC || UseParallelOldGC) { > set_parallel_gc_flags(); > } else if (UseConcMarkSweepGC) { // should be done before ParNew > check below > set_cms_and_parnew_gc_flags(); > } else if (UseParNewGC) { // skipped if CMS is set above > set_parnew_gc_flags(); > } else if (UseG1GC) { > set_g1_gc_flags(); > } > check_deprecated_gcs(); > check_deprecated_gc_flags(); > > With default GC (Btw, what is the default GC collector?), > ParallelGCThreads = 0. > > > > So I will change code to: > > if (AssumeMP && !UseSerialGC) { > if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { > warning("If the number of processors is expected to increase > from one, then" > " you should configure the number of parallel GC threads > appropriately" > " using -XX:ParallelGCThreads=N"); > } > } > > Will send another webrev after test. > > Thanks > Yumin > > On 3/27/2013 11:17 AM, Jon Masamitsu wrote: >> Yumin, >> >> How about adding PrintGCDetails to the guard? >> >> if (AssumeMP && !UseSerialGC && PrintGCDetails) {. >> >> Jon >> >> On 3/27/2013 9:41 AM, Yumin Qi wrote: >>> so the warning should be >>> >>> if (AssumeMP && !UseSerialGC) { >>> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { >>> warning("If the number of processors is expected to increase >>> from one, then" >>> " you should configure the number of parallel GC >>> threads appropriately" >>> " using -XX:ParallelGCThreads=N"); >>> } >>> } >>> >>> So the warning will only be issued when AssumeMP turned on and the >>> ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not >>> the default value 0, so the warning will not be triggered. I will do >>> a test. >>> >>> Is this better? >>> >>> Thanks >>> Yumin >>> >>> On 3/26/2013 9:54 PM, David Holmes wrote: >>>> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>>>> David, >>>>> >>>>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>>>> Well now you have confused me. I thought checking >>>>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the >>>>>> user >>>>>> has not attempted manage the number of GC threads even though they >>>>>> recognize the number of processors may start at 1 and increase >>>>>> later). >>>>>> I do not understand the new <2 test - maybe I really only want 1, >>>>>> if I >>>>>> asked for that why should I get a warning ??? >>>>>> >>>>> The previous code is issuing the warning before gc set flags >>>>> (includes >>>>> ParallelGCThreads), we don't want with AssumeMP turned on, running >>>>> on a >>>>> MP issues the warning since ParallelGCThreads will be not 1 but the >>>>> number of calculation based on ncpus. So I moved the check code >>>>> after >>>>> GC set flags. After GC set flags, ParallelGCThreads is not the >>>>> default >>>>> value (0) so I check if it is < 2. >>>> >>>> I was overlooking the case where you use +AssumeMP but have >>>> multiple processors anyway. But if I explicitly set >>>> ParallelGCThreads=1 then I don't expect to get a warning. Not sure >>>> we can distinguish these cases though. >>>> >>>> Again I leave this to you and Jon to finalize. >>>> >>>> Thanks, >>>> David >>>> >>>>> If users really want to run with single CPU with -XX:+AssumeMP, >>>>> giving a >>>>> warning is reasonable (this is our intention here) --- there is >>>>> possibility they will increase number of cpus even they don't, >>>>> that is OK. >>>>> >>>>> Thanks >>>>> Yumin >>>>>> But, this is a GC warning (and I think it is misplaced anyway) so if >>>>>> Jon is happy with this behaviour so be it. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>>>> Sorry, copied wrong link. It is at same link. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>>>> Hi, Jon >>>>>>>>> >>>>>>>>> I made a change to the warning condition and move it after >>>>>>>>> GC flags >>>>>>>>> are set. I think at this time, ParallelGCThreads has a value >>>>>>>>> != 0. >>>>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>>>> >>>>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>>>> >>>>>>>> This webrev isn't accessible outside Oracle... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads >>>>>>>>> set with >>>>>>>>> turning on AssumeMP. The warning is gone. >>>>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>>>> intrusive. >>>>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>>>> it always just to be safe. >>>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>>>> new web in the same link. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>>>> David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> David and All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> except for serial gc, all other GCs will check this >>>>>>>>>>>>>>> flag, so I >>>>>>>>>>>>>>> moved it >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Serial GC is set here: >>>>>>>>>>>> >>>>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. >>>>>>>>>>>> Otherwise we >>>>>>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>>>>>> SerialGC is the only GC built into the VM, but not for the >>>>>>>>>>>> case >>>>>>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>> >>>>>>>>>>>>> So after it moved into >>>>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>>>> increase >>>>>>>>>>>>> from one, then" >>>>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>>>> parallel GC >>>>>>>>>>>>> threads appropriately" >>>>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>> 3288 } >>>>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>>>> before >>>>>>>>>>>>> ParNew >>>>>>>>>>>>> check below >>>>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set >>>>>>>>>>>>> above >>>>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>>>> 3298 } >>>>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>> >>>>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>>>> better to >>>>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In any case it isn't clear what the user should supply >>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>> If they >>>>>>>>>>>>>>>> use the maximum expected number of cores initially then >>>>>>>>>>>>>>>> while >>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>>>> to GC >>>>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> warning("If the number of processors is expected to >>>>>>>>>>>>>>>> increase >>>>>>>>>>>>>>>> from one, >>>>>>>>>>>>>>>> then you should configure the number of parallel GC >>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>>>> available" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs >>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a >>>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>>>> places where data consistency was broken. The >>>>>>>>>>>>>>>>>>> solution is >>>>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is >>>>>>>>>>>>>>>>>>> forced to be >>>>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > From yumin.qi at oracle.com Wed Mar 27 20:33:11 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 27 Mar 2013 13:33:11 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <515355A9.8000203@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> <515337A9.9090509@oracle.com> <515346D9.6010801@oracle.com> <515355A9.8000203@oracle.com> Message-ID: <51535787.1000604@oracle.com> Jon, On 3/27/2013 1:25 PM, Jon Masamitsu wrote: > Yumin, > > I suggest the addition of PrintGCDetails to address some of David's > concern that basically the warning is not needed. If the user adds > PrintGCDetails to the command line, I think it is an indication that > the user cares about GC so will want to see the warning. > > But I'm willing to leave it out if you think every user deserves the > warning. > In fact it is only for users who will use this flag --- a very very small number compared to whole I think, so I will keep current setting. Thanks Yumin > Jon > > On 3/27/2013 12:22 PM, Yumin Qi wrote: >> Jon, >> >> The warning is for a immediate attention, with PrintGCDetail, that >> requires it set on in command line, right? >> >> I also found that with default setting (no GC flavor set), no >> setting for ParallelGCThreads, it will be 0. >> >> so with java -XX:+AssumeMP -version, it will give warning, this is >> not right. >> >> // Set per-collector flags >> if (UseParallelGC || UseParallelOldGC) { >> set_parallel_gc_flags(); >> } else if (UseConcMarkSweepGC) { // should be done before ParNew >> check below >> set_cms_and_parnew_gc_flags(); >> } else if (UseParNewGC) { // skipped if CMS is set above >> set_parnew_gc_flags(); >> } else if (UseG1GC) { >> set_g1_gc_flags(); >> } >> check_deprecated_gcs(); >> check_deprecated_gc_flags(); >> >> With default GC (Btw, what is the default GC collector?), >> ParallelGCThreads = 0. >> >> >> >> So I will change code to: >> >> if (AssumeMP && !UseSerialGC) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { >> warning("If the number of processors is expected to increase >> from one, then" >> " you should configure the number of parallel GC >> threads appropriately" >> " using -XX:ParallelGCThreads=N"); >> } >> } >> >> Will send another webrev after test. >> >> Thanks >> Yumin >> >> On 3/27/2013 11:17 AM, Jon Masamitsu wrote: >>> Yumin, >>> >>> How about adding PrintGCDetails to the guard? >>> >>> if (AssumeMP && !UseSerialGC && PrintGCDetails) {. >>> >>> Jon >>> >>> On 3/27/2013 9:41 AM, Yumin Qi wrote: >>>> so the warning should be >>>> >>>> if (AssumeMP && !UseSerialGC) { >>>> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { >>>> warning("If the number of processors is expected to increase >>>> from one, then" >>>> " you should configure the number of parallel GC >>>> threads appropriately" >>>> " using -XX:ParallelGCThreads=N"); >>>> } >>>> } >>>> >>>> So the warning will only be issued when AssumeMP turned on and the >>>> ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not >>>> the default value 0, so the warning will not be triggered. I will >>>> do a test. >>>> >>>> Is this better? >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 9:54 PM, David Holmes wrote: >>>>> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>>>>> David, >>>>>> >>>>>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>>>>> Well now you have confused me. I thought checking >>>>>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do >>>>>>> (the user >>>>>>> has not attempted manage the number of GC threads even though they >>>>>>> recognize the number of processors may start at 1 and increase >>>>>>> later). >>>>>>> I do not understand the new <2 test - maybe I really only want >>>>>>> 1, if I >>>>>>> asked for that why should I get a warning ??? >>>>>>> >>>>>> The previous code is issuing the warning before gc set flags >>>>>> (includes >>>>>> ParallelGCThreads), we don't want with AssumeMP turned on, >>>>>> running on a >>>>>> MP issues the warning since ParallelGCThreads will be not 1 but the >>>>>> number of calculation based on ncpus. So I moved the check code >>>>>> after >>>>>> GC set flags. After GC set flags, ParallelGCThreads is not the >>>>>> default >>>>>> value (0) so I check if it is < 2. >>>>> >>>>> I was overlooking the case where you use +AssumeMP but have >>>>> multiple processors anyway. But if I explicitly set >>>>> ParallelGCThreads=1 then I don't expect to get a warning. Not sure >>>>> we can distinguish these cases though. >>>>> >>>>> Again I leave this to you and Jon to finalize. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> If users really want to run with single CPU with -XX:+AssumeMP, >>>>>> giving a >>>>>> warning is reasonable (this is our intention here) --- there is >>>>>> possibility they will increase number of cpus even they don't, >>>>>> that is OK. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>>> But, this is a GC warning (and I think it is misplaced anyway) >>>>>>> so if >>>>>>> Jon is happy with this behaviour so be it. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>>>>> Sorry, copied wrong link. It is at same link. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>>>>> >>>>>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>>>>> Hi, Jon >>>>>>>>>> >>>>>>>>>> I made a change to the warning condition and move it after >>>>>>>>>> GC flags >>>>>>>>>> are set. I think at this time, ParallelGCThreads has a value >>>>>>>>>> != 0. >>>>>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>>>>> >>>>>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>>>>> >>>>>>>>> This webrev isn't accessible outside Oracle... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads >>>>>>>>>> set with >>>>>>>>>> turning on AssumeMP. The warning is gone. >>>>>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>>>>> intrusive. >>>>>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>>>>> it always just to be safe. >>>>>>>>>>> >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>>>>> new web in the same link. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>>>>> David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> David and All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> except for serial gc, all other GCs will check this >>>>>>>>>>>>>>>> flag, so I >>>>>>>>>>>>>>>> moved it >>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Serial GC is set here: >>>>>>>>>>>>> >>>>>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. >>>>>>>>>>>>> Otherwise we >>>>>>>>>>>>> only have SerialGC. So you have excluded it for the case >>>>>>>>>>>>> where >>>>>>>>>>>>> SerialGC is the only GC built into the VM, but not for the >>>>>>>>>>>>> case >>>>>>>>>>>>> where all GCs are available and the user requests >>>>>>>>>>>>> UseSerialGC. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> So after it moved into >>>>>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>>>>> increase >>>>>>>>>>>>>> from one, then" >>>>>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>>>>> parallel GC >>>>>>>>>>>>>> threads appropriately" >>>>>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>> 3288 } >>>>>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>>>>> before >>>>>>>>>>>>>> ParNew >>>>>>>>>>>>>> check below >>>>>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is >>>>>>>>>>>>>> set above >>>>>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>>>>> 3298 } >>>>>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That way we don't bypass the assertion and don't >>>>>>>>>>>>>>>>> encounter >>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>>>>> + " num_of_gc_threads can be set to >>>>>>>>>>>>>>>>> number of >>>>>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>>>>> better to >>>>>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In any case it isn't clear what the user should supply >>>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>>> If they >>>>>>>>>>>>>>>>> use the maximum expected number of cores initially >>>>>>>>>>>>>>>>> then while >>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>>>>> to GC >>>>>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> warning("If the number of processors is expected to >>>>>>>>>>>>>>>>> increase >>>>>>>>>>>>>>>>> from one, >>>>>>>>>>>>>>>>> then you should configure the number of parallel GC >>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>>>>> available" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs >>>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a >>>>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>>>>> places where data consistency was broken. The >>>>>>>>>>>>>>>>>>>> solution is >>>>>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is >>>>>>>>>>>>>>>>>>>> forced to be >>>>>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Wed Mar 27 20:44:40 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 27 Mar 2013 13:44:40 -0700 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51534B3B.8020209@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> <515337A9.9090509@oracle.com> <515346D9.6010801@oracle.com> <51534B3B.8020209@oracle.com> Message-ID: <51535A38.8090408@oracle.com> Looks fine. Thanks. Jon On 3/27/2013 12:40 PM, Yumin Qi wrote: > new webrev at same link: > > http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin > > On 3/27/2013 12:22 PM, Yumin Qi wrote: >> Jon, >> >> The warning is for a immediate attention, with PrintGCDetail, that >> requires it set on in command line, right? >> >> I also found that with default setting (no GC flavor set), no >> setting for ParallelGCThreads, it will be 0. >> >> so with java -XX:+AssumeMP -version, it will give warning, this is >> not right. >> >> // Set per-collector flags >> if (UseParallelGC || UseParallelOldGC) { >> set_parallel_gc_flags(); >> } else if (UseConcMarkSweepGC) { // should be done before ParNew >> check below >> set_cms_and_parnew_gc_flags(); >> } else if (UseParNewGC) { // skipped if CMS is set above >> set_parnew_gc_flags(); >> } else if (UseG1GC) { >> set_g1_gc_flags(); >> } >> check_deprecated_gcs(); >> check_deprecated_gc_flags(); >> >> With default GC (Btw, what is the default GC collector?), >> ParallelGCThreads = 0. >> >> >> >> So I will change code to: >> >> if (AssumeMP && !UseSerialGC) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { >> warning("If the number of processors is expected to increase >> from one, then" >> " you should configure the number of parallel GC >> threads appropriately" >> " using -XX:ParallelGCThreads=N"); >> } >> } >> >> Will send another webrev after test. >> >> Thanks >> Yumin >> >> On 3/27/2013 11:17 AM, Jon Masamitsu wrote: >>> Yumin, >>> >>> How about adding PrintGCDetails to the guard? >>> >>> if (AssumeMP && !UseSerialGC && PrintGCDetails) {. >>> >>> Jon >>> >>> On 3/27/2013 9:41 AM, Yumin Qi wrote: >>>> so the warning should be >>>> >>>> if (AssumeMP && !UseSerialGC) { >>>> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { >>>> warning("If the number of processors is expected to increase >>>> from one, then" >>>> " you should configure the number of parallel GC >>>> threads appropriately" >>>> " using -XX:ParallelGCThreads=N"); >>>> } >>>> } >>>> >>>> So the warning will only be issued when AssumeMP turned on and the >>>> ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not >>>> the default value 0, so the warning will not be triggered. I will >>>> do a test. >>>> >>>> Is this better? >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 9:54 PM, David Holmes wrote: >>>>> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>>>>> David, >>>>>> >>>>>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>>>>> Well now you have confused me. I thought checking >>>>>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do >>>>>>> (the user >>>>>>> has not attempted manage the number of GC threads even though they >>>>>>> recognize the number of processors may start at 1 and increase >>>>>>> later). >>>>>>> I do not understand the new <2 test - maybe I really only want >>>>>>> 1, if I >>>>>>> asked for that why should I get a warning ??? >>>>>>> >>>>>> The previous code is issuing the warning before gc set flags >>>>>> (includes >>>>>> ParallelGCThreads), we don't want with AssumeMP turned on, >>>>>> running on a >>>>>> MP issues the warning since ParallelGCThreads will be not 1 but the >>>>>> number of calculation based on ncpus. So I moved the check code >>>>>> after >>>>>> GC set flags. After GC set flags, ParallelGCThreads is not the >>>>>> default >>>>>> value (0) so I check if it is < 2. >>>>> >>>>> I was overlooking the case where you use +AssumeMP but have >>>>> multiple processors anyway. But if I explicitly set >>>>> ParallelGCThreads=1 then I don't expect to get a warning. Not sure >>>>> we can distinguish these cases though. >>>>> >>>>> Again I leave this to you and Jon to finalize. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> If users really want to run with single CPU with -XX:+AssumeMP, >>>>>> giving a >>>>>> warning is reasonable (this is our intention here) --- there is >>>>>> possibility they will increase number of cpus even they don't, >>>>>> that is OK. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>>> But, this is a GC warning (and I think it is misplaced anyway) >>>>>>> so if >>>>>>> Jon is happy with this behaviour so be it. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>>>>> Sorry, copied wrong link. It is at same link. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>>>>> >>>>>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>>>>> Hi, Jon >>>>>>>>>> >>>>>>>>>> I made a change to the warning condition and move it after >>>>>>>>>> GC flags >>>>>>>>>> are set. I think at this time, ParallelGCThreads has a value >>>>>>>>>> != 0. >>>>>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>>>>> >>>>>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>>>>> >>>>>>>>> This webrev isn't accessible outside Oracle... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads >>>>>>>>>> set with >>>>>>>>>> turning on AssumeMP. The warning is gone. >>>>>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>>>>> intrusive. >>>>>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>>>>> it always just to be safe. >>>>>>>>>>> >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>>>>> new web in the same link. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>>>>> David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> David and All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> except for serial gc, all other GCs will check this >>>>>>>>>>>>>>>> flag, so I >>>>>>>>>>>>>>>> moved it >>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Serial GC is set here: >>>>>>>>>>>>> >>>>>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. >>>>>>>>>>>>> Otherwise we >>>>>>>>>>>>> only have SerialGC. So you have excluded it for the case >>>>>>>>>>>>> where >>>>>>>>>>>>> SerialGC is the only GC built into the VM, but not for the >>>>>>>>>>>>> case >>>>>>>>>>>>> where all GCs are available and the user requests >>>>>>>>>>>>> UseSerialGC. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> So after it moved into >>>>>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>>>>> increase >>>>>>>>>>>>>> from one, then" >>>>>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>>>>> parallel GC >>>>>>>>>>>>>> threads appropriately" >>>>>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>> 3288 } >>>>>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>>>>> before >>>>>>>>>>>>>> ParNew >>>>>>>>>>>>>> check below >>>>>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is >>>>>>>>>>>>>> set above >>>>>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>>>>> 3298 } >>>>>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That way we don't bypass the assertion and don't >>>>>>>>>>>>>>>>> encounter >>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>>>>> + " num_of_gc_threads can be set to >>>>>>>>>>>>>>>>> number of >>>>>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>>>>> better to >>>>>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In any case it isn't clear what the user should supply >>>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>>> If they >>>>>>>>>>>>>>>>> use the maximum expected number of cores initially >>>>>>>>>>>>>>>>> then while >>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>>>>> to GC >>>>>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> warning("If the number of processors is expected to >>>>>>>>>>>>>>>>> increase >>>>>>>>>>>>>>>>> from one, >>>>>>>>>>>>>>>>> then you should configure the number of parallel GC >>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>>>>> available" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs >>>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a >>>>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>>>>> places where data consistency was broken. The >>>>>>>>>>>>>>>>>>>> solution is >>>>>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is >>>>>>>>>>>>>>>>>>>> forced to be >>>>>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Mar 27 21:14:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Mar 2013 17:14:34 -0400 Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions In-Reply-To: <515271FB.9090203@oracle.com> References: <515271FB.9090203@oracle.com> Message-ID: <5153613A.4040906@oracle.com> Hi Jon, In metaspace.hpp maybe capacity_in_bytes should be called capacity_bytes_slow() or something like that to distinguish it from capacity_bytes() which is fast. *+ // Total capacity in all Metaspaces* static size_t capacity_in_bytes() { * return capacity_in_bytes(Metaspace::ClassType) +* * capacity_in_bytes(Metaspace::NonClassType);* *+ #ifdef PRODUCT* *+ // Use capacity_bytes() in PRODUCT instead of this function.* *+ guarantee(false, "Should not call capacity_in_bytes() in the PRODUCT");* *+ #endif * Or maybe since capacity_in_bytes() is used for the other counters, change the capacity_bytes() name to allocated_capacity() or something like that. Just so the two names are more different than the presence of "_in". metaspace.cpp: line 270 and 283 are missing an 'n' in accounting. I like the promise of a cleanup. Even with the comment, it's hard to keep these straight. 1199-1201 is the same code as above it. 2520 capacity_in_bytes(mdtype) is still called for PrintGCDetails which iterates over the CLD graph. This seems too expensive for GC printing. It also calls used_in_bytes() so iterates twice. Then x2 for class vs. data metaspace. This wasn't part of the GC slowdown that was observed? 2935. I don't understand why we are checking UseMallocOnly since we don't use malloc for metaspaces ever. I can't comment on the CMS change. It looks like you just moved it. Coleen On 3/27/2013 12:13 AM, Jon Masamitsu wrote: > > Replace the use of a method that calculated the total capacity of > the Metaspaces by iterating over all the Metaspaces by maintaining > the sum of Metaspace capacities as the Metachunks are > allocated to each Metaspace. Also maintain a sum for each > Metaspace as the Metachunks are allocated to that Metaspace. > > Change should_expand() and compute_new_space() to > calculate quantities in bytes. > > Remove calls to methods that calculated totals for > "used" and "free" by iterating over the Metaspaces > in product mode. In some cases substitute the use > of capacity for used. > > http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/ > > Thanks. > > Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Wed Mar 27 22:12:49 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 27 Mar 2013 15:12:49 -0700 Subject: RFR(S): 8010780: G1: Eden occupancy/capacity output wrong after a full GC Message-ID: <51536EE1.1010308@oracle.com> Hi Everyone, Can I have a couple of volunteers look review this fix? The webrev can be found at: http://cr.openjdk.java.net/~johnc/8010780/webrev.0/ Summary: One of the performance team spotted and error in the G1 logs following a full GC: 411.322: [G1Ergonomics (Mixed GCs) (to-space exhausted), 0.4279260 secs] .... [Eden: 0.0B(1840.0M)->0.0B(1840.0M) Survivors: 0.0B->0.0B Heap: 36.0G(36.0G)->36.0G(36.0G)] [Times: user=1.13 sys=0.10, real=0.43 secs] 411.336: [Full GC (Allocation Failure) 35G->18G(36G), 8.0471890 secs] [Times: user=8.50 sys=0.01, real=8.05 secs] 433.639: [GC pause (G1 Evacuation Pause) (young) 433.640: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 26203, predicted base time: 13.50 ms, remaining time: 186.50 ms, target pause time: 200.00 ms] 433.640: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 148 regions, survivors: 0 regions, predicted young region time: 164.22 ms] 433.640: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 148 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 177.72 ms, target pause time: 200.00 ms] 433.895: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 21458059264 bytes, allocation request: 0 bytes, threshold: 17394617520 bytes (45.00 %), source: end of GC] , 0.2552910 secs] .... [Eden: 2368.0M(1840.0M)->0.0B(1632.0M) Survivors: 0.0B->304.0M Heap: 20.7G(36.0G)->20.2G(36.0G)] The heap transition line for the GC after the full GC was displaying the eden capacity that was calculated by the GC preceding the full GC rather than the eden capacity calculated at the end of the of the full GC. As a result the reported eden occupancy is much larger than the reported capacity. The main part of the fix is the moving of G1CollectorPolicy::_prev_eden_capacity from G1CollectorPolicy::print_detailed_heap_transition() to G1CollectorPolicy::record_collection_pause_start(). The code that records the heap state before the GC has been refactored into a separate routine and is invoked at the start of both an incremental and full GC. Additionally I added a more detailed heap transition message to the full GC output: > 1.989: [Full GC (Allocation Failure) 256M->234M(256M), 2.3966795 secs] > [Eden: 0.0B(12.0M)->0.0B(12.0M) Survivors: 0.0B->0.0B Heap: > 256.0M(256.0M)->234.7M(256.0M)] > [Times: user=3.00 sys=0.00, real=2.40 secs] > for validation purposes. Testing: GCOld with a small heap (128m) and +G1PrintHeapRegions Thanks, JohnC From tao.mao at oracle.com Wed Mar 27 22:45:26 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 27 Mar 2013 15:45:26 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <51512A97.2030600@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> <51512A97.2030600@oracle.com> Message-ID: <51537686.1030601@oracle.com> Please see inline. Tao On 3/25/13 9:56 PM, Bengt Rutisson wrote: > > Hi Tao, > > Thanks for updating the tests. Looks good to me. > > Have you tried running the tests? It is a very small change so it > should be ok. But our testing process is very strange and it may be > that these tests are not run until PIT testing, so running them once > before pushing is a good idea to avoid unnecessary issues later on. They have passed the jtreg tests. I'm going to push it. script: jtreg -jdk:/Users/tamao/home/jdk1.8.0_b74_macosx/ \ -vmoption:-tamao \ ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestCMSIncrementalMode.java \ ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestIncGC.java results: Test results: passed: 2 Report written to /Users/tamao/Dropbox/Oracle/JTreport/html/report.html Results written to /Users/tamao/Dropbox/Oracle/JTwork > > Also, I see that you decided not to remove "likely" from the other > messages in Arguments::check_deprecated_gcs(). Would you like to do > that as a separate change or do you think we should leave those > messages unchanged? So what was the decision for deprecating these gc's? To me, there hasn't seemed to be any definitive decision, yet. > > Thanks, > Bengt > > On 3/25/13 7:48 PM, Tao Mao wrote: >> Thank you for pointing it out, Bengt. A new webrev is updated. >> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ >> >> Please see inline. >> Tao >> >> On 3/24/13 1:16 PM, Bengt Rutisson wrote: >>> >>> Hi Tao, >>> >>> On 3/23/13 4:51 AM, Tao Mao wrote: >>>> Thank you for review and suggestion. A new webrev is updated. >>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >>> >>> I like Jon's suggestion about removing the word "likely" but that >>> means that you need to update these tests: >>> >>> test/gc/startup_warnings/TestCMSIncrementalMode.java >>> test/gc/startup_warnings/TestIncGC.java >> Test files modified. >>> >>> Also, would it make sense to remove the word "likely" from the >>> warning messages in Arguments::check_deprecated_gcs() too? In that >>> case you need to update these tests as well: >>> >>> test/gc/startup_warnings/TestDefNewCMS.java >>> test/gc/startup_warnings/TestParNewSerialOld.java >> Have we made a decision to certainly remove these gc comb's in >> future? If so, it's OK to state so. Anyway, it would be better to >> resolve it with a separate CR. >>> >>> Bengt >>> >>>> >>>> Tao >>>> >>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>>> Tao, >>>>> >>>>> Changes look fine. I would remove the "likely" so that messages >>>>> read like >>>>> >>>>> "and will be removed in a future release" >>>>> >>>>> Fewer words are better and the intent is still clear. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>>> A simple changeset. Need a reviewer! >>>>>> >>>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>>> Arguments::check_deprecated_gcs() to >>>>>> Arguments::check_deprecated_gc_flags() >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>>> >>>>>> changeset: >>>>>> Cleanup suggested by Bengt. >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Mar 27 23:13:46 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 27 Mar 2013 16:13:46 -0700 Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions In-Reply-To: <5153613A.4040906@oracle.com> References: <515271FB.9090203@oracle.com> <5153613A.4040906@oracle.com> Message-ID: <51537D2A.4070700@oracle.com> On 3/27/2013 2:14 PM, Coleen Phillimore wrote: > > Hi Jon, > > In metaspace.hpp maybe capacity_in_bytes should be called > capacity_bytes_slow() or something like that to distinguish it from > capacity_bytes() which is fast. > > *+ // Total capacity in all Metaspaces* > static size_t capacity_in_bytes() { > * return capacity_in_bytes(Metaspace::ClassType) +* > * capacity_in_bytes(Metaspace::NonClassType);* > *+ #ifdef PRODUCT* > *+ // Use capacity_bytes() in PRODUCT instead of this function.* > *+ guarantee(false, "Should not call capacity_in_bytes() in the > PRODUCT");* > *+ #endif > > * I like the name capacity_bytes_slow() so made the change capacity_in_bytes -> capacity_bytes_slow > > Or maybe since capacity_in_bytes() is used for the other counters, > change the capacity_bytes() name to allocated_capacity() or something > like that. Just so the two names are more different than the > presence of "_in". I will keep this second suggestion in mind. I'm going to be making some other name changes so may use allocated_capacity. > > metaspace.cpp: > > line 270 and 283 are missing an 'n' in accounting. I like the > promise of a cleanup. Even with the comment, it's hard to keep these > straight. > > 1199-1201 is the same code as above it. Fixed. > > 2520 capacity_in_bytes(mdtype) is still called for PrintGCDetails > which iterates over the CLD graph. This seems too expensive for GC > printing. It also calls used_in_bytes() so iterates twice. Then x2 > for class vs. data metaspace. This wasn't part of the GC slowdown > that was observed? Yes this this is part of the slow down. I don't have a replacement yet for used_in_bytes() yet so thought I would fix this when I replaced used_in_bytes(). I can diff out this code (the code that does data_space and class_space output separately) or I can fix it. Should I just fix it now? > > 2935. I don't understand why we are checking UseMallocOnly since we > don't use malloc for metaspaces ever. That was probably a mis-merge when I started with the malloc-chunks patch. I'll delete it. > > I can't comment on the CMS change. It looks like you just moved it. Yes, I just moved a class up so that I could use it in the "Resizing" phase. Thanks. Jon > > Coleen > > > On 3/27/2013 12:13 AM, Jon Masamitsu wrote: >> >> Replace the use of a method that calculated the total capacity of >> the Metaspaces by iterating over all the Metaspaces by maintaining >> the sum of Metaspace capacities as the Metachunks are >> allocated to each Metaspace. Also maintain a sum for each >> Metaspace as the Metachunks are allocated to that Metaspace. >> >> Change should_expand() and compute_new_space() to >> calculate quantities in bytes. >> >> Remove calls to methods that calculated totals for >> "used" and "free" by iterating over the Metaspaces >> in product mode. In some cases substitute the use >> of capacity for used. >> >> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/ >> >> Thanks. >> >> Jon > > From david.holmes at oracle.com Thu Mar 28 05:31:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2013 15:31:29 +1000 Subject: RFR: 2178143: VM crashes if the number of bound CPUs changed during runtime In-Reply-To: <51534B3B.8020209@oracle.com> References: <514A29BC.7040105@oracle.com> <5150D068.7020803@oracle.com> <5150DA80.4090907@oracle.com> <5150EF71.8040507@oracle.com> <5151326C.8030002@oracle.com> <515134F7.4050007@oracle.com> <5151389C.6060806@oracle.com> <51513986.9030207@oracle.com> <51513E50.7000401@oracle.com> <5151B8C8.7060802@oracle.com> <5151F43F.7000102@oracle.com> <5151FA15.1000104@oracle.com> <5151FAA3.8090402@oracle.com> <51525E3D.6080600@oracle.com> <5152704B.9090302@oracle.com> <51527B7A.1020709@oracle.com> <51532127.1080002@oracle.com> <515337A9.9090509@oracle.com> <515346D9.6010801@oracle.com> <51534B3B.8020209@oracle.com> Message-ID: <5153D5B1.9080802@oracle.com> So if I'm reading this right: + if (AssumeMP && !UseSerialGC) { + if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { The FLAG_IS_DEFAULT will be true if -XX:ParallelGCThreads=N was not specified, even though ParallelGCThreads was subsequently set programmatically to match the number of processors. So we will only warn if: - AssumeMP is true - we're not using serial GC - the user didn't set -XX:ParallelGCThreads - but parallelGCThreads ==1 (indicating one core available) That sounds like what I wanted to, but was unable to, express. Thanks, David On 28/03/2013 5:40 AM, Yumin Qi wrote: > new webrev at same link: > > http://cr.openjdk.java.net/~minqi/2178143/ > > Thanks > Yumin > > On 3/27/2013 12:22 PM, Yumin Qi wrote: >> Jon, >> >> The warning is for a immediate attention, with PrintGCDetail, that >> requires it set on in command line, right? >> >> I also found that with default setting (no GC flavor set), no >> setting for ParallelGCThreads, it will be 0. >> >> so with java -XX:+AssumeMP -version, it will give warning, this is >> not right. >> >> // Set per-collector flags >> if (UseParallelGC || UseParallelOldGC) { >> set_parallel_gc_flags(); >> } else if (UseConcMarkSweepGC) { // should be done before ParNew >> check below >> set_cms_and_parnew_gc_flags(); >> } else if (UseParNewGC) { // skipped if CMS is set above >> set_parnew_gc_flags(); >> } else if (UseG1GC) { >> set_g1_gc_flags(); >> } >> check_deprecated_gcs(); >> check_deprecated_gc_flags(); >> >> With default GC (Btw, what is the default GC collector?), >> ParallelGCThreads = 0. >> >> >> >> So I will change code to: >> >> if (AssumeMP && !UseSerialGC) { >> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads == 1) { >> warning("If the number of processors is expected to increase >> from one, then" >> " you should configure the number of parallel GC threads >> appropriately" >> " using -XX:ParallelGCThreads=N"); >> } >> } >> >> Will send another webrev after test. >> >> Thanks >> Yumin >> >> On 3/27/2013 11:17 AM, Jon Masamitsu wrote: >>> Yumin, >>> >>> How about adding PrintGCDetails to the guard? >>> >>> if (AssumeMP && !UseSerialGC && PrintGCDetails) {. >>> >>> Jon >>> >>> On 3/27/2013 9:41 AM, Yumin Qi wrote: >>>> so the warning should be >>>> >>>> if (AssumeMP && !UseSerialGC) { >>>> if (FLAG_IS_DEFAULT(ParallelGCThreads) && ParallelGCThreads < 2) { >>>> warning("If the number of processors is expected to increase >>>> from one, then" >>>> " you should configure the number of parallel GC >>>> threads appropriately" >>>> " using -XX:ParallelGCThreads=N"); >>>> } >>>> } >>>> >>>> So the warning will only be issued when AssumeMP turned on and the >>>> ncpus =1. If user add cmdline -XX:ParallelGCThreads=1 which is not >>>> the default value 0, so the warning will not be triggered. I will do >>>> a test. >>>> >>>> Is this better? >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/26/2013 9:54 PM, David Holmes wrote: >>>>> On 27/03/2013 2:06 PM, Yumin Qi wrote: >>>>>> David, >>>>>> >>>>>> On 3/26/2013 7:49 PM, David Holmes wrote: >>>>>>> Well now you have confused me. I thought checking >>>>>>> FLAG_IS_DEFAULT(ParallelGCThreads) was the right thing to do (the >>>>>>> user >>>>>>> has not attempted manage the number of GC threads even though they >>>>>>> recognize the number of processors may start at 1 and increase >>>>>>> later). >>>>>>> I do not understand the new <2 test - maybe I really only want 1, >>>>>>> if I >>>>>>> asked for that why should I get a warning ??? >>>>>>> >>>>>> The previous code is issuing the warning before gc set flags >>>>>> (includes >>>>>> ParallelGCThreads), we don't want with AssumeMP turned on, running >>>>>> on a >>>>>> MP issues the warning since ParallelGCThreads will be not 1 but the >>>>>> number of calculation based on ncpus. So I moved the check code >>>>>> after >>>>>> GC set flags. After GC set flags, ParallelGCThreads is not the >>>>>> default >>>>>> value (0) so I check if it is < 2. >>>>> >>>>> I was overlooking the case where you use +AssumeMP but have >>>>> multiple processors anyway. But if I explicitly set >>>>> ParallelGCThreads=1 then I don't expect to get a warning. Not sure >>>>> we can distinguish these cases though. >>>>> >>>>> Again I leave this to you and Jon to finalize. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> If users really want to run with single CPU with -XX:+AssumeMP, >>>>>> giving a >>>>>> warning is reasonable (this is our intention here) --- there is >>>>>> possibility they will increase number of cpus even they don't, >>>>>> that is OK. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>>> But, this is a GC warning (and I think it is misplaced anyway) so if >>>>>>> Jon is happy with this behaviour so be it. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>> On 27/03/2013 5:44 AM, Yumin Qi wrote: >>>>>>>> Sorry, copied wrong link. It is at same link. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/26/2013 12:42 PM, Daniel D. Daugherty wrote: >>>>>>>>> >>>>>>>>> On 3/26/13 1:17 PM, Yumin Qi wrote: >>>>>>>>>> Hi, Jon >>>>>>>>>> >>>>>>>>>> I made a change to the warning condition and move it after >>>>>>>>>> GC flags >>>>>>>>>> are set. I think at this time, ParallelGCThreads has a value >>>>>>>>>> != 0. >>>>>>>>>> Please take a look if it is right. The This is the new webrev: >>>>>>>>>> >>>>>>>>>> http://javaweb.us.oracle.com/~yqi/webrev/2178143/ >>>>>>>>> >>>>>>>>> This webrev isn't accessible outside Oracle... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tested with platform of ncpus > 1 and no ParallelGCThreads >>>>>>>>>> set with >>>>>>>>>> turning on AssumeMP. The warning is gone. >>>>>>>>>> Also tested with ncpus = 1 and the warning is on too. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/26/2013 8:03 AM, Jon Masamitsu wrote: >>>>>>>>>>> If I set AssumeMP on the command line and nothing else >>>>>>>>>>> and am running on a platform where I get ParallelGCThreads > 1, >>>>>>>>>>> am I going to see the warning? If yes, that seems too >>>>>>>>>>> intrusive. >>>>>>>>>>> I can see users hearing about the flag and deciding to include >>>>>>>>>>> it always just to be safe. >>>>>>>>>>> >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> On 3/25/13 11:21 PM, Yumin Qi wrote: >>>>>>>>>>>> You are right, thanks! I misread the INCLUDE. >>>>>>>>>>>> new web in the same link. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/25/2013 11:00 PM, David Holmes wrote: >>>>>>>>>>>>> On 26/03/2013 3:56 PM, Yumin Qi wrote: >>>>>>>>>>>>>> David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/25/2013 10:41 PM, David Holmes wrote: >>>>>>>>>>>>>>> On 26/03/2013 3:30 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> David and All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Changed as suggested by David. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David, I did not move the warning into >>>>>>>>>>>>>>>> set_parallel_gc_flags() >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> except for serial gc, all other GCs will check this >>>>>>>>>>>>>>>> flag, so I >>>>>>>>>>>>>>>> moved it >>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>> #if INCLUDE_ALL_GCS >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> before call set GC flags. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I didn't realize all the other GCs would utilize >>>>>>>>>>>>>>> ParallelGCThreads. >>>>>>>>>>>>>>> Can we at least exclude it for serial GC case? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Serial GC is set here: >>>>>>>>>>>>> >>>>>>>>>>>>> INCLUDE_ALL_GCS allows all GCs including Serial GC. >>>>>>>>>>>>> Otherwise we >>>>>>>>>>>>> only have SerialGC. So you have excluded it for the case where >>>>>>>>>>>>> SerialGC is the only GC built into the VM, but not for the >>>>>>>>>>>>> case >>>>>>>>>>>>> where all GCs are available and the user requests UseSerialGC. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 3253 #if !INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3254 force_serial_gc(); >>>>>>>>>>>>>> 3255 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> So after it moved into >>>>>>>>>>>>>> 3283 #if INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3284 if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>> 3285 warning("If the number of processors is expected to >>>>>>>>>>>>>> increase >>>>>>>>>>>>>> from one, then" >>>>>>>>>>>>>> 3286 " you should configure the number of >>>>>>>>>>>>>> parallel GC >>>>>>>>>>>>>> threads appropriately" >>>>>>>>>>>>>> 3287 " using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>> 3288 } >>>>>>>>>>>>>> 3289 // Set per-collector flags >>>>>>>>>>>>>> 3290 if (UseParallelGC || UseParallelOldGC) { >>>>>>>>>>>>>> 3291 set_parallel_gc_flags(); >>>>>>>>>>>>>> 3292 } else if (UseConcMarkSweepGC) { // should be done >>>>>>>>>>>>>> before >>>>>>>>>>>>>> ParNew >>>>>>>>>>>>>> check below >>>>>>>>>>>>>> 3293 set_cms_and_parnew_gc_flags(); >>>>>>>>>>>>>> 3294 } else if (UseParNewGC) { // skipped if CMS is set >>>>>>>>>>>>>> above >>>>>>>>>>>>>> 3295 set_parnew_gc_flags(); >>>>>>>>>>>>>> 3296 } else if (UseG1GC) { >>>>>>>>>>>>>> 3297 set_g1_gc_flags(); >>>>>>>>>>>>>> 3298 } >>>>>>>>>>>>>> 3299 check_deprecated_gcs(); >>>>>>>>>>>>>> 3300 #else // INCLUDE_ALL_GCS >>>>>>>>>>>>>> 3301 assert(verify_serial_gc_flags(), "SerialGC unset"); >>>>>>>>>>>>>> 3302 #endif // INCLUDE_ALL_GCS >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is excluded for serial GC. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Otherwise looks good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> new webrev: http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/25/2013 5:44 PM, David Holmes wrote: >>>>>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have a few suggested changes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> First in os.hpp I suggest >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> return _processor_count > 1 || AssumeMP ; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That way we don't bypass the assertion and don't encounter >>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>> overhead on the common path. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In arguments.cpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + if (AssumeMP && FLAG_IS_DEFAULT(ParallelGCThreads)) { >>>>>>>>>>>>>>>>> + warning("With AssumeMP, recommend run with >>>>>>>>>>>>>>>>> -XX:ParallelGCThreads=, where" >>>>>>>>>>>>>>>>> + " num_of_gc_threads can be set to number of >>>>>>>>>>>>>>>>> cores"); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not convinced issuing a warning is necessary or >>>>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>>> With a uniprocessor startup will we even default to using >>>>>>>>>>>>>>>>> parallel GC? >>>>>>>>>>>>>>>>> The above should only be issued if using parallel GC - so >>>>>>>>>>>>>>>>> better to >>>>>>>>>>>>>>>>> move it into set_parallel_gc_flags(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In any case it isn't clear what the user should supply >>>>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>>>> If they >>>>>>>>>>>>>>>>> use the maximum expected number of cores initially then >>>>>>>>>>>>>>>>> while >>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>> only have 1 core their VM may not even function >>>>>>>>>>>>>>>>> adequately due >>>>>>>>>>>>>>>>> to GC >>>>>>>>>>>>>>>>> overhead. I think all you can say here is something like: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> warning("If the number of processors is expected to >>>>>>>>>>>>>>>>> increase >>>>>>>>>>>>>>>>> from one, >>>>>>>>>>>>>>>>> then you should configure the number of parallel GC >>>>>>>>>>>>>>>>> threads >>>>>>>>>>>>>>>>> appropriately using -XX:ParallelGCThreads=N"); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In globals.hpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> + product(bool, AssumeMP, false, \ >>>>>>>>>>>>>>>>> + "Assume run on multiple processors always") \ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Was there any discussion on making this default to true >>>>>>>>>>>>>>>>> instead? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Suggested re-wording: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "Instruct the VM to assume multiple processors are >>>>>>>>>>>>>>>>> available" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 26/03/2013 9:15 AM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>> It should be "AssumeMP". >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Yumin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/25/2013 3:32 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> New webrev to use "-XX:+AssumMP" flag. Also add >>>>>>>>>>>>>>>>>>> warning to >>>>>>>>>>>>>>>>>>> recommend >>>>>>>>>>>>>>>>>>> use this flag with "-XX:ParallelGCThreads" to remind >>>>>>>>>>>>>>>>>>> user to >>>>>>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>>>> running with only one GC thread. This is verified by >>>>>>>>>>>>>>>>>>> Oleksandr with >>>>>>>>>>>>>>>>>>> the test case running on Linux which is not Zone >>>>>>>>>>>>>>>>>>> configured. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Same link. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 3/20/2013 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2178143: VM crashes if the number of bound CPUs >>>>>>>>>>>>>>>>>>>> changed >>>>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>>>> runtime. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Situation: Customer first configure only one CPU >>>>>>>>>>>>>>>>>>>> online and >>>>>>>>>>>>>>>>>>>> turn >>>>>>>>>>>>>>>>>>>> others offline to run java application, after java >>>>>>>>>>>>>>>>>>>> program >>>>>>>>>>>>>>>>>>>> started, >>>>>>>>>>>>>>>>>>>> bring more CPUs back online. Since VM started on a >>>>>>>>>>>>>>>>>>>> single >>>>>>>>>>>>>>>>>>>> CPU, >>>>>>>>>>>>>>>>>>>> os::is_MP() will return false, but after more CPUs >>>>>>>>>>>>>>>>>>>> available, OS >>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>> schedule the app run on multiple CPUs, this caused >>>>>>>>>>>>>>>>>>>> SEGV in >>>>>>>>>>>>>>>>>>>> various >>>>>>>>>>>>>>>>>>>> places where data consistency was broken. The >>>>>>>>>>>>>>>>>>>> solution is >>>>>>>>>>>>>>>>>>>> supply a >>>>>>>>>>>>>>>>>>>> flag to assume it is running on MP, so lock is >>>>>>>>>>>>>>>>>>>> forced to be >>>>>>>>>>>>>>>>>>>> called. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/2178143/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From bengt.rutisson at oracle.com Thu Mar 28 06:31:45 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Mar 2013 07:31:45 +0100 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <51537686.1030601@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> <51512A97.2030600@oracle.com> <51537686.1030601@oracle.com> Message-ID: <5153E3D1.2040002@oracle.com> Hi Tao, On 3/27/13 11:45 PM, Tao Mao wrote: > Please see inline. > Tao > > On 3/25/13 9:56 PM, Bengt Rutisson wrote: >> >> Hi Tao, >> >> Thanks for updating the tests. Looks good to me. >> >> Have you tried running the tests? It is a very small change so it >> should be ok. But our testing process is very strange and it may be >> that these tests are not run until PIT testing, so running them once >> before pushing is a good idea to avoid unnecessary issues later on. > They have passed the jtreg tests. I'm going to push it. > > script: > jtreg -jdk:/Users/tamao/home/jdk1.8.0_b74_macosx/ \ > -vmoption:-tamao \ > ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestCMSIncrementalMode.java > \ > ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestIncGC.java > > results: > Test results: passed: 2 > Report written to /Users/tamao/Dropbox/Oracle/JTreport/html/report.html > Results written to /Users/tamao/Dropbox/Oracle/JTwork Great! Thanks! >> >> Also, I see that you decided not to remove "likely" from the other >> messages in Arguments::check_deprecated_gcs(). Would you like to do >> that as a separate change or do you think we should leave those >> messages unchanged? > So what was the decision for deprecating these gc's? To me, there > hasn't seemed to be any definitive decision, yet. It is the same decision as for CMSIncrementalMode, where you removed the "likely". Bengt >> >> Thanks, >> Bengt >> >> On 3/25/13 7:48 PM, Tao Mao wrote: >>> Thank you for pointing it out, Bengt. A new webrev is updated. >>> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ >>> >>> Please see inline. >>> Tao >>> >>> On 3/24/13 1:16 PM, Bengt Rutisson wrote: >>>> >>>> Hi Tao, >>>> >>>> On 3/23/13 4:51 AM, Tao Mao wrote: >>>>> Thank you for review and suggestion. A new webrev is updated. >>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >>>> >>>> I like Jon's suggestion about removing the word "likely" but that >>>> means that you need to update these tests: >>>> >>>> test/gc/startup_warnings/TestCMSIncrementalMode.java >>>> test/gc/startup_warnings/TestIncGC.java >>> Test files modified. >>>> >>>> Also, would it make sense to remove the word "likely" from the >>>> warning messages in Arguments::check_deprecated_gcs() too? In that >>>> case you need to update these tests as well: >>>> >>>> test/gc/startup_warnings/TestDefNewCMS.java >>>> test/gc/startup_warnings/TestParNewSerialOld.java >>> Have we made a decision to certainly remove these gc comb's in >>> future? If so, it's OK to state so. Anyway, it would be better to >>> resolve it with a separate CR. >>>> >>>> Bengt >>>> >>>>> >>>>> Tao >>>>> >>>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>>>> Tao, >>>>>> >>>>>> Changes look fine. I would remove the "likely" so that messages >>>>>> read like >>>>>> >>>>>> "and will be removed in a future release" >>>>>> >>>>>> Fewer words are better and the intent is still clear. >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>>>> A simple changeset. Need a reviewer! >>>>>>> >>>>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>>>> Arguments::check_deprecated_gcs() to >>>>>>> Arguments::check_deprecated_gc_flags() >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>>>> >>>>>>> changeset: >>>>>>> Cleanup suggested by Bengt. >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Mar 28 10:45:35 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Mar 2013 11:45:35 +0100 Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions In-Reply-To: <51537D2A.4070700@oracle.com> References: <515271FB.9090203@oracle.com> <5153613A.4040906@oracle.com> <51537D2A.4070700@oracle.com> Message-ID: <51541F4F.4060300@oracle.com> Jon, I have some comments and I've replied to your discussion with Coleen inline. In MetaspaceGC::should_expand it looks like you reverted part of the change I did for JDK-8004241. I still believe that checking the value of capacity when deciding weather to expand is wrong because should_expand is used to decide when we should reserve more address space, not commit more memory out of already reserved address space. In addition to that, checking MaxMetaspaceSize against MetaspaceAux::capacity_byte() seems unintuitive compared MaxHeapSize. MaxHeapSize limits the amount of address space we reserve for the Java heap, that of course implies that the amount of memory we commit for the Java heap is also bounded. I think that MaxMetaspaceSize should work in a similar manner. It should limit the amount of address space we reserve and thereby it will enforce a limit of how much memory we commit as well. In psParallelCompact, PreGCValues::fill you call MetaspaceAux::capacity_words() and multiply by BytesPerWord instead of calling capacity_bytes() Instead of adding calls to verify_capacity() after calls to purge(), can't you call verify_capacity() from inside purge()? I think that the atomics you added in MetaspaceAux::{inc,dec}_capacity and SpaceManager::inc_allocation_metrics are unnecessary since it looks like all the callers hold the expand_lock(). That can probably be asserted with assert_lock_strong calls. For the overall used versus capacity in MetaspaceCounters I think it's ok to that we will report the amount of memory in chunks which have are not on the free list as the "used" value, at least for now. On 2013-03-28 00:13, Jon Masamitsu wrote: > > On 3/27/2013 2:14 PM, Coleen Phillimore wrote: >> >> Hi Jon, >> >> In metaspace.hpp maybe capacity_in_bytes should be called >> capacity_bytes_slow() or something like that to distinguish it from >> capacity_bytes() which is fast. >> >> *+ // Total capacity in all Metaspaces* >> static size_t capacity_in_bytes() { >> * return capacity_in_bytes(Metaspace::ClassType) +* >> * capacity_in_bytes(Metaspace::NonClassType);* >> *+ #ifdef PRODUCT* >> *+ // Use capacity_bytes() in PRODUCT instead of this function.* >> *+ guarantee(false, "Should not call capacity_in_bytes() in the >> PRODUCT");* >> *+ #endif >> >> * > > I like the name capacity_bytes_slow() so made the change > capacity_in_bytes -> capacity_bytes_slow >> >> Or maybe since capacity_in_bytes() is used for the other counters, >> change the capacity_bytes() name to allocated_capacity() or something >> like that. Just so the two names are more different than the >> presence of "_in". > > I will keep this second suggestion in mind. I'm going to be making some > other name changes > so may use allocated_capacity. > >> >> metaspace.cpp: >> >> line 270 and 283 are missing an 'n' in accounting. I like the >> promise of a cleanup. Even with the comment, it's hard to keep these >> straight. >> >> 1199-1201 is the same code as above it. > > Fixed. > >> >> 2520 capacity_in_bytes(mdtype) is still called for PrintGCDetails >> which iterates over the CLD graph. This seems too expensive for GC >> printing. It also calls used_in_bytes() so iterates twice. Then x2 >> for class vs. data metaspace. This wasn't part of the GC slowdown >> that was observed? > > Yes this this is part of the slow down. I don't have a replacement yet > for used_in_bytes() yet so thought I > would fix this when I replaced used_in_bytes(). I can diff out this code > (the code that does data_space and class_space output separately) or > I can fix it. Should I just fix it now? How about this: Move the running count of allocated chunk bytes to the ChunkManager or VirtualSpaceList classes, then allocated chunks of ClassType and NonClassType are accounted separately and we can simply add them together for the total. > >> >> 2935. I don't understand why we are checking UseMallocOnly since we >> don't use malloc for metaspaces ever. > > That was probably a mis-merge when I started with the malloc-chunks > patch. I'll > delete it. No, that's much much older :) As I remember it's from before the metachunk allocation scheme was integrated into hotspot-metadata. But I agree that it should be removed, now it doesn't make any sense whatsoever. > >> >> I can't comment on the CMS change. It looks like you just moved it. > > Yes, I just moved a class up so that I could use it in the "Resizing" > phase. For JDK-8009894 I'm planning on adding some more code to the "Resizing" case. As part of that Stefan wanted me to break out part of that case in to a method in order to not make collect_in_background even bigger. Do you think it's time for a CMSCollector::resize() and moving of some of the code in the case there? /Mikael > > Thanks. > > Jon > >> >> Coleen >> >> >> On 3/27/2013 12:13 AM, Jon Masamitsu wrote: >>> >>> Replace the use of a method that calculated the total capacity of >>> the Metaspaces by iterating over all the Metaspaces by maintaining >>> the sum of Metaspace capacities as the Metachunks are >>> allocated to each Metaspace. Also maintain a sum for each >>> Metaspace as the Metachunks are allocated to that Metaspace. >>> >>> Change should_expand() and compute_new_space() to >>> calculate quantities in bytes. >>> >>> Remove calls to methods that calculated totals for >>> "used" and "free" by iterating over the Metaspaces >>> in product mode. In some cases substitute the use >>> of capacity for used. >>> >>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/ >>> >>> Thanks. >>> >>> Jon >> >> > From mikael.gerdin at oracle.com Thu Mar 28 15:11:46 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Thu, 28 Mar 2013 15:11:46 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine Message-ID: <20130328151150.B442648469@hg.openjdk.java.net> Changeset: 2e093b564241 Author: mgerdin Date: 2013-03-28 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2e093b564241 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine Summary: Keep a counter of how many times we were stalled by the GC locker, add a diagnostic flag which sets the limit. Reviewed-by: brutisso, ehelin, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/globals.hpp From tao.mao at oracle.com Thu Mar 28 17:50:41 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 28 Mar 2013 10:50:41 -0700 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <5153E3D1.2040002@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> <51512A97.2030600@oracle.com> <51537686.1030601@oracle.com> <5153E3D1.2040002@oracle.com> Message-ID: <515482F1.5070002@oracle.com> Hi Bengt, On 3/27/2013 11:31 PM, Bengt Rutisson wrote: > > Hi Tao, > > On 3/27/13 11:45 PM, Tao Mao wrote: >> Please see inline. >> Tao >> >> On 3/25/13 9:56 PM, Bengt Rutisson wrote: >>> >>> Hi Tao, >>> >>> Thanks for updating the tests. Looks good to me. >>> >>> Have you tried running the tests? It is a very small change so it >>> should be ok. But our testing process is very strange and it may be >>> that these tests are not run until PIT testing, so running them once >>> before pushing is a good idea to avoid unnecessary issues later on. >> They have passed the jtreg tests. I'm going to push it. >> >> script: >> jtreg -jdk:/Users/tamao/home/jdk1.8.0_b74_macosx/ \ >> -vmoption:-tamao \ >> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestCMSIncrementalMode.java >> \ >> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestIncGC.java >> >> results: >> Test results: passed: 2 >> Report written to /Users/tamao/Dropbox/Oracle/JTreport/html/report.html >> Results written to /Users/tamao/Dropbox/Oracle/JTwork > > Great! Thanks! > >>> >>> Also, I see that you decided not to remove "likely" from the other >>> messages in Arguments::check_deprecated_gcs(). Would you like to do >>> that as a separate change or do you think we should leave those >>> messages unchanged? >> So what was the decision for deprecating these gc's? To me, there >> hasn't seemed to be any definitive decision, yet. > > It is the same decision as for CMSIncrementalMode, where you removed > the "likely". > > Bengt Where is the latest update regarding this issue? Any mail thread, or web? Thank you. Tao > >>> >>> Thanks, >>> Bengt >>> >>> On 3/25/13 7:48 PM, Tao Mao wrote: >>>> Thank you for pointing it out, Bengt. A new webrev is updated. >>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ >>>> >>>> Please see inline. >>>> Tao >>>> >>>> On 3/24/13 1:16 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi Tao, >>>>> >>>>> On 3/23/13 4:51 AM, Tao Mao wrote: >>>>>> Thank you for review and suggestion. A new webrev is updated. >>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >>>>> >>>>> I like Jon's suggestion about removing the word "likely" but that >>>>> means that you need to update these tests: >>>>> >>>>> test/gc/startup_warnings/TestCMSIncrementalMode.java >>>>> test/gc/startup_warnings/TestIncGC.java >>>> Test files modified. >>>>> >>>>> Also, would it make sense to remove the word "likely" from the >>>>> warning messages in Arguments::check_deprecated_gcs() too? In that >>>>> case you need to update these tests as well: >>>>> >>>>> test/gc/startup_warnings/TestDefNewCMS.java >>>>> test/gc/startup_warnings/TestParNewSerialOld.java >>>> Have we made a decision to certainly remove these gc comb's in >>>> future? If so, it's OK to state so. Anyway, it would be better to >>>> resolve it with a separate CR. >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> Tao >>>>>> >>>>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>>>>> Tao, >>>>>>> >>>>>>> Changes look fine. I would remove the "likely" so that messages >>>>>>> read like >>>>>>> >>>>>>> "and will be removed in a future release" >>>>>>> >>>>>>> Fewer words are better and the intent is still clear. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>>>>> A simple changeset. Need a reviewer! >>>>>>>> >>>>>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>>>>> Arguments::check_deprecated_gcs() to >>>>>>>> Arguments::check_deprecated_gc_flags() >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>>>>> >>>>>>>> changeset: >>>>>>>> Cleanup suggested by Bengt. >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Mar 28 18:09:03 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Mar 2013 19:09:03 +0100 Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode from Arguments::check_deprecated_gcs() to Arguments::check_deprecated_gc_flags() In-Reply-To: <515482F1.5070002@oracle.com> References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com> <514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com> <51509C17.6080808@oracle.com> <51512A97.2030600@oracle.com> <51537686.1030601@oracle.com> <5153E3D1.2040002@oracle.com> <515482F1.5070002@oracle.com> Message-ID: <5154873F.60002@oracle.com> On 3/28/13 6:50 PM, Tao Mao wrote: > Hi Bengt, > > On 3/27/2013 11:31 PM, Bengt Rutisson wrote: >> >> Hi Tao, >> >> On 3/27/13 11:45 PM, Tao Mao wrote: >>> Please see inline. >>> Tao >>> >>> On 3/25/13 9:56 PM, Bengt Rutisson wrote: >>>> >>>> Hi Tao, >>>> >>>> Thanks for updating the tests. Looks good to me. >>>> >>>> Have you tried running the tests? It is a very small change so it >>>> should be ok. But our testing process is very strange and it may be >>>> that these tests are not run until PIT testing, so running them >>>> once before pushing is a good idea to avoid unnecessary issues >>>> later on. >>> They have passed the jtreg tests. I'm going to push it. >>> >>> script: >>> jtreg -jdk:/Users/tamao/home/jdk1.8.0_b74_macosx/ \ >>> -vmoption:-tamao \ >>> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestCMSIncrementalMode.java >>> \ >>> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestIncGC.java >>> >>> results: >>> Test results: passed: 2 >>> Report written to /Users/tamao/Dropbox/Oracle/JTreport/html/report.html >>> Results written to /Users/tamao/Dropbox/Oracle/JTwork >> >> Great! Thanks! >> >>>> >>>> Also, I see that you decided not to remove "likely" from the other >>>> messages in Arguments::check_deprecated_gcs(). Would you like to do >>>> that as a separate change or do you think we should leave those >>>> messages unchanged? >>> So what was the decision for deprecating these gc's? To me, there >>> hasn't seemed to be any definitive decision, yet. >> >> It is the same decision as for CMSIncrementalMode, where you removed >> the "likely". >> >> Bengt > Where is the latest update regarding this issue? Any mail thread, or web? I think the JEP is pretty clear about it: http://openjdk.java.net/jeps/173 " The DefNew + CMS and ParNew + SerialOld combinations and the Incremental Mode of CMS will be deprecated (logging a warning message). This is to be interpreted as that these GC combinations will be removed in some upcoming major release." Bengt > > Thank you. > Tao > >> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> On 3/25/13 7:48 PM, Tao Mao wrote: >>>>> Thank you for pointing it out, Bengt. A new webrev is updated. >>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/ >>>>> >>>>> Please see inline. >>>>> Tao >>>>> >>>>> On 3/24/13 1:16 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Tao, >>>>>> >>>>>> On 3/23/13 4:51 AM, Tao Mao wrote: >>>>>>> Thank you for review and suggestion. A new webrev is updated. >>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/ >>>>>> >>>>>> I like Jon's suggestion about removing the word "likely" but that >>>>>> means that you need to update these tests: >>>>>> >>>>>> test/gc/startup_warnings/TestCMSIncrementalMode.java >>>>>> test/gc/startup_warnings/TestIncGC.java >>>>> Test files modified. >>>>>> >>>>>> Also, would it make sense to remove the word "likely" from the >>>>>> warning messages in Arguments::check_deprecated_gcs() too? In >>>>>> that case you need to update these tests as well: >>>>>> >>>>>> test/gc/startup_warnings/TestDefNewCMS.java >>>>>> test/gc/startup_warnings/TestParNewSerialOld.java >>>>> Have we made a decision to certainly remove these gc comb's in >>>>> future? If so, it's OK to state so. Anyway, it would be better to >>>>> resolve it with a separate CR. >>>>>> >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Tao >>>>>>> >>>>>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote: >>>>>>>> Tao, >>>>>>>> >>>>>>>> Changes look fine. I would remove the "likely" so that >>>>>>>> messages read like >>>>>>>> >>>>>>>> "and will be removed in a future release" >>>>>>>> >>>>>>>> Fewer words are better and the intent is still clear. >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> >>>>>>>> On 3/21/2013 4:23 PM, Tao Mao wrote: >>>>>>>>> A simple changeset. Need a reviewer! >>>>>>>>> >>>>>>>>> 8010518 Move deprecating CMSIncrementalMode from >>>>>>>>> Arguments::check_deprecated_gcs() to >>>>>>>>> Arguments::check_deprecated_gc_flags() >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518 >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/ >>>>>>>>> >>>>>>>>> changeset: >>>>>>>>> Cleanup suggested by Bengt. >>>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Thu Mar 28 18:36:40 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 28 Mar 2013 11:36:40 -0700 Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions In-Reply-To: <51541F4F.4060300@oracle.com> References: <515271FB.9090203@oracle.com> <5153613A.4040906@oracle.com> <51537D2A.4070700@oracle.com> <51541F4F.4060300@oracle.com> Message-ID: <51548DB8.9090100@oracle.com> Mikael, Thanks for the review. Replies below. On 03/28/13 03:45, Mikael Gerdin wrote: > Jon, > > I have some comments and I've replied to your discussion with Coleen > inline. > > In MetaspaceGC::should_expand it looks like you reverted part of the > change I did for JDK-8004241. > I still believe that checking the value of capacity when deciding > weather to expand is wrong because should_expand is used to decide > when we should reserve more address space, not commit more memory out > of already reserved address space. I've changed that code to be the same as in the baseline. > bool MetaspaceGC::should_expand(VirtualSpaceList* vsl, size_t word_size) { > > size_t committed_capacity_bytes = > MetaspaceAux::allocated_capacity_bytes(); > // If the user wants a limit, impose one. > size_t max_metaspace_size_bytes = MaxMetaspaceSize; > size_t metaspace_size_bytes = MetaspaceSize; > if (!FLAG_IS_DEFAULT(MaxMetaspaceSize) && > MetaspaceAux::reserved_in_bytes() >= MaxMetaspaceSize) { > return false; > } > In addition to that, checking MaxMetaspaceSize against > MetaspaceAux::capacity_byte() seems unintuitive compared MaxHeapSize. > MaxHeapSize limits the amount of address space we reserve for the Java > heap, that of course implies that the amount of memory we commit for > the Java heap is also bounded. I think that MaxMetaspaceSize should > work in a similar manner. It should limit the amount of address space > we reserve and thereby it will enforce a limit of how much memory we > commit as well. This is not a separate issue, right? Reverting to the above fixes this. > > In psParallelCompact, PreGCValues::fill you call > MetaspaceAux::capacity_words() and multiply by BytesPerWord instead of > calling capacity_bytes() Fixed. > > Instead of adding calls to verify_capacity() after calls to purge(), > can't you call verify_capacity() from inside purge()? I cannot do that for CMS because the purge() is being done during a concurrent phase and class loading can be happening. I didn't want to add more locking and I think that if the verification works for the other GC's then there isn't anything special about CMS with regard to metadata allocation. > > I think that the atomics you added in > MetaspaceAux::{inc,dec}_capacity and > SpaceManager::inc_allocation_metrics are unnecessary since it looks > like all the callers hold the expand_lock(). That can probably be > asserted with assert_lock_strong calls. I'll try it. > > For the overall used versus capacity in MetaspaceCounters I think it's > ok to that we will report the amount of memory in chunks which have > are not on the free list as the "used" value, at least for now. I'm working on fixing this in response to Coleen's comments. > > > > > On 2013-03-28 00:13, Jon Masamitsu wrote: >> >> On 3/27/2013 2:14 PM, Coleen Phillimore wrote: >>> >>> Hi Jon, >>> >>> In metaspace.hpp maybe capacity_in_bytes should be called >>> capacity_bytes_slow() or something like that to distinguish it from >>> capacity_bytes() which is fast. >>> >>> *+ // Total capacity in all Metaspaces* >>> static size_t capacity_in_bytes() { >>> * return capacity_in_bytes(Metaspace::ClassType) +* >>> * capacity_in_bytes(Metaspace::NonClassType);* >>> *+ #ifdef PRODUCT* >>> *+ // Use capacity_bytes() in PRODUCT instead of this function.* >>> *+ guarantee(false, "Should not call capacity_in_bytes() in the >>> PRODUCT");* >>> *+ #endif >>> >>> * >> >> I like the name capacity_bytes_slow() so made the change >> capacity_in_bytes -> capacity_bytes_slow >>> >>> Or maybe since capacity_in_bytes() is used for the other counters, >>> change the capacity_bytes() name to allocated_capacity() or something >>> like that. Just so the two names are more different than the >>> presence of "_in". >> >> I will keep this second suggestion in mind. I'm going to be making some >> other name changes >> so may use allocated_capacity. >> >>> >>> metaspace.cpp: >>> >>> line 270 and 283 are missing an 'n' in accounting. I like the >>> promise of a cleanup. Even with the comment, it's hard to keep these >>> straight. >>> >>> 1199-1201 is the same code as above it. >> >> Fixed. >> >>> >>> 2520 capacity_in_bytes(mdtype) is still called for PrintGCDetails >>> which iterates over the CLD graph. This seems too expensive for GC >>> printing. It also calls used_in_bytes() so iterates twice. Then x2 >>> for class vs. data metaspace. This wasn't part of the GC slowdown >>> that was observed? >> >> Yes this this is part of the slow down. I don't have a replacement yet >> for used_in_bytes() yet so thought I >> would fix this when I replaced used_in_bytes(). I can diff out this >> code >> (the code that does data_space and class_space output separately) or >> I can fix it. Should I just fix it now? > > How about this: > > Move the running count of allocated chunk bytes to the ChunkManager or > VirtualSpaceList classes, then allocated chunks of ClassType and > NonClassType are accounted separately and we can simply add them > together for the total. I think I'm fixing the this problem. Let me know when I send out the fix. > > > >> >>> >>> 2935. I don't understand why we are checking UseMallocOnly since we >>> don't use malloc for metaspaces ever. >> >> That was probably a mis-merge when I started with the malloc-chunks >> patch. I'll >> delete it. > > No, that's much much older :) > As I remember it's from before the metachunk allocation scheme was > integrated into hotspot-metadata. > But I agree that it should be removed, now it doesn't make any sense > whatsoever. Done. > >> >>> >>> I can't comment on the CMS change. It looks like you just moved it. >> >> Yes, I just moved a class up so that I could use it in the "Resizing" >> phase. > > For JDK-8009894 I'm planning on adding some more code to the > "Resizing" case. As part of that Stefan wanted me to break out part of > that case in to a method in order to not make collect_in_background > even bigger. I was (holding my breathe) looking for your changes when I merged. I guested that you were holding them back. > Do you think it's time for a CMSCollector::resize() and moving of some > of the code in the case there? I originally put the code to trace the resizing in there because I was doing the purge() at that point and wanted to have some indication when the purge was happening. When I merged I accepted the change that had the purge() in sweep() so adding the tracing code is less interesting. I can delete it and wait for you changes. In fact I will delete it. Jon > > /Mikael > >> >> Thanks. >> >> Jon >> >>> >>> Coleen >>> >>> >>> On 3/27/2013 12:13 AM, Jon Masamitsu wrote: >>>> >>>> Replace the use of a method that calculated the total capacity of >>>> the Metaspaces by iterating over all the Metaspaces by maintaining >>>> the sum of Metaspace capacities as the Metachunks are >>>> allocated to each Metaspace. Also maintain a sum for each >>>> Metaspace as the Metachunks are allocated to that Metaspace. >>>> >>>> Change should_expand() and compute_new_space() to >>>> calculate quantities in bytes. >>>> >>>> Remove calls to methods that calculated totals for >>>> "used" and "free" by iterating over the Metaspaces >>>> in product mode. In some cases substitute the use >>>> of capacity for used. >>>> >>>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/ >>>> >>>> Thanks. >>>> >>>> Jon >>> >>> >> From jesper.wilhelmsson at oracle.com Thu Mar 28 18:50:56 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 28 Mar 2013 19:50:56 +0100 Subject: RFR: 8008916 G1: Evacuation failed tracing event Message-ID: <51549110.2010208@oracle.com> Hi, A new version of the evacuation failed event for G1. Now, each thread sends an event with the info it has collected during the collection in the same way as the other collectors do with promotion failed events. Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/ Thanks, /Jesper From bengt.rutisson at oracle.com Thu Mar 28 21:20:39 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Mar 2013 22:20:39 +0100 Subject: RFR: 8008916 G1: Evacuation failed tracing event In-Reply-To: <51549110.2010208@oracle.com> References: <51549110.2010208@oracle.com> Message-ID: <5154B427.2060503@oracle.com> Jesper, This looks much better! Have you tested it to see that you get a maximum of one event per GC thread and GC? It looks to me like you risk getting multiple events sent for each GC thread every GC. You send the events in the G1ParScanThreadState destructor. I am not that familiar with G1ParScanThreadState but it looks to me like we create new G1ParScanThreadState instances for the different phases of a GC. Here are the places where we create new instances of G1ParScanThreadState: G1CollectedHeap::process_discovered_references() G1ParPreserveCMReferentsTask::work() G1ParTask::work() G1STWRefProcTaskProxy::work() So, it looks to me like we risk getting 4 events sent per thread and GC. Some minor comments: In G1CollectedHeap::handle_evacuation_failure_par() you pass the ef_info on to G1CollectedHeap::handle_evacuation_failure_common(). But the ef_info is now thread local so you don't have to take the lock to use it. One way to simplify this would be to do "ef_info->register_copy_failure(old->size());" in G1CollectedHeap::handle_evacuation_failure_par() just before "if (_evac_failure_closure != cl)" instead. Then you don't have to pass it on to handle_evacuation_failure_common(). (As a side note, I don't think setting _evacuation_failed to true has to be protected by the lock either. It is a shared variable but all writes to it from different threads will be to set it to true, so I think racing on it is benign. But you have it in the same place as before, which might be good.) In G1ParCopyClosure::copy_to_survivor_space() you are now picking out two thing from the _par_scan_state and passing them on to G1CollectedHeap::handle_evacuation_failure_par(). Have you considered passing a reference to _par_scan_state instead and let handle_evacuation_failure_par() extract the data it needs? If you move the implementation of the destructor of G1ParScanThreadState in to the cpp file you don't have to add the include for gcTrace.hpp to g1CollectedHeap.hpp. Why did you decide to remove set_evactuation_failed()? Finally, you have several quite unrelated spelling corrections in this change. This makes it a bit hard to review. I'm not sure I think it is worth the extra review time to get those fixed. Bengt On 3/28/13 7:50 PM, Jesper Wilhelmsson wrote: > Hi, > > A new version of the evacuation failed event for G1. Now, each thread > sends an event with the info it has collected during the collection in > the same way as the other collectors do with promotion failed events. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/ > > Thanks, > /Jesper From bengt.rutisson at oracle.com Thu Mar 28 22:09:30 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Mar 2013 23:09:30 +0100 Subject: RFE (m) (Prelminary): JDK-7197666: java -d64 -version core dumps in a box with lots of memory Message-ID: <5154BF9A.2080208@oracle.com> Hi all, Sending this to both runtime and GC since I think it concerns both areas. I'd like some feedback on this preliminary change. I still want to do some more testing and evaluation before I ask for final reviews: http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/ In particular I would like some feedback on these questions: - I am adding a flag that has the same value on all platforms except Solaris x86. There is the product_pd flag macro to support this. But there is no experimental_pd marcro. I would have preferred to make my new flag experimental. Should I add experimental_pd or should I just use a product flag? - Even with product_pd I think I still have to go in to all the different platform files and add the exact same code to give the flag a default value on all platforms. Is there a way to have a default value and only override it on Solaris x86? - The class I am adding, ArrayAllocator, wants to choose between doing malloc and mmap. Normally we use ReservedSpace and VirtualSpace to get mapped memory. However, those classes are kind of clumsy when I just want to allocate one chunk of memory. It is much simpler to use the os::reserve_memory() and os::commit_memory() methods directly. I think my use case here motivate using these methods directly, but is there some reason not to do that? Some background on the change: The default implementation of malloc on Solaris has several limitation compared to malloc on other platforms. One limitation is that it can only use one consecutive chunk of memory. Another limitation is that it always allocates in this single chunk of memory no matter how large the requested amount of memory is. Other malloc implementations normally use mapped memory for large allocations. The Java heap is mapped in memory and we try to pick a good address for it. The lowest allowed address is controlled by HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other platforms have at least 2 GB). Since the C heap ends up below the Java heap it means that in some cases it is limited to 256 MB. When we run with ParallelOldGC we get three task queues per GC thread. Each task queue takes mallocs 1MB. The failing machine in the bug report has lots of CPUs and ends up with 83 GC threads. This is 249 MB, which is more than we can get out of the 256 MB limited C heap considering that there are other things that get malloced too. So, the problems occur mostly on Solaris x86. My suggested fix tries to address this by letting the task queues be mapped instead of malloced on Solaris x86. Instead of inlining this logic in taskqueue.cpp I added a more general class. The reason for this is that I think we need to use the same logic in more places, especially for G1, which is mallocing quite a lot. Since I think malloc on other platforms use mapped memory for large malloc requests I think it is enough for this change to have effect on Solaris. The other platforms probably have better heuristics than I can come up with for which sizes should be mapped. On Sparc we have the same limitation with malloc, but we have more memory available for the C heap. This is why I have only enabled this for Solaris x86. Also, I will be on vacation for a few days. Back in the office Thrusday April 4. I'm happy for any feedback on this, but if I don't respond until next week you know why :) Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.coomes at oracle.com Fri Mar 29 03:52:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:52:20 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b83 for changeset a1dcc0d83da1 Message-ID: <20130329035226.0003A484A4@hg.openjdk.java.net> Changeset: 54c29eb352e7 Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/54c29eb352e7 Added tag jdk8-b83 for changeset a1dcc0d83da1 ! .hgtags From john.coomes at oracle.com Fri Mar 29 03:51:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:51:55 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b83 for changeset 466685ba01bf Message-ID: <20130329035155.845C3484A1@hg.openjdk.java.net> Changeset: d409b4cdb74f Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/d409b4cdb74f Added tag jdk8-b83 for changeset 466685ba01bf ! .hgtags From john.coomes at oracle.com Fri Mar 29 03:52:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:52:06 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b83 for changeset a46d69a1a8ec Message-ID: <20130329035215.78A66484A3@hg.openjdk.java.net> Changeset: f5f40094ffcc Author: katleman Date: 2013-03-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/f5f40094ffcc Added tag jdk8-b83 for changeset a46d69a1a8ec ! .hgtags From john.coomes at oracle.com Fri Mar 29 03:51:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:51:59 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b83 for changeset a45bb25a67c7 Message-ID: <20130329035202.61434484A2@hg.openjdk.java.net> Changeset: 14f1babaf548 Author: katleman Date: 2013-03-28 10:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/14f1babaf548 Added tag jdk8-b83 for changeset a45bb25a67c7 ! .hgtags From john.coomes at oracle.com Fri Mar 29 03:52:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:52:35 +0000 Subject: hg: hsx/hotspot-gc/jdk: 3 new changesets Message-ID: <20130329035403.670FD484A5@hg.openjdk.java.net> Changeset: 6782f2c46bca Author: wetmore Date: 2013-03-21 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6782f2c46bca 8009517: new code changes causing errors in old build (-Werror) environment Reviewed-by: mduigou ! make/com/sun/org/apache/xml/Makefile ! make/javax/others/Makefile Changeset: ac519af51769 Author: dcherepanov Date: 2013-03-27 08:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ac519af51769 Merge Changeset: 8cc500af2454 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8cc500af2454 Added tag jdk8-b83 for changeset ac519af51769 ! .hgtags From john.coomes at oracle.com Fri Mar 29 03:55:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:55:06 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b83 for changeset 22ba3f92d4ae Message-ID: <20130329035518.3E982484A6@hg.openjdk.java.net> Changeset: 35cef52b0023 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/35cef52b0023 Added tag jdk8-b83 for changeset 22ba3f92d4ae ! .hgtags From john.coomes at oracle.com Fri Mar 29 03:55:23 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 29 Mar 2013 03:55:23 +0000 Subject: hg: hsx/hotspot-gc/nashorn: Added tag jdk8-b83 for changeset 053d7c55dc82 Message-ID: <20130329035525.41599484A7@hg.openjdk.java.net> Changeset: fbbdef940138 Author: katleman Date: 2013-03-28 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/fbbdef940138 Added tag jdk8-b83 for changeset 053d7c55dc82 ! .hgtags From jon.masamitsu at oracle.com Fri Mar 29 06:47:02 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 29 Mar 2013 06:47:02 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7112912: Message "Error occurred during initialization of VM" on boxes with lots of RAM Message-ID: <20130329064707.72A6D484B2@hg.openjdk.java.net> Changeset: 754c24457b20 Author: tschatzl Date: 2013-03-27 19:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/754c24457b20 7112912: Message "Error occurred during initialization of VM" on boxes with lots of RAM Summary: Ergonomics now also takes available virtual memory into account when deciding for a heap size. The helper method to determine the maximum allocatable memory block now uses the appropriate OS specific calls to retrieve available virtual memory for the java process. In 32 bit environments this method now also searches for the maximum actually reservable amount of memory. Merge previously separate implementations for Linux/BSD/Solaris into a single method. Reviewed-by: jmasa, tamao ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp From thomas.schatzl at oracle.com Fri Mar 29 08:51:54 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Mar 2013 09:51:54 +0100 Subject: RFR (XXS): 8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose Message-ID: <1364547114.2821.11.camel@cirrus> Hi all, please review the following change for 8005857: In this issue, code checks whether the gc locker is active during heap expansion to print a message that instead of gc the heap has been expanded. The code used the method GCLocker::is_active() to get the gc locker state, but is_active() asserts when the VM is currently not at a safepoint and no GC is actually needed. This assert does not hold in all cases while expanding the heap. E.g. heap expansion may be done outside of a safepoint when satisfying an allocation request for a large object. Heap expansion may occur also when no GC is pending in the gc locker. Imho the previous use of is_active() was wrong not only because of the assert. The message text notifies of the avoidance of a gc. However, the condition did not check whether the gc locker indicated the need for a gc, i.e. did not check the GCLocker::needs_gc() predicate. This change uses GCLocker::is_active_and_needs_gc() instead of GCLocker::is_active(). Which does not check whether the vm is at a safepoint, and also checks whether a gc is actually pending. Jon M. suggested this fix. JIRA: https://jbs.oracle.com/bugs/browse/JDK-8005857 bugs.sun: http://bugs.sun.com/view_bug.do?bug_id=8005857 Testing: jprt, kitchensink, runthese jck tests (which contains the test case where this bug has been reported) Thanks, Thomas From thomas.schatzl at oracle.com Fri Mar 29 09:33:45 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Mar 2013 10:33:45 +0100 Subject: RFE (m) (Prelminary): JDK-7197666: java -d64 -version core dumps in a box with lots of memory In-Reply-To: <5154BF9A.2080208@oracle.com> References: <5154BF9A.2080208@oracle.com> Message-ID: <1364549625.2821.34.camel@cirrus> Hi, On Thu, 2013-03-28 at 23:09 +0100, Bengt Rutisson wrote: > > Hi all, > > Sending this to both runtime and GC since I think it concerns both > areas. > > I'd like some feedback on this preliminary change. I still want to do > some more testing and evaluation before I ask for final reviews: > > http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/ > > In particular I would like some feedback on these questions: > > - The class I am adding, ArrayAllocator, wants to choose between doing > malloc and mmap. Normally we use ReservedSpace and VirtualSpace to get > mapped memory. However, those classes are kind of clumsy when I just > want to allocate one chunk of memory. It is much simpler to use the > os::reserve_memory() and os::commit_memory() methods directly. I think > my use case here motivate using these methods directly, but is there > some reason not to do that? The *Space classes are heavily geared to be used as virtual memory management helpers for a two-generation heap, so I'm not sure if they are appropriate here. Not sure why you chose to use AllocateHeap(), I always thought that the use of the corresponding macros (NEW_C_HEAP_ARRAY etc.) is recommended. The error messages of ArrayAllocator give very little information, maybe add the requested block size that lead to the failure in the message. There is a typo in the comment "uses malpped memory" -> "uses mapped memory". While it is not strictly necessary, you could initialize all member variables in the constructor's initialization list. Maybe there is a common name for such type of objects, i.e. cleanup helpers that are "stack allocated" only to be automatically called during destructor of the enclosing class in c++ jargon. It seems to be a common pattern. If that is not the case, maybe rename it to LargeArrayAllocator to better indicate the purpose in addition to the comment. > > Some background on the change: > > The default implementation of malloc on Solaris has several limitation > compared to malloc on other platforms. One limitation is that it can > only use one consecutive chunk of memory. Another limitation is that > it always allocates in this single chunk of memory no matter how large > the requested amount of memory is. Other malloc implementations > normally use mapped memory for large allocations. > > The Java heap is mapped in memory and we try to pick a good address > for it. The lowest allowed address is controlled by > HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other > platforms have at least 2 GB). Since the C heap ends up below the Java > heap it means that in some cases it is limited to 256 MB. 256 MB seems to be very low in any case. Maybe in addition to that, make HeapBaseMinAddress dependent on the OS? Is there some documentation/FAQ that tells solaris/x86 users to consider increasing HeapBaseMinAddress if they run out of C heap? > Thomas From leonid.mesnik at oracle.com Fri Mar 29 09:38:13 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 29 Mar 2013 13:38:13 +0400 Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure In-Reply-To: <5151A2E3.60507@oracle.com> References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com> <5151A2E3.60507@oracle.com> Message-ID: <51556105.2040900@oracle.com> Hi Here is new version of test. (pass jprt) http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.1/ See my comment inline. On 03/26/2013 05:30 PM, Mikael Gerdin wrote: > Leonid, > > On 2013-03-22 08:06, Leonid Mesnik wrote: >> Could anyone please review this small test fix. >> >> Leonid >> On 03/20/2013 04:16 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Could you please review fix for 8009808 TEST-BUG : test case is using >>> bash style tests. Default shell for jtreg is bourne. thus failure. >>> >>> I've completely rewritten test in java without major changes it test >>> logic. >>> I remove CMS so test could be run when CMS is not supported. Also I >>> changed max memory to 128M to reduce memory load and increase number >>> of GC log entries. > > Do you think it would be useful to run this test with different GCs? > In that case you can pick up the test.vm.opts and test.java.opts > system properties and add them to the java command line you launch. I've added test.java.opts properties. They are used during testing to set additional GC. > >>> >>> Here is the link: >>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/ >>> >>> > > Are you sure about this: > static final File currentDirectory = new > File(System.getProperty("user.dir")); > > isn't user.dir the home directory? Current directory should be just "." > Something like new File(".").getAbsoluteFile() should give you the > current work dir. System.getProperty("user.dir") is current directory. However I changed it to "." to make it more evident. > > What is the relation between "numberOfFiles" and "minutesToRun"?? > How do you know that running for 3 minutes will cause a log rotation? I've updated test to invoke fullGC and estimate lower bound of needed invocation. Now test check that exactly 3 logs are generated. Leonid > > I know that you've just adapted the existing test but it seems strange > to me. > > /Mikael > > > >> >> -- Leonid Mesnik JVM SQE From jon.masamitsu at oracle.com Fri Mar 29 13:18:31 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 29 Mar 2013 06:18:31 -0700 Subject: RFR (XXS): 8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose In-Reply-To: <1364547114.2821.11.camel@cirrus> References: <1364547114.2821.11.camel@cirrus> Message-ID: <515594A7.5080005@oracle.com> Thomas, This is the webrev? http://cr.openjdk.java.net/~tschatzl/8005857/webrev/ Looks good. Jon On 3/29/2013 1:51 AM, Thomas Schatzl wrote: > Hi all, > > please review the following change for 8005857: > > In this issue, code checks whether the gc locker is active during heap > expansion to print a message that instead of gc the heap has been expanded. > > The code used the method GCLocker::is_active() to get the gc locker > state, but is_active() asserts when the VM is currently not at a > safepoint and no GC is actually needed. > This assert does not hold in all cases while expanding the heap. E.g. heap > expansion may be done outside of a safepoint when satisfying an allocation > request for a large object. Heap expansion may occur also when no GC is > pending in the gc locker. > > Imho the previous use of is_active() was wrong not only because of the assert. > The message text notifies of the avoidance of a gc. However, the condition did > not check whether the gc locker indicated the need for a gc, i.e. did not > check the GCLocker::needs_gc() predicate. > > This change uses GCLocker::is_active_and_needs_gc() instead of > GCLocker::is_active(). Which does not check whether the vm is at a safepoint, > and also checks whether a gc is actually pending. > > Jon M. suggested this fix. > > JIRA: > https://jbs.oracle.com/bugs/browse/JDK-8005857 > > bugs.sun: > http://bugs.sun.com/view_bug.do?bug_id=8005857 > > Testing: > jprt, kitchensink, runthese jck tests (which contains the test case > where this bug has been reported) > > Thanks, > Thomas > > > > From thomas.schatzl at oracle.com Fri Mar 29 14:50:03 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Mar 2013 15:50:03 +0100 Subject: RFR (XXS): 8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose In-Reply-To: <515594A7.5080005@oracle.com> References: <1364547114.2821.11.camel@cirrus> <515594A7.5080005@oracle.com> Message-ID: <1364568603.3293.0.camel@cirrus> Hi, On Fri, 2013-03-29 at 06:18 -0700, Jon Masamitsu wrote: > Thomas, > > This is the webrev? > > http://cr.openjdk.java.net/~tschatzl/8005857/webrev/ > Uh, yes :) Sorry. > Looks good. Thanks, Thomas From jon.masamitsu at oracle.com Sat Mar 30 00:20:07 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 29 Mar 2013 17:20:07 -0700 Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions In-Reply-To: <515271FB.9090203@oracle.com> References: <515271FB.9090203@oracle.com> Message-ID: <51562FB7.9010609@oracle.com> Ths webrev has mostly name changes suggested by the code review comments. There are additional changes coming that relate to semantic changes suggested by the code review. This was created by deleting some of the suggested semantic changes so will not compile. The next webrev will be relative to this one so you won't have to look at the name changes when looking and the semantic changes. Ignore the block comment about chunk accounting at the beginning of metaspace.cpp. That will be updated or deleted in the next webrev. The deletion of some dead code is included in this webrev (limited number of lines). http://cr.openjdk.java.net/~jmasa/8008966/webrev.00_1/ Thanks. Jon On 3/26/2013 9:13 PM, Jon Masamitsu wrote: > > Replace the use of a method that calculated the total capacity of > the Metaspaces by iterating over all the Metaspaces by maintaining > the sum of Metaspace capacities as the Metachunks are > allocated to each Metaspace. Also maintain a sum for each > Metaspace as the Metachunks are allocated to that Metaspace. > > Change should_expand() and compute_new_space() to > calculate quantities in bytes. > > Remove calls to methods that calculated totals for > "used" and "free" by iterating over the Metaspaces > in product mode. In some cases substitute the use > of capacity for used. > > http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/ > > Thanks. > > Jon From john.cuthbertson at oracle.com Sat Mar 30 03:49:25 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 30 Mar 2013 03:49:25 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8010463: G1: Crashes with -UseTLAB and heap verification Message-ID: <20130330034930.80B26484D0@hg.openjdk.java.net> Changeset: 24ef5fb05e0f Author: johnc Date: 2013-03-29 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/24ef5fb05e0f 8010463: G1: Crashes with -UseTLAB and heap verification Summary: Some parts of the G1 heap can only be walked during a safepoint. Skip verifying these parts of the heap when verifying during JVM startup. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/thread.cpp + test/gc/TestVerifyBeforeGCDuringStartup.java