From rednaxelafx at gmail.com Mon Oct 1 01:58:14 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 1 Oct 2012 09:58:14 +0800 Subject: Getting the Heap virtual addresses? In-Reply-To: <5065E7B5.5080904@oracle.com> References: <5065E7B5.5080904@oracle.com> Message-ID: Hi Azeem, It'd be easy to get with an SA agent instead of a JVMTI agent. Would that do for you? - Kris On Sat, Sep 29, 2012 at 2:08 AM, Azeem Jiva wrote: > Is there a way to get at the virtual addresses for the heap from a JVMTI > agent? The data is clearly available as PrintGCDetails dumps the > information at the end of the run. > > -- > Azeem Jiva > @javawithjiva > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Oct 1 11:18:00 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 01 Oct 2012 11:18:00 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 44 new changesets Message-ID: <20121001112113.6796847149@hg.openjdk.java.net> Changeset: fac3dd92ebaf Author: bpittore Date: 2012-09-19 17:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fac3dd92ebaf 7195372: Wrong copyright in new files Summary: Fixed copyrights Reviewed-by: dholmes Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! make/linux/makefiles/sa.make Changeset: ef7fe63a2d39 Author: vladidan Date: 2012-09-24 19:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ef7fe63a2d39 Merge Changeset: 15ba0e7a3ff4 Author: sla Date: 2012-09-17 11:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/15ba0e7a3ff4 7193201: [OS X] The development launcher should be signed and given task_for_pid privileges Reviewed-by: sspitsyn, nloodin, mgronlun, coleenp ! make/bsd/makefiles/launcher.make + src/os/bsd/launcher/Info-privileged.plist Changeset: a7509aff1b06 Author: dholmes Date: 2012-09-17 07:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a7509aff1b06 7194254: jstack reports wrong thread priorities Reviewed-by: dholmes, sla, fparain Contributed-by: Dmytro Sheyko ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp + test/runtime/7194254/Test7194254.java Changeset: 7b41bee02500 Author: dholmes Date: 2012-09-17 08:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7b41bee02500 Merge Changeset: 716e6ef4482a Author: zgu Date: 2012-09-17 10:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/716e6ef4482a 7190089: NMT ON: NMT failed assertion on thread's stack base address Summary: Solaris only, record stack info to NMT after stack size adjustment was made for primordial threads Reviewed-by: kvn, acorn, coleenp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: c088e2e95e69 Author: zgu Date: 2012-09-17 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c088e2e95e69 Merge ! src/share/vm/runtime/thread.cpp Changeset: 9a86ddfc6c8f Author: zgu Date: 2012-09-17 16:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9a86ddfc6c8f 7188594: Print statistic collected by NMT with VM flag Summary: Print out statistics of collected NMT data if it is on at VM exits Reviewed-by: kvn, coleenp, twisti ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/services/memTracker.hpp Changeset: 45f22ba9348d Author: zgu Date: 2012-09-18 11:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/45f22ba9348d Merge Changeset: 1cb8583c3da8 Author: minqi Date: 2012-09-18 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cb8583c3da8 7191786: retransformClasses() does not pass in LocalVariableTypeTable of a method Summary: JVMTI REtruncformClasses must support LocalVariableTypeTable attribute Reviewed-by: dcubed, dsamersoff, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: 26994b6e10d5 Author: minqi Date: 2012-09-19 08:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/26994b6e10d5 Merge Changeset: 989cf02ca531 Author: ihse Date: 2012-09-17 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/989cf02ca531 7172012: Make test-in-build an option (Queens) Reviewed-by: ohair, dholmes ! make/bsd/Makefile ! make/defs.make ! make/linux/Makefile ! make/solaris/Makefile Changeset: 06be7f06c2de Author: ohair Date: 2012-09-18 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/06be7f06c2de Merge Changeset: 37518f191ddb Author: ohair Date: 2012-09-18 13:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/37518f191ddb 7198329: Add $(sort) to object files used in links makes binarties more consistent Reviewed-by: dholmes, tbell, erikj, ihse, ohrstrom ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/vm.make Changeset: 0e5be2138cd6 Author: jcoomes Date: 2012-09-18 19:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e5be2138cd6 Merge Changeset: 2c527daec02c Author: jcoomes Date: 2012-09-19 16:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2c527daec02c Merge Changeset: 6af8f3562069 Author: kevinw Date: 2012-09-19 15:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6af8f3562069 7196045: Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API. Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/management.cpp + test/runtime/7196045/Test7196045.java Changeset: 8440414b0fd8 Author: kevinw Date: 2012-09-20 03:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8440414b0fd8 Merge Changeset: b711844284e2 Author: nloodin Date: 2012-09-21 10:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b711844284e2 7200092: Make NMT a bit friendlier to work with Reviewed-by: kvn, ysr, azeemj ! src/share/vm/services/memTracker.cpp Changeset: 5a98bf7d847b Author: minqi Date: 2012-09-24 12:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5a98bf7d847b 6879063: SA should use hsdis for disassembly Summary: We should in SA to use hsdis for it like the JVM does to replace the current java based disassembler. Reviewed-by: twisti, jrose, sla Contributed-by: yumin.qi at oracle.com - agent/make/ClosureFinder.java ! agent/make/Makefile ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/linux/Makefile ! agent/src/os/linux/mapfile ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/os/win32/windbg/Makefile ! 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/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/Disassembler.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/InstructionVisitor.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/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/SADebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.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/runtime/x86/X86RegisterMap.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js + agent/src/share/native/sadis.c ! agent/test/jdi/jstack.sh ! agent/test/jdi/jstack64.sh ! agent/test/jdi/runsa.sh ! agent/test/jdi/sasanity.sh ! agent/test/libproc/libproctest.sh ! agent/test/libproc/libproctest64.sh ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/sa.make ! src/share/tools/hsdis/Makefile ! src/share/tools/hsdis/README ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 3d739d45d9fd Author: minqi Date: 2012-09-24 20:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3d739d45d9fd 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/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 Changeset: 45535ab90688 Author: dholmes Date: 2012-09-25 07:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/45535ab90688 7200065: Cross-compilation changes to support the new-build Reviewed-by: dholmes, ohair Contributed-by: Fredrik Ohrstrom ! make/linux/makefiles/adlc.make ! make/linux/makefiles/defs.make Changeset: b86575d092a2 Author: dsamersoff Date: 2012-09-27 20:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b86575d092a2 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/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 ! make/linux/makefiles/sa.make ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 15fba4382765 Author: stefank Date: 2012-09-28 14:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/15fba4382765 Merge Changeset: 2cb2f30450c7 Author: twisti Date: 2012-09-17 12:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2cb2f30450c7 7196262: JSR 292: java/lang/invoke/PrivateInvokeTest.java fails on solaris-sparc Reviewed-by: kvn, jrose, bdelsart ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/asm/register.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 8d3cc6612bd1 Author: kvn Date: 2012-09-17 17:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8d3cc6612bd1 7197033: missing ResourceMark for assert in Method::bci_from() Summary: Added missing ResourceMark. Reviewed-by: dholmes, coleenp, jmasa ! src/share/vm/oops/method.cpp Changeset: 137868b7aa6f Author: kvn Date: 2012-09-17 19:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/137868b7aa6f 7196199: java/text/Bidi/Bug6665028.java failed: Bidi run count incorrect Summary: Save whole XMM/YMM registers in safepoint interrupt handler. Reviewed-by: roland, twisti ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp + test/compiler/7196199/Test7196199.java Changeset: 9d89c76b0505 Author: twisti Date: 2012-09-19 10:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9d89c76b0505 7198499: TraceTypeProfile as diagnostic option Reviewed-by: kvn Contributed-by: Aleksey Shipilev ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/doCall.cpp Changeset: 8ae8f9dd7099 Author: kvn Date: 2012-09-19 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8ae8f9dd7099 7199010: incorrect vector alignment Summary: Fixed vectors alignment when several arrays are accessed in one loop. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp Changeset: 7eca5de9e0b6 Author: roland Date: 2012-09-20 16:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7eca5de9e0b6 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement() Summary: use shorter instruction sequences for atomic add and atomic exchange when possible. Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: b31471cdc53e Author: kvn Date: 2012-09-24 10:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b31471cdc53e 7200163: add CodeComments functionality to assember stubs Summary: Pass the codeBuffer to the Stub constructor, and adapts the disassembler to print the comments. Reviewed-by: jrose, kvn, twisti Contributed-by: goetz.lindenmaier at sap.com ! 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/nmethod.cpp ! src/share/vm/code/nmethod.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/sharedRuntime.cpp Changeset: 3a327d0b8586 Author: twisti Date: 2012-09-24 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3a327d0b8586 7188176: The JVM should differentiate between T and M series and adjust GC ergonomics Reviewed-by: kvn Contributed-by: Tao Mao ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp Changeset: f7c1f489db55 Author: twisti Date: 2012-09-24 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f7c1f489db55 Merge Changeset: c92f43386117 Author: kvn Date: 2012-09-24 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c92f43386117 Merge ! src/share/vm/classfile/vmSymbols.hpp Changeset: 9191895df19d Author: twisti Date: 2012-09-24 17:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9191895df19d 7200001: failed C1 OSR compile doesn't get recompiled with C2 Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 1a9b9cfcef41 Author: neliasso Date: 2012-03-29 16:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1a9b9cfcef41 7163863: Updated projectcreator Summary: Enable source browsing for all platform dependent code Reviewed-by: brutisso, coleenp ! make/windows/makefiles/projectcreator.make ! src/share/tools/ProjectCreator/BuildConfig.java - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java + src/share/tools/ProjectCreator/FileTreeCreator.java + src/share/tools/ProjectCreator/FileTreeCreatorVC10.java + src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: 0702f188baeb Author: kvn Date: 2012-09-25 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0702f188baeb 7200233: C2: can't use expand rules for vector instruction rules Summary: Added missed _bottom_type set in ArchDesc::defineExpand() and missed vector nodes in MatchRule::is_vector(). Reviewed-by: twisti, roland, dlong ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 06f52c4d0e18 Author: kvn Date: 2012-09-25 15:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/06f52c4d0e18 7200264: 7192963 changes disabled shift vectors Summary: Replaced is_vector_use() call with explicit check for vector shift's count. Reviewed-by: twisti, roland, dlong, vlivanov ! src/share/vm/opto/superword.cpp + test/compiler/7200264/Test7200264.sh + test/compiler/7200264/TestIntVect.java Changeset: e626685e9f6c Author: kvn Date: 2012-09-27 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e626685e9f6c 7193318: C2: remove number of inputs requirement from Node's new operator Summary: Deleted placement new operator of Node - node(size_t, Compile *, int). Reviewed-by: kvn, twisti Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 69fb89ec6fa7 Author: kvn Date: 2012-09-27 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/69fb89ec6fa7 7198084: NPG: distance is too big for short branches in test_invocation_counter_for_mdp() Summary: use long branches in test_invocation_counter_for_mdp() Reviewed-by: twisti ! src/cpu/sparc/vm/interp_masm_sparc.cpp Changeset: f2e12eb74117 Author: kvn Date: 2012-09-28 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f2e12eb74117 Merge - 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/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 9f008ad79470 Author: amurillo Date: 2012-09-28 13:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9f008ad79470 Added tag hs25-b03 for changeset f2e12eb74117 ! .hgtags Changeset: 1b582b1bf7cb Author: amurillo Date: 2012-09-28 14:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1b582b1bf7cb 8000251: new hotspot build - hs25-b04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5c8fbbfed964 Author: stefank Date: 2012-10-01 11:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5c8fbbfed964 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/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 - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java From azeem.jiva at oracle.com Mon Oct 1 13:10:59 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Mon, 01 Oct 2012 08:10:59 -0500 Subject: Getting the Heap virtual addresses? In-Reply-To: References: <5065E7B5.5080904@oracle.com> Message-ID: <50699663.8030900@oracle.com> Krystal, That would work as well, I just need some way of getting the data while the JVM is running. On 09/30/2012 08:58 PM, Krystal Mok wrote: > Hi Azeem, > > It'd be easy to get with an SA agent instead of a JVMTI agent. Would > that do for you? > > - Kris > > On Sat, Sep 29, 2012 at 2:08 AM, Azeem Jiva > wrote: > > Is there a way to get at the virtual addresses for the heap from a > JVMTI agent? The data is clearly available as PrintGCDetails > dumps the information at the end of the run. > > -- > Azeem Jiva > @javawithjiva > > -- Azeem Jiva @javawithjiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Oct 1 13:51:31 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 01 Oct 2012 13:51:31 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000230: Change os::print_location to be more descriptive when a location is pointing into an object Message-ID: <20121001135135.F16054714A@hg.openjdk.java.net> Changeset: 85f1cded9793 Author: stefank Date: 2012-09-28 15:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/85f1cded9793 8000230: Change os::print_location to be more descriptive when a location is pointing into an object Reviewed-by: mgerdin, twisti ! src/share/vm/runtime/os.cpp From bengt.rutisson at oracle.com Mon Oct 1 14:05:27 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Oct 2012 16:05:27 +0200 Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption In-Reply-To: <5064CDCA.6030102@oracle.com> References: <505B6B65.1060201@oracle.com> <505C76EC.5030902@oracle.com> <506247DF.80709@oracle.com> <5064A8DE.2070509@oracle.com> <5064CDCA.6030102@oracle.com> Message-ID: <5069A327.9010904@oracle.com> Hi John, Comments inline... On 2012-09-28 00:06, John Cuthbertson wrote: > Hi Bengt, > > Thanks for the response. Replies are inline... > > On 09/27/12 12:28, Bengt Rutisson wrote: >> >> Hi John, >> >> Thanks for the extra explanations. They helped a lot! And I think >> your suggestions, for addressing the comments I had, sounds good. In >> particular it makes sense to treat the task queue size the same way >> in CMS and G1. > The main difference was that CMS was using virtual space for it's > marking stack while G1 was using C heap. So the G1 code now mirrors > that of CMS. Right. And I agree that it seems good if we use the same allocation strategy for both collectors. >> I'll look at your updated webrev when you send it out. >> >> Regarding whether or not to only use VirtualSpaces on 64 bit I feel a >> bit unsure. Using VirtualSpaces already make the code more complex >> than it was before with C heap allocations. Introducing platform >> dependencies on top of that seems to create a big mess. If it somehow >> is possible to abstract the allocation away so we keep it in one >> place it might be worth treating 32 and 64 bit differently. >> >> Not sure if this is a good thought; but if we would make it optional >> to use VirtualSpaces or CHeap to support 32/64 bit differences, would >> it make sense to only use VirtualSpaces on Solaris? You mentioned >> that the out-of-C-heap issue seem to happen due to a Solaris bug. > > I think we should use a virtual space for the marking stack (like CMS > does) on all platforms. > > For the card bitmaps etc it might look OK if we're prepared to have > conditional compilation in the code. Then I could have a very simple > allocator/utility class to manage the backing store that doesn't care > if the underlying space is C heap or virtual space. The conditional > code would be "hidden" in the simple allocator. On platforms other > than Solaris it would be a wrapper around malloc; on Solaris we would > allocate from the virtual space using a simple pointer bump. How does > that sound? Yes, that sounds like about what I meant. I'm still not sure it is worth the extra complexity. Maybe we should just always use virtual spaces. If it turns out to be an issue on 32-bit platforms we can add the wrappers then. Not sure what the best approach is. > If we decide to go that route I may want to break up the work. One CR > for the mark stack and the current CR for the card bit maps with the > simple allocator. Yes, that sounds like a good plan in that case. > BTW I instrumented the G1CollectedHeap constructor to determine where > the bulk of the allocation requests were coming from: > > cairnapple{jcuthber}:272> ./test.sh -d64 -XX:-ZapUnusedHeapArea > -XX:CICompilerCount=1 -XX:ParallelGCThreads=1 -Xms2g -Xmx2g > -XX:+UseG1GC -XX:+PrintMallocStatistics > Using java runtime at: > /net/jre.us.oracle.com/p/v42/jdk/7/fcs/b147/binaries/solaris-x64/jre > 0 mallocs (0MB), 0 frees (0MB), 0MB resrc > 90 mallocs (1MB), 0 frees (0MB), 0MB resrc > 14432 mallocs (4MB), 0 frees (0MB), 0MB resrc > 14556 mallocs (4MB), 2 frees (0MB), 0MB resrc > java version "1.7.0" > Java(TM) SE Runtime Environment (build 1.7.0-b147) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b02-internal-fastdebug, > mixed mode) > allocation stats: 19599 mallocs (7MB), 1119 frees (0MB), 3MB resrc > > The first is from the executable statement in the G1CollectorHeap > constructor. The second from just after initializing the > ConcurrentMark instance. The third is just after allocating the > initial heap. The last is at the end of the G1CollectedHeap constructor. > > The bulk of the malloc requests are coming from allocating the heap > region instances (and some of their contained structures). > > If the simple allocator idea works out then we could perhaps up level > it to the G1CollectedHeap and and use it to allocate the heap region > instances. Right. So if we would have a wrapper class to handle the allocations we could play around a bit with this and see if it would be good to use virtual spaces for heap region structures as well. I don't know if you got any wiser by my comments, but I'm looking forward to see what you come up with :-) Thanks, Bengt > > Regards, > > JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Mon Oct 1 21:58:36 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 01 Oct 2012 14:58:36 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken Message-ID: <506A120C.7060907@oracle.com> Hi Everyone, Can I have a couple of volunteers look over the changes for this fix? The webrev can be found at: http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ Summary: While testing the changes for another CR, I ran into this divide by zero error. I decided to make a separate CR so that the change can be backported to hs24 - which also has the issue. Testing: The original test case with and without PGCT=0 and PrintPLAB enabled. Thanks, JohnC From jon.masamitsu at oracle.com Mon Oct 1 22:52:47 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 01 Oct 2012 15:52:47 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <506A120C.7060907@oracle.com> References: <506A120C.7060907@oracle.com> Message-ID: <506A1EBF.9080105@oracle.com> John, Would you mind passing in the no_of_gc_workers into adjust_desired_plab_sz()? G1CollectedHeap::evacuate_collection_set() release_gc_alloc_regions(n_workers) _survivor_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); _old_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); ParNewGeneration::collect() adjust_desired_plab_sz(n_workers) Jon On 10/01/12 14:58, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers look over the changes for this fix? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ > > Summary: > While testing the changes for another CR, I ran into this divide by > zero error. I decided to make a separate CR so that the change can be > backported to hs24 - which also has the issue. > > Testing: > The original test case with and without PGCT=0 and PrintPLAB enabled. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Mon Oct 1 23:02:36 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 01 Oct 2012 16:02:36 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <506A1EBF.9080105@oracle.com> References: <506A120C.7060907@oracle.com> <506A1EBF.9080105@oracle.com> Message-ID: <506A210C.7080305@oracle.com> Hi Jon, Not at all. I'll send out a new webrev shortly. JohnC On 10/01/12 15:52, Jon Masamitsu wrote: > John, > > Would you mind passing in the no_of_gc_workers into > adjust_desired_plab_sz()? > > G1CollectedHeap::evacuate_collection_set() > release_gc_alloc_regions(n_workers) > _survivor_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); > _old_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); > > > ParNewGeneration::collect() > adjust_desired_plab_sz(n_workers) > > Jon > > On 10/01/12 14:58, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers look over the changes for this fix? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ >> >> Summary: >> While testing the changes for another CR, I ran into this divide by >> zero error. I decided to make a separate CR so that the change can be >> backported to hs24 - which also has the issue. >> >> Testing: >> The original test case with and without PGCT=0 and PrintPLAB enabled. >> >> Thanks, >> >> JohnC From John.Coomes at oracle.com Mon Oct 1 23:27:19 2012 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 1 Oct 2012 16:27:19 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <506A120C.7060907@oracle.com> References: <506A120C.7060907@oracle.com> Message-ID: <20586.9943.595220.270355@oracle.com> John Cuthbertson (john.cuthbertson at oracle.com) wrote: > Hi Everyone, > > Can I have a couple of volunteers look over the changes for this fix? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ > > Summary: > While testing the changes for another CR, I ran into this divide by zero > error. I decided to make a separate CR so that the change can be > backported to hs24 - which also has the issue. > > Testing: > The original test case with and without PGCT=0 and PrintPLAB enabled. Looks good to me. -John From iggy.veresov at gmail.com Mon Oct 1 23:42:41 2012 From: iggy.veresov at gmail.com (Igor Veresov) Date: Mon, 1 Oct 2012 16:42:41 -0700 Subject: TLAB and NUMA aware allocator In-Reply-To: References: <5063DC2A.6000807@oracle.com> Message-ID: <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> On Linux we just hope that the scheduler will leave a thread on the same node, which is what happens in reality. Also, per generational hypothesis we hope that in most cases the data will be already dead when such a migration happens. And like Jon said it's not an issue on Solaris. igor On Sep 27, 2012, at 12:41 PM, Vitaly Davidovich wrote: > Thanks Jon -- that blog entry was useful. > > Vitaly > > On Thu, Sep 27, 2012 at 12:55 AM, Jon Masamitsu wrote: > Vitaly, > > The current implementation depends on a thread not migrating > between nodes. On solaris that naturally happens. I don't > remember the details but it's something like Solaris sees that > a thread XX is executing on node AA and using memory on AA > so it leaves XX on AA. On linux I'm guessing (really guessing) > that there is a way to create an affinity between XX on AA. > > This has all the things I ever knew about it. > > https://blogs.oracle.com/jonthecollector/entry/help_for_the_numa_weary > > Jon > > > On 9/26/2012 4:09 PM, Vitaly Davidovich wrote: > Hi guys, > > If I understand it correctly, the NUMA allocator splits eden into regions > and tries to ensure that an allocated object is in a region local to the > mutator thread. How does this affect tlabs? Specifically, a tlab will be > handed out to a thread from the current node. If the java thread then > migrates to a different node, its tlab is presumably still on the previous > node, leading to cross-node traffic? Is there a notion of a processor local > tlab? In that case, access to already allocated objects will take a hit but > new allocations will not. > > The way I imagine a processor local tlab working is when a thread migrates, > the previous tlab becomes available for whichever java thread is onproc > there now - that is, tlab ownership changes. The migrated thread then > picks up allocations in the new tlab. > > It can still be a bump the pointer since only one hardware thread can be > running at a time on the processor. > > Is this or something like it already there? If not, what challenges am I > overlooking from my high-level view? > > Thanks > > Sent from my phone > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd-2012 at eckenfels.net Tue Oct 2 00:03:49 2012 From: bernd-2012 at eckenfels.net (Bernd Eckenfels) Date: Tue, 02 Oct 2012 02:03:49 +0200 Subject: Large Page allocation strategy only for 2003? In-Reply-To: <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> References: <5063DC2A.6000807@oracle.com> <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> Message-ID: Hello, While investigating the risks of using/recommending large pages I noticed that there are two different allocations strategies. One requests the whole area (I guess thats part of the heap in NUMA?) with a single malloc or with multiple (+UseLargePagesIndividualAllocation). The option for this defaults to single on all platforms but Windows 2003. I wonder if this is really a 2003 thing only. or if the code should be updated to default to on on Win7,8,2008 and 2008R2 as well. I asume, that not the whole heap will be allocated in case of NUMA, right? Because otherwise I could see use for the IndividulaAllocations in that case as well, otherwise a single locality might get exhausted? Greetings Bernd From jon.masamitsu at oracle.com Tue Oct 2 06:10:38 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 01 Oct 2012 23:10:38 -0700 Subject: Large Page allocation strategy only for 2003? In-Reply-To: References: <5063DC2A.6000807@oracle.com> <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> Message-ID: <506A855E.8030801@oracle.com> On 10/1/2012 5:03 PM, Bernd Eckenfels wrote: > Hello, > > While investigating the risks of using/recommending large pages I > noticed that there are two different allocations strategies. One > requests the whole area (I guess thats part of the heap in NUMA?) with > a single malloc or with multiple (+UseLargePagesIndividualAllocation). > The option for this defaults to single on all platforms but Windows 2003. > > I wonder if this is really a 2003 thing only. or if the code should be > updated to default to on on Win7,8,2008 and 2008R2 as well. I believe that it was a workaround for a problem on windows 2003. I don't recall anymore details. Jon > > I asume, that not the whole heap will be allocated in case of NUMA, > right? Because otherwise I could see use for the IndividulaAllocations > in that case as well, otherwise a single locality might get exhausted? > > Greetings > Bernd From stefan.karlsson at oracle.com Tue Oct 2 07:55:54 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Tue, 02 Oct 2012 07:55:54 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream Message-ID: <20121002075601.080B84715C@hg.openjdk.java.net> Changeset: 86af3dacab81 Author: stefank Date: 2012-10-01 13:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/86af3dacab81 8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream Reviewed-by: brutisso, sla, jmasa, coleenp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp From stefan.karlsson at oracle.com Tue Oct 2 10:49:15 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Tue, 02 Oct 2012 10:49:15 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location Message-ID: <20121002104924.1F35547161@hg.openjdk.java.net> Changeset: 87ac5c0a404d Author: stefank Date: 2012-10-01 13:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/87ac5c0a404d 8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location Reviewed-by: brutisso, neliasso ! src/share/vm/runtime/os.cpp From vitalyd at gmail.com Tue Oct 2 11:29:43 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 2 Oct 2012 07:29:43 -0400 Subject: TLAB and NUMA aware allocator In-Reply-To: <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> References: <5063DC2A.6000807@oracle.com> <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> Message-ID: Thanks Igor, makes sense. Vitaly Sent from my phone On Oct 1, 2012 7:42 PM, "Igor Veresov" wrote: > On Linux we just hope that the scheduler will leave a thread on the same > node, which is what happens in reality. Also, per generational hypothesis > we hope that in most cases the data will be already dead when such a > migration happens. > > And like Jon said it's not an issue on Solaris. > > igor > > On Sep 27, 2012, at 12:41 PM, Vitaly Davidovich wrote: > > Thanks Jon -- that blog entry was useful. > > Vitaly > > On Thu, Sep 27, 2012 at 12:55 AM, Jon Masamitsu wrote: > >> Vitaly, >> >> The current implementation depends on a thread not migrating >> between nodes. On solaris that naturally happens. I don't >> remember the details but it's something like Solaris sees that >> a thread XX is executing on node AA and using memory on AA >> so it leaves XX on AA. On linux I'm guessing (really guessing) >> that there is a way to create an affinity between XX on AA. >> >> This has all the things I ever knew about it. >> >> https://blogs.oracle.com/**jonthecollector/entry/help_** >> for_the_numa_weary >> >> Jon >> >> >> On 9/26/2012 4:09 PM, Vitaly Davidovich wrote: >> >>> Hi guys, >>> >>> If I understand it correctly, the NUMA allocator splits eden into regions >>> and tries to ensure that an allocated object is in a region local to the >>> mutator thread. How does this affect tlabs? Specifically, a tlab will be >>> handed out to a thread from the current node. If the java thread then >>> migrates to a different node, its tlab is presumably still on the >>> previous >>> node, leading to cross-node traffic? Is there a notion of a processor >>> local >>> tlab? In that case, access to already allocated objects will take a hit >>> but >>> new allocations will not. >>> >>> The way I imagine a processor local tlab working is when a thread >>> migrates, >>> the previous tlab becomes available for whichever java thread is onproc >>> there now - that is, tlab ownership changes. The migrated thread then >>> picks up allocations in the new tlab. >>> >>> It can still be a bump the pointer since only one hardware thread can be >>> running at a time on the processor. >>> >>> Is this or something like it already there? If not, what challenges am I >>> overlooking from my high-level view? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Oct 2 12:45:07 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Oct 2012 14:45:07 +0200 Subject: Review request (S): 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5065757D.9060102@oracle.com> References: <5065757D.9060102@oracle.com> Message-ID: <506AE1D3.1050103@oracle.com> Hi Andreas, I think this looks good. I like that we treat PrintGCDateStamps and PrintGCTimeStamps in a consistent way. One thing that kind of worries me is that the TraceTime class is used from other parts of the JVM than just the GC. This means that you now get date stamps on compiler events if you enable PrintGCDateStamps. I think this is probably fine since they already get time stamps if you enable PrintGCTimeStamps. See for example how PhaseTraceTime is used in C1. Maybe we should send this review out on hotspot-dev to make sure that all teams have a chance to comment on this? Thanks, Bengt On 2012-09-28 12:01, Andreas Eriksson wrote: > Hi, > > Can I have some reviews for the following change please: > http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ > > > This fixes GC logs from genCollectedHeap.cpp where sometimes it would > not print date-stamps. > The fix moves printing of date-stamps into TraceTime, where > time-stamps are already printed from. > > Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc > -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps: > 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), > 0.0108630 secs] > 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs] > 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs] > 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), > 0.0103210 secs] > > Another route that was investigated was to add the date-stamp call > directly in genCollectedHeap.cpp, but because of complex interactions > when a full GC was initiated from a non-full GC this path was not taken. > > > This will slightly change the logging output when using > -XX:+PrintGCDetails. > Now date-stamps will also be printed inside other lines, as > time-stamps already are: > > Before: > 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: > 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 > secs] [Times: user=0.01 sys=0.00, real=0.01 secs] > > After: > 2012-09-28T11:29:33.260+0200: 0.184: [GC2012-09-28T11:29:33.261+0200: > 0.184: [ParNew: 2642K->45K(3072K), 0.0095770 secs] > 3412K->1828K(9920K), 0.0097520 secs] [Times: user=0.01 sys=0.00, > real=0.01 secs] > > Thanks to Bengt Rutisson for helping with the change and webrev. > > Regards, > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From azeem.jiva at oracle.com Tue Oct 2 13:11:23 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Tue, 02 Oct 2012 08:11:23 -0500 Subject: Large Page allocation strategy only for 2003? In-Reply-To: <506A855E.8030801@oracle.com> References: <5063DC2A.6000807@oracle.com> <1EF58030-C874-4D4B-ACD4-4E3F8DF6405B@gmail.com> <506A855E.8030801@oracle.com> Message-ID: <506AE7FB.2040206@oracle.com> Yeah the UseLargePagesIndividualAllocation was meant as a fix for Windows2003 where pages would migrate if you allocated the whole area. This was fixed in subsequent Windows versions, but the workaround remains in the JVM. On 10/02/2012 01:10 AM, Jon Masamitsu wrote: > > > On 10/1/2012 5:03 PM, Bernd Eckenfels wrote: >> Hello, >> >> While investigating the risks of using/recommending large pages I >> noticed that there are two different allocations strategies. One >> requests the whole area (I guess thats part of the heap in NUMA?) >> with a single malloc or with multiple >> (+UseLargePagesIndividualAllocation). The option for this defaults to >> single on all platforms but Windows 2003. >> >> I wonder if this is really a 2003 thing only. or if the code should >> be updated to default to on on Win7,8,2008 and 2008R2 as well. > > I believe that it was a workaround for a problem on windows 2003. > I don't recall anymore details. > > Jon > >> >> I asume, that not the whole heap will be allocated in case of NUMA, >> right? Because otherwise I could see use for the >> IndividulaAllocations in that case as well, otherwise a single >> locality might get exhausted? >> >> Greetings >> Bernd -- Azeem Jiva @javawithjiva From john.cuthbertson at oracle.com Tue Oct 2 21:15:56 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 02 Oct 2012 14:15:56 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <506A1EBF.9080105@oracle.com> References: <506A120C.7060907@oracle.com> <506A1EBF.9080105@oracle.com> Message-ID: <506B598C.2090108@oracle.com> Hi Everyone, Here's a new webrev based upon Jon's feedback: http://cr.openjdk.java.net/~johnc/8000311/webrev.1/ In addition to his idea of passing the number of worker threads to the (caller of) PLABStats::adjust_desired_plab_sz(), I also pass it into the G1 reference processing and enqueuing routines. Testing: specjvm98/dacapo2006 w/ G1, ParallelGCThreads=0, heap verification specjvm98/dacapo2006 w/ G1, ParallelGCThreads=n, heap verification specjvm98/dacapo2006 w/ G1, ParallelGCThreads=n, heap verification, +ParallelRefProcEnabled specjvm98/dacapo2006 w/ ParNew, ParallelGCThreads=n, heap verification Thanks, JohnC On 10/01/12 15:52, Jon Masamitsu wrote: > John, > > Would you mind passing in the no_of_gc_workers into > adjust_desired_plab_sz()? > > G1CollectedHeap::evacuate_collection_set() > release_gc_alloc_regions(n_workers) > _survivor_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); > _old_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); > > > ParNewGeneration::collect() > adjust_desired_plab_sz(n_workers) > > Jon > > On 10/01/12 14:58, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers look over the changes for this fix? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ >> >> Summary: >> While testing the changes for another CR, I ran into this divide by >> zero error. I decided to make a separate CR so that the change can be >> backported to hs24 - which also has the issue. >> >> Testing: >> The original test case with and without PGCT=0 and PrintPLAB enabled. >> >> Thanks, >> >> JohnC From john.cuthbertson at oracle.com Tue Oct 2 21:52:48 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 02 Oct 2012 14:52:48 -0700 Subject: RFR(S/M): 7127708: G1: change task num types from int to uint in concurrent mark Message-ID: <506B6230.4030002@oracle.com> Hi Everyone, Can I have another couple of volunteers review the changes for this CR - the webrev can be found at: http://cr.openjdk.java.net/~johnc/7127708/webrev.0/ Summary: Exactly what it says the the CR's description: > In G1's concurrent mark files we use an int for the task ID and call > it "task num". Recent work done by Jon Masamitsu: > > 7121618: Change type of number of GC workers to unsigned int > > has replaced int's with uint's for the worker IDs across our GCs. We > should also make the necessary changes in the G1 files to further > conform to that. While we're at it we should also rename "task num" as > "worker id" to be consistent with the rest of the GCs. The changes were contributed by Kaushik Srenevasan from Twitter. I've looked them over and they look OK to me. Testing: jtreg tests and specjvm (Kaushik); GC test suite with a low IHOP and marking verification (JohnC); a jprt test run is in the queue. Thanks, JohnC From jon.masamitsu at oracle.com Tue Oct 2 22:00:07 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 02 Oct 2012 15:00:07 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <506B598C.2090108@oracle.com> References: <506A120C.7060907@oracle.com> <506A1EBF.9080105@oracle.com> <506B598C.2090108@oracle.com> Message-ID: <506B63E7.7010608@oracle.com> John, Looks good. Thanks for the extra changes. Jon On 10/02/12 14:15, John Cuthbertson wrote: > Hi Everyone, > > Here's a new webrev based upon Jon's feedback: > http://cr.openjdk.java.net/~johnc/8000311/webrev.1/ > > In addition to his idea of passing the number of worker threads to the > (caller of) PLABStats::adjust_desired_plab_sz(), I also pass it into > the G1 reference processing and enqueuing routines. > > Testing: > specjvm98/dacapo2006 w/ G1, ParallelGCThreads=0, heap verification > specjvm98/dacapo2006 w/ G1, ParallelGCThreads=n, heap verification > specjvm98/dacapo2006 w/ G1, ParallelGCThreads=n, heap verification, > +ParallelRefProcEnabled > specjvm98/dacapo2006 w/ ParNew, ParallelGCThreads=n, heap verification > > Thanks, > > JohnC > > > On 10/01/12 15:52, Jon Masamitsu wrote: >> John, >> >> Would you mind passing in the no_of_gc_workers into >> adjust_desired_plab_sz()? >> >> G1CollectedHeap::evacuate_collection_set() >> release_gc_alloc_regions(n_workers) >> _survivor_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); >> _old_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); >> >> >> ParNewGeneration::collect() >> adjust_desired_plab_sz(n_workers) >> >> Jon >> >> On 10/01/12 14:58, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers look over the changes for this >>> fix? The webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ >>> >>> Summary: >>> While testing the changes for another CR, I ran into this divide by >>> zero error. I decided to make a separate CR so that the change can >>> be backported to hs24 - which also has the issue. >>> >>> Testing: >>> The original test case with and without PGCT=0 and PrintPLAB enabled. >>> >>> Thanks, >>> >>> JohnC > From john.cuthbertson at oracle.com Tue Oct 2 22:45:07 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 02 Oct 2012 15:45:07 -0700 Subject: RFR(M): 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Message-ID: <506B6E73.10406@oracle.com> Hi Everyone, Can I have a couple of volunteers review the change for this CR - the webrev can be found at: http://cr.openjdk.java.net/~johnc/8000244/webrev.0/ Summary: In response code review comments from Bengt for CR 7188263, I decided to deal with the marking stack in its own CR - these are those changes. The allocation of G1's global marking stack now matches that of CMS and is allocated from virtual memory instead of C heap. Further the size of the marking stack has been changed from a fixed 128*TASKQUEUE_SIZE (16M entry capacity in a 64 bit JVM), which is the equivalent of the task queues of 128 threads, to a value based upon the actual number of parallel marking threads - with a suitable default minimum (4M entry capacity in a 64 bit JVM). The 4M entry capacity is the equivalent of the task queues for 32 threads. I have also mimicked CMS and added code to expand the marking stack in the event that concurrent marking is aborted and restarted due to overflowing the stack. The default maximum was the previous fixed value (128*TASKQUEUE_SIZE). Hence we go a maximum of 2 expansions before we have a marking stack sized as it was previously. Additionally I have rearranged (some of) the ConcurrentMark initialization code to (hopefully) make it a bit more robust w.r.t. allocation failures. This CR does not address the allocation of the liveness accounting data structures - those will be handled as 7188263. Testing: * command line testing with some instrumentation * GC test suite with a low IHOP, heap and marking verification, and forced marking overflows (and instrumentation) * GC test suite (normal) * jprt * refworkload (I didn't see any overflows in my runs, with an 8Gb heap, but it could happen). Thanks, JohnC From john.cuthbertson at oracle.com Tue Oct 2 22:56:08 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 02 Oct 2012 15:56:08 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <506B63E7.7010608@oracle.com> References: <506A120C.7060907@oracle.com> <506A1EBF.9080105@oracle.com> <506B598C.2090108@oracle.com> <506B63E7.7010608@oracle.com> Message-ID: <506B7108.6030600@oracle.com> Hi Jon, Thanks for the review. And it was no problem adding the changes - they were a good idea. JohnC On 10/02/12 15:00, Jon Masamitsu wrote: > John, > > Looks good. Thanks for the extra changes. > > Jon > > On 10/02/12 14:15, John Cuthbertson wrote: >> Hi Everyone, >> >> Here's a new webrev based upon Jon's feedback: >> http://cr.openjdk.java.net/~johnc/8000311/webrev.1/ >> >> In addition to his idea of passing the number of worker threads to >> the (caller of) PLABStats::adjust_desired_plab_sz(), I also pass it >> into the G1 reference processing and enqueuing routines. >> >> Testing: >> specjvm98/dacapo2006 w/ G1, ParallelGCThreads=0, heap verification >> specjvm98/dacapo2006 w/ G1, ParallelGCThreads=n, heap verification >> specjvm98/dacapo2006 w/ G1, ParallelGCThreads=n, heap verification, >> +ParallelRefProcEnabled >> specjvm98/dacapo2006 w/ ParNew, ParallelGCThreads=n, heap verification >> >> Thanks, >> >> JohnC >> >> >> On 10/01/12 15:52, Jon Masamitsu wrote: >>> John, >>> >>> Would you mind passing in the no_of_gc_workers into >>> adjust_desired_plab_sz()? >>> >>> G1CollectedHeap::evacuate_collection_set() >>> release_gc_alloc_regions(n_workers) >>> _survivor_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); >>> _old_plab_stats.adjust_desired_plab_sz(no_of_gc_workers); >>> >>> >>> ParNewGeneration::collect() >>> adjust_desired_plab_sz(n_workers) >>> >>> Jon >>> >>> On 10/01/12 14:58, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers look over the changes for this >>>> fix? The webrev can be found at: >>>> http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ >>>> >>>> Summary: >>>> While testing the changes for another CR, I ran into this divide by >>>> zero error. I decided to make a separate CR so that the change can >>>> be backported to hs24 - which also has the issue. >>>> >>>> Testing: >>>> The original test case with and without PGCT=0 and PrintPLAB enabled. >>>> >>>> Thanks, >>>> >>>> JohnC >> From john.cuthbertson at oracle.com Tue Oct 2 22:57:40 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 02 Oct 2012 15:57:40 -0700 Subject: RFR(XXXS): 8000311: G1: ParallelGCThreads==0 broken In-Reply-To: <20586.9943.595220.270355@oracle.com> References: <506A120C.7060907@oracle.com> <20586.9943.595220.270355@oracle.com> Message-ID: <506B7164.8000304@oracle.com> Hi John, Sorry I'm late getting back to you. Thanks for the review. Can you check out the latest webrev based upon feedback from Jon Masmitsu - when you get a chance? Thanks, JohnC On 10/01/12 16:27, John Coomes wrote: > John Cuthbertson (john.cuthbertson at oracle.com) wrote: > >> Hi Everyone, >> >> Can I have a couple of volunteers look over the changes for this fix? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8000311/webrev.0/ >> >> Summary: >> While testing the changes for another CR, I ran into this divide by zero >> error. I decided to make a separate CR so that the change can be >> backported to hs24 - which also has the issue. >> >> Testing: >> The original test case with and without PGCT=0 and PrintPLAB enabled. >> > > Looks good to me. > > -John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Wed Oct 3 00:33:12 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 2 Oct 2012 20:33:12 -0400 Subject: RFR(S/M): 7127708: G1: change task num types from int to uint in concurrent mark In-Reply-To: <506B6230.4030002@oracle.com> References: <506B6230.4030002@oracle.com> Message-ID: Hi John, concurrentMark.cpp: 4118 if (_cm->verbose_low()) { 4119 gclog_or_tty->print_cr("[%d] starting termination protocol", _worker_id); 4120 } Should be %u format? Same in g1OopClosuresg1OopClosures.inline.hpp: if (_cm->verbose_high()) { 114 gclog_or_tty->print_cr("[%d] we're looking at location " 115 "*"PTR_FORMAT" = "PTR_FORMAT, 116 _task->worker_id(), p, (void*) obj); 117 } Thanks Sent from my phone On Oct 2, 2012 5:54 PM, "John Cuthbertson" wrote: > Hi Everyone, > > Can I have another couple of volunteers review the changes for this CR - > the webrev can be found at: http://cr.openjdk.java.net/~** > johnc/7127708/webrev.0/ > > Summary: > Exactly what it says the the CR's description: > >> In G1's concurrent mark files we use an int for the task ID and call it >> "task num". Recent work done by Jon Masamitsu: >> >> 7121618: Change type of number of GC workers to unsigned int >> >> has replaced int's with uint's for the worker IDs across our GCs. We >> should also make the necessary changes in the G1 files to further conform >> to that. While we're at it we should also rename "task num" as "worker id" >> to be consistent with the rest of the GCs. >> > > > The changes were contributed by Kaushik Srenevasan from Twitter. I've > looked them over and they look OK to me. > > Testing: jtreg tests and specjvm (Kaushik); GC test suite with a low IHOP > and marking verification (JohnC); a jprt test run is in the queue. > > Thanks, > > JohnC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd-2012 at eckenfels.net Wed Oct 3 04:03:54 2012 From: bernd-2012 at eckenfels.net (Bernd Eckenfels) Date: Wed, 03 Oct 2012 06:03:54 +0200 Subject: date/timestamp for PrintCMSInitiationStatistics (was: Review request (S): 7176220: 'Full GC' events miss date stamp information occasionally) In-Reply-To: <506AE1D3.1050103@oracle.com> References: <5065757D.9060102@oracle.com> <506AE1D3.1050103@oracle.com> Message-ID: Am 02.10.2012, 14:45 Uhr, schrieb Bengt Rutisson : > I think this looks good. I like that we treat PrintGCDateStamps and > PrintGCTimeStamps in a consistent way. Oh and please fix this location as well, it produces a rather confusing message: # src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp:1508 # if (PrintCMSInitiationStatistics && stats().valid()) { # gclog_or_tty->print("CMSCollector shouldConcurrentCollect: "); # gclog_or_tty->stamp(); # gclog_or_tty->print_cr(""); Greetings Bernd From john.calvin at utoronto.ca Wed Oct 3 00:41:20 2012 From: john.calvin at utoronto.ca (John Calvin) Date: Wed, 3 Oct 2012 00:41:20 +0000 Subject: JVM fatal error in Par_ConcMarkingClosure::trim_queue Message-ID: <1D532B6B8971C641B23B36BF463156BA37D5AE0A@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Has anyone seen the bug below before? John Calvin Manager, Data Centres Enterprise Infrastructure Solutions, Information + Technology Services University of Toronto (416) 978-6878 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f54206e9127, pid=28861, tid=139998890891008 # # JRE version: 6.0_33-b03 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x3c5127] Par_ConcMarkingClosure::trim_queue(unsigned long)+0x77 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00007f541c0ab000): GCTaskThread [stack: 0x0000000000000000,0x0000000000000000] [id=28867] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000000039003b8 Registers: RAX=0x0000000000000001, RBX=0x00007f5408290c10, RCX=0x0000000000000003, RDX=0x00000000039003a8 RSP=0x00007f5408290bb0, RBP=0x00007f5408290be0, RSI=0x00000006a33e40b0, RDI=0x00007f5420dc61e0 R8 =0x0000000000000001, R9 =0x0000000000000001, R10=0x00000006a33e40b0, R11=0x00007f53fa7f0010 R12=0x0000000000000000, R13=0x0000000000000000, R14=0x0000000000000001, R15=0x0000000000000005 RIP=0x00007f54206e9127, EFLAGS=0x0000000000010202, CSGSFS=0x0000000000000033, ERR=0x0000000000000004 TRAPNO=0x000000000000000e Top of Stack: (sp=0x00007f5408290bb0) 0x00007f5408290bb0: 00007f53fa1e8958 00000006a33e40b0 0x00007f5408290bc0: 00007f5408290c10 00007f541c0aa8f8 0x00007f5408290bd0: 00007f541c0c10b0 00007f53fa1e8860 0x00007f5408290be0: 00007f5408290ca0 00007f54206e933a 0x00007f5408290bf0: 00007f53fa1e8970 00007f53fa1e8940 0x00007f5408290c00: 00007f541c0c0d64 00000006a3a64d68 0x00007f5408290c10: 00007f5420da2570 00007fff499cf800 0x00007f5408290c20: 00007f541c1045e0 00007f541c0aa5a0 0x00007f5408290c30: 00007f541c0aaa08 00007fff499cf801 0x00007f5408290c40: 00007f53fa1e8860 00000005c0000000 0x00007f5408290c50: 0000000048000000 00007f541c0aa7b8 0x00007f5408290c60: 00007f541c0aa8f8 00007f541c0c10b0 0x00007f5408290c70: 00000000506b5751 00007f5420daa148 0x00007f5408290c80: 00007f53fa1e8860 00007f5408290d00 0x00007f5408290c90: 0000000000000005 00007f5408290cb0 0x00007f5408290ca0: 00007f5408290d50 00007f54206e88ef 0x00007f5408290cb0: 00007f541c0ab000 00007f541c0abde0 0x00007f5408290cc0: 00007f541c0abe10 00007f541c0abe20 0x00007f5408290cd0: 00007f541c0ac1f8 00007f541c0ac200 0x00007f5408290ce0: 00007f541c0ab9c0 00007f541c0ab9f0 0x00007f5408290cf0: 00007f541c0aba00 00007f541c0abdd8 0x00007f5408290d00: 0000000000000000 000000006313f392 0x00007f5408290d10: 00007f541c0ab001 0000000000000005 0x00007f5408290d20: 00007f541c0ab000 0000000000000005 0x00007f5408290d30: 00007f541c0ab000 00007f541c0aaf10 0x00007f5408290d40: 00007f5408290d70 0000000000000007 0x00007f5408290d50: 00007f5408290dc0 00007f5420b9d05c 0x00007f5408290d60: 00007f541c0aaf10 00007f5420a2fa01 0x00007f5408290d70: 00007f541c0ab000 00007f53fa1e8860 0x00007f5408290d80: 00007f5400000002 00007f541c0ab000 0x00007f5408290d90: 00007f541c0aaf10 00007f5420a2c705 0x00007f5408290da0: 00007f541c0ab000 00007f541c0acb70 Instructions: (pc=0x00007f54206e9127) 0x00007f54206e9107: 45 67 80 00 48 8b 75 d8 80 3a 00 74 5e 48 8b 3d 0x00007f54206e9117: 0d 4b 80 00 8b 56 08 8b 4f 08 48 d3 e2 48 03 17 0x00007f54206e9127: 48 8b 42 10 48 8d 7a 10 48 89 da ff 90 98 01 00 0x00007f54206e9137: 00 48 8b 0d 51 39 80 00 31 d2 48 8b 7b 30 8b 01 Register to memory mapping: RAX=0x0000000000000001 is an unknown value RBX=0x00007f5408290c10 is an unknown value RCX=0x0000000000000003 is an unknown value RDX=0x00000000039003a8 is an unknown value RSP=0x00007f5408290bb0 is an unknown value RBP=0x00007f5408290be0 is an unknown value RSI=0x00000006a33e40b0 is an oop [C - klass: {type array char} - length: 215 RDI=0x00007f5420dc61e0: in /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so at 0x00007f5420324000 R8 =0x0000000000000001 is an unknown value R9 =0x0000000000000001 is an unknown value R10=0x00000006a33e40b0 is an oop [C - klass: {type array char} - length: 215 R11=0x00007f53fa7f0010 is an unknown value R12=0x0000000000000000 is an unknown value R13=0x0000000000000000 is an unknown value R14=0x0000000000000001 is an unknown value R15=0x0000000000000005 is an unknown value Stack: [0x0000000000000000,0x0000000000000000], sp=0x00007f5408290bb0, free space=136717666882k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x3c5127] Par_ConcMarkingClosure::trim_queue(unsigned long)+0x77 V [libjvm.so+0x3c533a] CMSConcMarkingTask::do_work_steal(int)+0xfa V [libjvm.so+0x3c48ef] CMSConcMarkingTask::work(int)+0xef V [libjvm.so+0x87905c] YieldingFlexibleGangWorker::loop()+0xbc V [libjvm.so+0x876234] GangWorker::run()+0x24 V [libjvm.so+0x7117af] java_start(Thread*)+0x13f --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x00007f53dc012000 JavaThread "Thread-6442" daemon [_thread_in_Java, id=5169, stack(0x00007f5395b2e000,0x00007f5395bf6000)] 0x00007f5380007000 JavaThread "Thread-6441" daemon [_thread_blocked, id=5168, stack(0x00007f539503e000,0x00007f5395106000)] 0x00007f5328005800 JavaThread "Thread-6440" daemon [_thread_blocked, id=5167, stack(0x00007f539599e000,0x00007f5395a66000)] 0x00007f53d8002000 JavaThread "Thread-6439" daemon [_thread_in_Java, id=5166, stack(0x00007f5395bf6000,0x00007f5395cbe000)] 0x00007f5340001800 JavaThread "Thread-6438" daemon [_thread_blocked, id=5165, stack(0x00007f53f8401000,0x00007f53f84c9000)] 0x00007f540009e800 JavaThread "Thread-6436" daemon [_thread_blocked, id=5163, stack(0x00007f5395a66000,0x00007f5395b2e000)] 0x00007f53a802e800 JavaThread "http-bio-8080-exec-34" daemon [_thread_blocked, id=4007, stack(0x00007f5395296000,0x00007f539535e000)] 0x00007f53a802d000 JavaThread "http-bio-8080-exec-33" daemon [_thread_in_native, id=4006, stack(0x00007f539535e000,0x00007f5395426000)] 0x00007f53a802b800 JavaThread "http-bio-8080-exec-32" daemon [_thread_blocked, id=4004, stack(0x00007f5395426000,0x00007f53954ee000)] 0x00007f53a802a800 JavaThread "http-bio-8080-exec-31" daemon [_thread_blocked, id=4003, stack(0x00007f53954ee000,0x00007f53955b6000)] 0x00007f53a802a000 JavaThread "http-bio-8080-exec-30" daemon [_thread_blocked, id=4002, stack(0x00007f53f8591000,0x00007f53f8659000)] 0x00007f53a8029000 JavaThread "http-bio-8080-exec-29" daemon [_thread_blocked, id=3998, stack(0x00007f53f8339000,0x00007f53f8401000)] 0x00007f53a8027000 JavaThread "http-bio-8080-exec-28" daemon [_thread_blocked, id=3988, stack(0x00007f53955b6000,0x00007f539567e000)] 0x00007f53a8025000 JavaThread "http-bio-8080-exec-27" daemon [_thread_blocked, id=3987, stack(0x00007f539567e000,0x00007f5395746000)] 0x00007f53a8023000 JavaThread "http-bio-8080-exec-26" daemon [_thread_blocked, id=3986, stack(0x00007f5395746000,0x00007f539580e000)] 0x00007f53a8021000 JavaThread "http-bio-8080-exec-25" daemon [_thread_blocked, id=3985, stack(0x00007f539580e000,0x00007f53958d6000)] 0x00007f53a8020000 JavaThread "http-bio-8080-exec-24" daemon [_thread_blocked, id=3981, stack(0x00007f5395f18000,0x00007f5395fe0000)] 0x00007f53a801f000 JavaThread "http-bio-8080-exec-23" daemon [_thread_in_Java, id=3980, stack(0x00007f53e1199000,0x00007f53e1261000)] 0x00007f5384007800 JavaThread "ThreadService-1" daemon [_thread_blocked, id=3574, stack(0x00007f5395e4e000,0x00007f5395f16000)] 0x00007f53a801d800 JavaThread "http-bio-8080-exec-22" daemon [_thread_blocked, id=3232, stack(0x00007f5395fe0000,0x00007f53960a8000)] 0x00007f53a801c000 JavaThread "http-bio-8080-exec-21" daemon [_thread_blocked, id=3230, stack(0x00007f53960a8000,0x00007f5396170000)] 0x00007f53a801a000 JavaThread "http-bio-8080-exec-20" daemon [_thread_in_native, id=3229, stack(0x00007f53e0069000,0x00007f53e0131000)] 0x00007f53a8019000 JavaThread "http-bio-8080-exec-19" daemon [_thread_blocked, id=3227, stack(0x00007f53e0131000,0x00007f53e01f9000)] 0x00007f53a8017800 JavaThread "http-bio-8080-exec-18" daemon [_thread_blocked, id=3225, stack(0x00007f53f84c9000,0x00007f53f8591000)] 0x00007f53a8016800 JavaThread "http-bio-8080-exec-17" daemon [_thread_blocked, id=3220, stack(0x00007f53e1009000,0x00007f53e10d1000)] 0x00007f53a8015800 JavaThread "http-bio-8080-exec-16" daemon [_thread_blocked, id=3219, stack(0x00007f5395cbe000,0x00007f5395d86000)] 0x00007f53a8014800 JavaThread "http-bio-8080-exec-15" daemon [_thread_blocked, id=1686, stack(0x00007f53e01f9000,0x00007f53e02c1000)] 0x00007f53a8013800 JavaThread "http-bio-8080-exec-14" daemon [_thread_in_Java, id=1685, stack(0x00007f53e0f41000,0x00007f53e1009000)] 0x00007f53a8012800 JavaThread "http-bio-8080-exec-13" daemon [_thread_blocked, id=1244, stack(0x00007f53f8659000,0x00007f53f8721000)] 0x00007f53a8011800 JavaThread "http-bio-8080-exec-12" daemon [_thread_blocked, id=1243, stack(0x00007f53f8721000,0x00007f53f87e9000)] 0x00007f53a8010800 JavaThread "http-bio-8080-exec-11" daemon [_thread_blocked, id=764, stack(0x00007f53e06a9000,0x00007f53e0771000)] 0x00007f53a800f800 JavaThread "http-bio-8080-exec-10" daemon [_thread_blocked, id=29120, stack(0x00007f53e0a91000,0x00007f53e0b59000)] 0x00007f53a800e800 JavaThread "http-bio-8080-exec-9" daemon [_thread_blocked, id=29118, stack(0x00007f53e0901000,0x00007f53e09c9000)] 0x00007f53a800d800 JavaThread "http-bio-8080-exec-8" daemon [_thread_in_vm, id=29116, stack(0x00007f53e09c9000,0x00007f53e0a91000)] 0x00007f53a800c800 JavaThread "http-bio-8080-exec-7" daemon [_thread_blocked, id=29114, stack(0x00007f53e0839000,0x00007f53e0901000)] 0x00007f53a800b800 JavaThread "http-bio-8080-exec-6" daemon [_thread_blocked, id=29112, stack(0x00007f53e0519000,0x00007f53e05e1000)] 0x00007f53a800a800 JavaThread "http-bio-8080-exec-5" daemon [_thread_in_Java, id=29110, stack(0x00007f53e0389000,0x00007f53e0451000)] 0x00007f53a8009800 JavaThread "http-bio-8080-exec-4" daemon [_thread_in_Java, id=29093, stack(0x00007f53e0ce9000,0x00007f53e0db1000)] 0x00007f53a8008800 JavaThread "http-bio-8080-exec-3" daemon [_thread_blocked, id=29091, stack(0x00007f53e0451000,0x00007f53e0519000)] 0x00007f53a8007800 JavaThread "http-bio-8080-exec-2" daemon [_thread_blocked, id=29089, stack(0x00007f53f87e9000,0x00007f53f88b1000)] 0x00007f53a8007000 JavaThread "http-bio-8080-exec-1" daemon [_thread_blocked, id=29028, stack(0x00007f53f88b1000,0x00007f53f8979000)] 0x00007f541c0f8800 JavaThread "ajp-bio-8009-AsyncTimeout" daemon [_thread_blocked, id=28995, stack(0x00007f53e0771000,0x00007f53e0839000)] 0x00007f541c0f7000 JavaThread "ajp-bio-8009-Acceptor-0" daemon [_thread_in_native, id=28994, stack(0x00007f53e02c1000,0x00007f53e0389000)] 0x00007f541c0f5800 JavaThread "http-bio-8080-AsyncTimeout" daemon [_thread_blocked, id=28993, stack(0x00007f53e0c21000,0x00007f53e0ce9000)] 0x00007f541c0f4800 JavaThread "http-bio-8080-Acceptor-0" daemon [_thread_in_native, id=28992, stack(0x00007f53e0e79000,0x00007f53e0f41000)] 0x00007f541c40a000 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=28991, stack(0x00007f53e0b59000,0x00007f53e0c21000)] 0x00007f5360e07000 JavaThread "kuali-course-search/KSB-pool-1-thread-1" [_thread_blocked, id=28990, stack(0x00007f53e05e1000,0x00007f53e06a9000)] 0x00007f5360b7f800 JavaThread "KSB-Scheduled-pool-1-thread-2" [_thread_blocked, id=28989, stack(0x00007f53e0db1000,0x00007f53e0e79000)] 0x00007f5360c5e800 JavaThread "locationCacheManager" daemon [_thread_blocked, id=28954, stack(0x00007f53e10d1000,0x00007f53e1199000)] 0x00007f5361344800 JavaThread "krmsCacheManager" daemon [_thread_blocked, id=28952, stack(0x00007f53e1261000,0x00007f53e1329000)] 0x00007f536106b800 JavaThread "Timer-1" daemon [_thread_blocked, id=28951, stack(0x00007f53e1329000,0x00007f53e13f1000)] 0x00007f5360da0800 JavaThread "notificationScheduler_QuartzSchedulerThread" [_thread_blocked, id=28950, stack(0x00007f53e13f1000,0x00007f53e14b9000)] 0x00007f53613b2800 JavaThread "notificationScheduler_Worker-10" [_thread_blocked, id=28949, stack(0x00007f53e14b9000,0x00007f53e1581000)] 0x00007f5360ee7000 JavaThread "notificationScheduler_Worker-9" [_thread_blocked, id=28948, stack(0x00007f53e1581000,0x00007f53e1649000)] 0x00007f5360f6b800 JavaThread "notificationScheduler_Worker-8" [_thread_blocked, id=28947, stack(0x00007f53e1649000,0x00007f53e1711000)] 0x00007f5360e44800 JavaThread "notificationScheduler_Worker-7" [_thread_blocked, id=28946, stack(0x00007f53e1711000,0x00007f53e17d9000)] 0x00007f5361310800 JavaThread "notificationScheduler_Worker-6" [_thread_blocked, id=28945, stack(0x00007f53e17d9000,0x00007f53e18a1000)] 0x00007f536134a800 JavaThread "notificationScheduler_Worker-5" [_thread_blocked, id=28944, stack(0x00007f53e18a1000,0x00007f53e1969000)] 0x00007f5361094000 JavaThread "notificationScheduler_Worker-4" [_thread_blocked, id=28943, stack(0x00007f53e1969000,0x00007f53e1a31000)] 0x00007f5360cf9800 JavaThread "notificationScheduler_Worker-3" [_thread_blocked, id=28942, stack(0x00007f53e1a31000,0x00007f53e1af9000)] 0x00007f5360aec800 JavaThread "notificationScheduler_Worker-2" [_thread_blocked, id=28941, stack(0x00007f53e1af9000,0x00007f53e1bc1000)] 0x00007f5361008800 JavaThread "notificationScheduler_Worker-1" [_thread_blocked, id=28940, stack(0x00007f53e1bc1000,0x00007f53e1c89000)] 0x00007f5361064800 JavaThread "pool-3-thread-1" [_thread_blocked, id=28939, stack(0x00007f53e1c89000,0x00007f53e1d51000)] 0x00007f5361089000 JavaThread "ServerPluginRegistry-pool-2-thread-2" [_thread_blocked, id=28938, stack(0x00007f53e1d51000,0x00007f53e1e19000)] 0x00007f5360c01800 JavaThread "ServerPluginRegistry-pool-2-thread-1" [_thread_blocked, id=28937, stack(0x00007f53e1e19000,0x00007f53e1ee1000)] 0x00007f5360cd7000 JavaThread "kewCacheManager" daemon [_thread_blocked, id=28935, stack(0x00007f53e1ee1000,0x00007f53e1fa9000)] 0x00007f5360eff800 JavaThread "KSB-Scheduled-pool-1-thread-1" [_thread_blocked, id=28934, stack(0x00007f53e1fa9000,0x00007f53e2071000)] 0x00007f5361080000 JavaThread "kimCacheManager" daemon [_thread_blocked, id=28933, stack(0x00007f53e2071000,0x00007f53e2139000)] 0x00007f5360d5a800 JavaThread "coreServiceCacheManager" daemon [_thread_blocked, id=28932, stack(0x00007f53e23d1000,0x00007f53e2499000)] 0x00007f5360ec0000 JavaThread "Thread-4" daemon [_thread_blocked, id=28931, stack(0x00007f53e2139000,0x00007f53e2201000)] 0x00007f5384005800 JavaThread "ThreadService-0" daemon [_thread_blocked, id=28930, stack(0x00007f53e2309000,0x00007f53e23d1000)] 0x00007f5360b4c000 JavaThread "Timer-0" daemon [_thread_blocked, id=28927, stack(0x00007f53e269f000,0x00007f53e2767000)] 0x00007f53606bd000 JavaThread "rice.ksb.scheduler_QuartzSchedulerThread" [_thread_blocked, id=28926, stack(0x00007f53e2767000,0x00007f53e282f000)] 0x00007f5360a74000 JavaThread "rice.ksb.scheduler_Worker-10" [_thread_blocked, id=28925, stack(0x00007f53e282f000,0x00007f53e28f7000)] 0x00007f5360bc5800 JavaThread "rice.ksb.scheduler_Worker-9" [_thread_blocked, id=28924, stack(0x00007f53e28f7000,0x00007f53e29bf000)] 0x00007f5360ba3800 JavaThread "rice.ksb.scheduler_Worker-8" [_thread_blocked, id=28923, stack(0x00007f53e29bf000,0x00007f53e2a87000)] 0x00007f5360bb4800 JavaThread "rice.ksb.scheduler_Worker-7" [_thread_blocked, id=28922, stack(0x00007f53e2a87000,0x00007f53e2b4f000)] 0x00007f5360bbe000 JavaThread "rice.ksb.scheduler_Worker-6" [_thread_blocked, id=28921, stack(0x00007f53e2b4f000,0x00007f53e2c17000)] 0x00007f5360a0f800 JavaThread "rice.ksb.scheduler_Worker-5" [_thread_blocked, id=28920, stack(0x00007f53e2c17000,0x00007f53e2cdf000)] 0x00007f5360a98000 JavaThread "rice.ksb.scheduler_Worker-4" [_thread_blocked, id=28919, stack(0x00007f53e2cdf000,0x00007f53e2da7000)] 0x00007f5360c98000 JavaThread "rice.ksb.scheduler_Worker-3" [_thread_blocked, id=28918, stack(0x00007f53e2da7000,0x00007f53e2e6f000)] 0x00007f53606f1000 JavaThread "rice.ksb.scheduler_Worker-2" [_thread_blocked, id=28917, stack(0x00007f53e2e6f000,0x00007f53e2f37000)] 0x00007f5360c93000 JavaThread "rice.ksb.scheduler_Worker-1" [_thread_blocked, id=28916, stack(0x00007f53e2f37000,0x00007f53e2fff000)] 0x00007f5360afa000 JavaThread "JotmClock" daemon [_thread_blocked, id=28915, stack(0x00007f53f807d000,0x00007f53f8145000)] 0x00007f5360a78000 JavaThread "JotmBatch" daemon [_thread_blocked, id=28914, stack(0x00007f53f8145000,0x00007f53f820d000)] 0x00007f5360b4f800 JavaThread "RMI Reaper" [_thread_blocked, id=28913, stack(0x00007f53f820d000,0x00007f53f82d5000)] 0x00007f541c338000 JavaThread "GC Daemon" daemon [_thread_blocked, id=28893, stack(0x00007f53f897c000,0x00007f53f8a44000)] 0x00007f541c211800 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=28891, stack(0x00007f53f8b45000,0x00007f53f8c0d000)] 0x00007f541c20b800 JavaThread "RMI TCP Accept-8999" daemon [_thread_in_native, id=28890, stack(0x00007f53f8c0d000,0x00007f53f8cd5000)] 0x00007f541c204000 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=28889, stack(0x00007f53f8cd5000,0x00007f53f8d9d000)] 0x00007f541c1bc000 JavaThread "CommunicatorServer" daemon [_thread_in_native, id=28888, stack(0x00007f53f8d9d000,0x00007f53f8e65000)] 0x00007f541c135800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=28887, stack(0x00007f53f9083000,0x00007f53f914b000)] 0x00007f541c132800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=28886, stack(0x00007f53f914b000,0x00007f53f924c000)] 0x00007f541c130800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=28885, stack(0x00007f53f924c000,0x00007f53f934d000)] 0x00007f541c12e800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=28884, stack(0x00007f53f934d000,0x00007f53f9415000)] 0x00007f541c12c800 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=28883, stack(0x00007f53f9415000,0x00007f53f94dd000)] 0x00007f541c10f800 JavaThread "Finalizer" daemon [_thread_blocked, id=28882, stack(0x00007f53f94dd000,0x00007f53f95a5000)] 0x00007f541c10e000 JavaThread "Reference Handler" daemon [_thread_blocked, id=28881, stack(0x00007f53f95a5000,0x00007f53f966d000)] 0x00007f541c008800 JavaThread "main" [_thread_in_native, id=28862, stack(0x00007f542025c000,0x00007f5420324000)] Other Threads: 0x00007f541c107000 VMThread [stack: 0x00007f53f966d000,0x00007f53f976e000] [id=28880] 0x00007f541c214000 WatcherThread [stack: 0x00007f53f8a44000,0x00007f53f8b45000] [id=28892] =>0x00007f541c0ab000 (exited) GCTaskThread [stack: 0x0000000000000000,0x0000000000000000] [id=28867] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap par new generation total 3947584K, used 2152986K [0x00000004c0000000, 0x00000005c0000000, 0x00000005c0000000) eden space 3700864K, 51% used [0x00000004c0000000, 0x0000000534596ac0, 0x00000005a1e20000) from space 246720K, 100% used [0x00000005a1e20000, 0x00000005b0f10000, 0x00000005b0f10000) to space 246720K, 0% used [0x00000005b0f10000, 0x00000005b0f10000, 0x00000005c0000000) concurrent mark-sweep generation total 8388608K, used 5088536K [0x00000005c0000000, 0x00000007c0000000, 0x00000007c0000000) concurrent-mark-sweep perm gen total 1048576K, used 108044K [0x00000007c0000000, 0x0000000800000000, 0x0000000800000000) Code Cache [0x00007f540bcde000, 0x00007f541bcde000, 0x00007f541bcde000) total_blobs=5085 nmethods=4325 adapters=711 free_code_cache=248021120 largest_free_block=21760 Dynamic libraries: 40000000-40009000 r-xp 00000000 fd:00 795119 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/bin/java 40108000-4010b000 rwxp 00008000 fd:00 795119 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/bin/java 405fb000-40661000 rwxp 00000000 00:00 0 [heap] 4c0000000-800000000 rwxp 00000000 00:00 0 32c5a00000-32c5a20000 r-xp 00000000 fd:00 656068 /lib64/ld-2.12.so 32c5c1f000-32c5c20000 r-xp 0001f000 fd:00 656068 /lib64/ld-2.12.so 32c5c20000-32c5c21000 rwxp 00020000 fd:00 656068 /lib64/ld-2.12.so 32c5c21000-32c5c22000 rwxp 00000000 00:00 0 32c5e00000-32c5e02000 r-xp 00000000 fd:00 656091 /lib64/libdl-2.12.so 32c5e02000-32c6002000 ---p 00002000 fd:00 656091 /lib64/libdl-2.12.so 32c6002000-32c6003000 r-xp 00002000 fd:00 656091 /lib64/libdl-2.12.so 32c6003000-32c6004000 rwxp 00003000 fd:00 656091 /lib64/libdl-2.12.so 32c6200000-32c6389000 r-xp 00000000 fd:00 656075 /lib64/libc-2.12.so 32c6389000-32c6588000 ---p 00189000 fd:00 656075 /lib64/libc-2.12.so 32c6588000-32c658c000 r-xp 00188000 fd:00 656075 /lib64/libc-2.12.so 32c658c000-32c658d000 rwxp 0018c000 fd:00 656075 /lib64/libc-2.12.so 32c658d000-32c6592000 rwxp 00000000 00:00 0 32c6600000-32c6617000 r-xp 00000000 fd:00 658369 /lib64/libpthread-2.12.so 32c6617000-32c6817000 ---p 00017000 fd:00 658369 /lib64/libpthread-2.12.so 32c6817000-32c6818000 r-xp 00017000 fd:00 658369 /lib64/libpthread-2.12.so 32c6818000-32c6819000 rwxp 00018000 fd:00 658369 /lib64/libpthread-2.12.so 32c6819000-32c681d000 rwxp 00000000 00:00 0 32c6a00000-32c6a83000 r-xp 00000000 fd:00 656864 /lib64/libm-2.12.so 32c6a83000-32c6c82000 ---p 00083000 fd:00 656864 /lib64/libm-2.12.so 32c6c82000-32c6c83000 r-xp 00082000 fd:00 656864 /lib64/libm-2.12.so 32c6c83000-32c6c84000 rwxp 00083000 fd:00 656864 /lib64/libm-2.12.so 32c6e00000-32c6e07000 r-xp 00000000 fd:00 656195 /lib64/librt-2.12.so 32c6e07000-32c7006000 ---p 00007000 fd:00 656195 /lib64/librt-2.12.so 32c7006000-32c7007000 r-xp 00006000 fd:00 656195 /lib64/librt-2.12.so 32c7007000-32c7008000 rwxp 00007000 fd:00 656195 /lib64/librt-2.12.so 32c8200000-32c8216000 r-xp 00000000 fd:00 659776 /lib64/libresolv-2.12.so 32c8216000-32c8416000 ---p 00016000 fd:00 659776 /lib64/libresolv-2.12.so 32c8416000-32c8417000 r-xp 00016000 fd:00 659776 /lib64/libresolv-2.12.so 32c8417000-32c8418000 rwxp 00017000 fd:00 659776 /lib64/libresolv-2.12.so 32c8418000-32c841a000 rwxp 00000000 00:00 0 32c9600000-32c9616000 r-xp 00000000 fd:00 658286 /lib64/libnsl-2.12.so 32c9616000-32c9815000 ---p 00016000 fd:00 658286 /lib64/libnsl-2.12.so 32c9815000-32c9816000 r-xp 00015000 fd:00 658286 /lib64/libnsl-2.12.so 32c9816000-32c9817000 rwxp 00016000 fd:00 658286 /lib64/libnsl-2.12.so 32c9817000-32c9819000 rwxp 00000000 00:00 0 3e6fc00000-3e6fc07000 r-xp 00000000 fd:00 922346 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so 3e6fc07000-3e6fd08000 ---p 00007000 fd:00 922346 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so 3e6fd08000-3e6fd0a000 rwxp 00008000 fd:00 922346 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so 7f5328000000-7f532804e000 rwxp 00000000 00:00 0 7f532804e000-7f532c000000 ---p 00000000 00:00 0 7f5330000000-7f533004d000 rwxp 00000000 00:00 0 7f533004d000-7f5334000000 ---p 00000000 00:00 0 7f5334000000-7f533408c000 rwxp 00000000 00:00 0 7f533408c000-7f5338000000 ---p 00000000 00:00 0 7f5338000000-7f533805f000 rwxp 00000000 00:00 0 7f533805f000-7f533c000000 ---p 00000000 00:00 0 7f533c000000-7f533c021000 rwxp 00000000 00:00 0 7f533c021000-7f5340000000 ---p 00000000 00:00 0 7f5340000000-7f534006c000 rwxp 00000000 00:00 0 7f534006c000-7f5344000000 ---p 00000000 00:00 0 7f5344000000-7f5344021000 rwxp 00000000 00:00 0 7f5344021000-7f5348000000 ---p 00000000 00:00 0 7f5348000000-7f534806e000 rwxp 00000000 00:00 0 7f534806e000-7f534c000000 ---p 00000000 00:00 0 7f534c000000-7f534c065000 rwxp 00000000 00:00 0 7f534c065000-7f5350000000 ---p 00000000 00:00 0 7f5350000000-7f5350079000 rwxp 00000000 00:00 0 7f5350079000-7f5354000000 ---p 00000000 00:00 0 7f5354000000-7f5354021000 rwxp 00000000 00:00 0 7f5354021000-7f5358000000 ---p 00000000 00:00 0 7f5358000000-7f5358021000 rwxp 00000000 00:00 0 7f5358021000-7f535c000000 ---p 00000000 00:00 0 7f535c000000-7f535c021000 rwxp 00000000 00:00 0 7f535c021000-7f5360000000 ---p 00000000 00:00 0 7f5360000000-7f5361bd3000 rwxp 00000000 00:00 0 7f5361bd3000-7f5364000000 ---p 00000000 00:00 0 7f5364000000-7f5364a01000 rwxp 00000000 00:00 0 7f5364a01000-7f5368000000 ---p 00000000 00:00 0 7f5368000000-7f5368046000 rwxp 00000000 00:00 0 7f5368046000-7f536c000000 ---p 00000000 00:00 0 7f536c000000-7f536c1a5000 rwxp 00000000 00:00 0 7f536c1a5000-7f5370000000 ---p 00000000 00:00 0 7f5370000000-7f5370045000 rwxp 00000000 00:00 0 7f5370045000-7f5374000000 ---p 00000000 00:00 0 7f5374000000-7f5374044000 rwxp 00000000 00:00 0 7f5374044000-7f5378000000 ---p 00000000 00:00 0 7f5378000000-7f5378045000 rwxp 00000000 00:00 0 7f5378045000-7f537c000000 ---p 00000000 00:00 0 7f537c000000-7f537c062000 rwxp 00000000 00:00 0 7f537c062000-7f5380000000 ---p 00000000 00:00 0 7f5380000000-7f538004a000 rwxp 00000000 00:00 0 7f538004a000-7f5384000000 ---p 00000000 00:00 0 7f5384000000-7f5384095000 rwxp 00000000 00:00 0 7f5384095000-7f5388000000 ---p 00000000 00:00 0 7f5388000000-7f538bffa000 rwxp 00000000 00:00 0 7f538bffa000-7f538c000000 ---p 00000000 00:00 0 7f538c000000-7f538fffd000 rwxp 00000000 00:00 0 7f538fffd000-7f5390000000 ---p 00000000 00:00 0 7f5390000000-7f5390021000 rwxp 00000000 00:00 0 7f5390021000-7f5394000000 ---p 00000000 00:00 0 7f539503e000-7f5395041000 ---p 00000000 00:00 0 7f5395041000-7f5395106000 rwxp 00000000 00:00 0 7f5395106000-7f5395109000 ---p 00000000 00:00 0 7f5395109000-7f53951ce000 rwxp 00000000 00:00 0 7f53951ce000-7f53951d1000 ---p 00000000 00:00 0 7f53951d1000-7f5395296000 rwxp 00000000 00:00 0 7f5395296000-7f5395299000 ---p 00000000 00:00 0 7f5395299000-7f539535e000 rwxp 00000000 00:00 0 7f539535e000-7f5395361000 ---p 00000000 00:00 0 7f5395361000-7f5395426000 rwxp 00000000 00:00 0 7f5395426000-7f5395429000 ---p 00000000 00:00 0 7f5395429000-7f53954ee000 rwxp 00000000 00:00 0 7f53954ee000-7f53954f1000 ---p 00000000 00:00 0 7f53954f1000-7f53955b6000 rwxp 00000000 00:00 0 7f53955b6000-7f53955b9000 ---p 00000000 00:00 0 7f53955b9000-7f539567e000 rwxp 00000000 00:00 0 7f539567e000-7f5395681000 ---p 00000000 00:00 0 7f5395681000-7f5395746000 rwxp 00000000 00:00 0 7f5395746000-7f5395749000 ---p 00000000 00:00 0 7f5395749000-7f539580e000 rwxp 00000000 00:00 0 7f539580e000-7f5395811000 ---p 00000000 00:00 0 7f5395811000-7f53958d6000 rwxp 00000000 00:00 0 7f53958d6000-7f53958d9000 ---p 00000000 00:00 0 7f53958d9000-7f539599e000 rwxp 00000000 00:00 0 7f539599e000-7f53959a1000 ---p 00000000 00:00 0 7f53959a1000-7f5395a66000 rwxp 00000000 00:00 0 7f5395a66000-7f5395a69000 ---p 00000000 00:00 0 7f5395a69000-7f5395b2e000 rwxp 00000000 00:00 0 7f5395b2e000-7f5395b31000 ---p 00000000 00:00 0 7f5395b31000-7f5395bf6000 rwxp 00000000 00:00 0 7f5395bf6000-7f5395bf9000 ---p 00000000 00:00 0 7f5395bf9000-7f5395cbe000 rwxp 00000000 00:00 0 7f5395cbe000-7f5395cc1000 ---p 00000000 00:00 0 7f5395cc1000-7f5395d86000 rwxp 00000000 00:00 0 7f5395d86000-7f5395d89000 ---p 00000000 00:00 0 7f5395d89000-7f5395e4e000 rwxp 00000000 00:00 0 7f5395e4e000-7f5395e51000 ---p 00000000 00:00 0 7f5395e51000-7f5395f16000 rwxp 00000000 00:00 0 7f5395f18000-7f5395f1b000 ---p 00000000 00:00 0 7f5395f1b000-7f5395fe0000 rwxp 00000000 00:00 0 7f5395fe0000-7f5395fe3000 ---p 00000000 00:00 0 7f5395fe3000-7f53960a8000 rwxp 00000000 00:00 0 7f53960a8000-7f53960ab000 ---p 00000000 00:00 0 7f53960ab000-7f5396170000 rwxp 00000000 00:00 0 7f5396170000-7f539c000000 r-xp 00000000 fd:00 534941 /usr/lib/locale/locale-archive 7f539c000000-7f539c054000 rwxp 00000000 00:00 0 7f539c054000-7f53a0000000 ---p 00000000 00:00 0 7f53a0000000-7f53a008a000 rwxp 00000000 00:00 0 7f53a008a000-7f53a4000000 ---p 00000000 00:00 0 7f53a4000000-7f53a4222000 rwxp 00000000 00:00 0 7f53a4222000-7f53a8000000 ---p 00000000 00:00 0 7f53a8000000-7f53a8030000 rwxp 00000000 00:00 0 7f53a8030000-7f53ac000000 ---p 00000000 00:00 0 7f53ac000000-7f53ac021000 rwxp 00000000 00:00 0 7f53ac021000-7f53b0000000 ---p 00000000 00:00 0 7f53b0000000-7f53b01b8000 rwxp 00000000 00:00 0 7f53b01b8000-7f53b4000000 ---p 00000000 00:00 0 7f53b4000000-7f53b41ef000 rwxp 00000000 00:00 0 7f53b41ef000-7f53b8000000 ---p 00000000 00:00 0 7f53b8000000-7f53b8021000 rwxp 00000000 00:00 0 7f53b8021000-7f53bc000000 ---p 00000000 00:00 0 7f53bc000000-7f53bc185000 rwxp 00000000 00:00 0 7f53bc185000-7f53c0000000 ---p 00000000 00:00 0 7f53c0000000-7f53c017d000 rwxp 00000000 00:00 0 7f53c017d000-7f53c4000000 ---p 00000000 00:00 0 7f53c4000000-7f53c4021000 rwxp 00000000 00:00 0 7f53c4021000-7f53c8000000 ---p 00000000 00:00 0 7f53c8000000-7f53c81a7000 rwxp 00000000 00:00 0 7f53c81a7000-7f53cc000000 ---p 00000000 00:00 0 7f53cc000000-7f53cc021000 rwxp 00000000 00:00 0 7f53cc021000-7f53d0000000 ---p 00000000 00:00 0 7f53d0000000-7f53d005d000 rwxp 00000000 00:00 0 7f53d005d000-7f53d4000000 ---p 00000000 00:00 0 7f53d4000000-7f53d41a6000 rwxp 00000000 00:00 0 7f53d41a6000-7f53d8000000 ---p 00000000 00:00 0 7f53d8000000-7f53d81a8000 rwxp 00000000 00:00 0 7f53d81a8000-7f53dc000000 ---p 00000000 00:00 0 7f53dc000000-7f53dc2c7000 rwxp 00000000 00:00 0 7f53dc2c7000-7f53e0000000 ---p 00000000 00:00 0 7f53e0069000-7f53e006c000 ---p 00000000 00:00 0 7f53e006c000-7f53e0131000 rwxp 00000000 00:00 0 7f53e0131000-7f53e0134000 ---p 00000000 00:00 0 7f53e0134000-7f53e01f9000 rwxp 00000000 00:00 0 7f53e01f9000-7f53e01fc000 ---p 00000000 00:00 0 7f53e01fc000-7f53e02c1000 rwxp 00000000 00:00 0 7f53e02c1000-7f53e02c4000 ---p 00000000 00:00 0 7f53e02c4000-7f53e0389000 rwxp 00000000 00:00 0 7f53e0389000-7f53e038c000 ---p 00000000 00:00 0 7f53e038c000-7f53e0451000 rwxp 00000000 00:00 0 7f53e0451000-7f53e0454000 ---p 00000000 00:00 0 7f53e0454000-7f53e0519000 rwxp 00000000 00:00 0 7f53e0519000-7f53e051c000 ---p 00000000 00:00 0 7f53e051c000-7f53e05e1000 rwxp 00000000 00:00 0 7f53e05e1000-7f53e05e4000 ---p 00000000 00:00 0 7f53e05e4000-7f53e06a9000 rwxp 00000000 00:00 0 7f53e06a9000-7f53e06ac000 ---p 00000000 00:00 0 7f53e06ac000-7f53e0771000 rwxp 00000000 00:00 0 7f53e0771000-7f53e0774000 ---p 00000000 00:00 0 7f53e0774000-7f53e0839000 rwxp 00000000 00:00 0 7f53e0839000-7f53e083c000 ---p 00000000 00:00 0 7f53e083c000-7f53e0901000 rwxp 00000000 00:00 0 7f53e0901000-7f53e0904000 ---p 00000000 00:00 0 7f53e0904000-7f53e09c9000 rwxp 00000000 00:00 0 7f53e09c9000-7f53e09cc000 ---p 00000000 00:00 0 7f53e09cc000-7f53e0a91000 rwxp 00000000 00:00 0 7f53e0a91000-7f53e0a94000 ---p 00000000 00:00 0 7f53e0a94000-7f53e0b59000 rwxp 00000000 00:00 0 7f53e0b59000-7f53e0b5c000 ---p 00000000 00:00 0 7f53e0b5c000-7f53e0c21000 rwxp 00000000 00:00 0 7f53e0c21000-7f53e0c24000 ---p 00000000 00:00 0 7f53e0c24000-7f53e0ce9000 rwxp 00000000 00:00 0 7f53e0ce9000-7f53e0cec000 ---p 00000000 00:00 0 7f53e0cec000-7f53e0db1000 rwxp 00000000 00:00 0 7f53e0db1000-7f53e0db4000 ---p 00000000 00:00 0 7f53e0db4000-7f53e0e79000 rwxp 00000000 00:00 0 7f53e0e79000-7f53e0e7c000 ---p 00000000 00:00 0 7f53e0e7c000-7f53e0f41000 rwxp 00000000 00:00 0 7f53e0f41000-7f53e0f44000 ---p 00000000 00:00 0 7f53e0f44000-7f53e1009000 rwxp 00000000 00:00 0 7f53e1009000-7f53e100c000 ---p 00000000 00:00 0 7f53e100c000-7f53e10d1000 rwxp 00000000 00:00 0 7f53e10d1000-7f53e10d4000 ---p 00000000 00:00 0 7f53e10d4000-7f53e1199000 rwxp 00000000 00:00 0 7f53e1199000-7f53e119c000 ---p 00000000 00:00 0 7f53e119c000-7f53e1261000 rwxp 00000000 00:00 0 7f53e1261000-7f53e1264000 ---p 00000000 00:00 0 7f53e1264000-7f53e1329000 rwxp 00000000 00:00 0 7f53e1329000-7f53e132c000 ---p 00000000 00:00 0 7f53e132c000-7f53e13f1000 rwxp 00000000 00:00 0 7f53e13f1000-7f53e13f4000 ---p 00000000 00:00 0 7f53e13f4000-7f53e14b9000 rwxp 00000000 00:00 0 7f53e14b9000-7f53e14bc000 ---p 00000000 00:00 0 7f53e14bc000-7f53e1581000 rwxp 00000000 00:00 0 7f53e1581000-7f53e1584000 ---p 00000000 00:00 0 7f53e1584000-7f53e1649000 rwxp 00000000 00:00 0 7f53e1649000-7f53e164c000 ---p 00000000 00:00 0 7f53e164c000-7f53e1711000 rwxp 00000000 00:00 0 7f53e1711000-7f53e1714000 ---p 00000000 00:00 0 7f53e1714000-7f53e17d9000 rwxp 00000000 00:00 0 7f53e17d9000-7f53e17dc000 ---p 00000000 00:00 0 7f53e17dc000-7f53e18a1000 rwxp 00000000 00:00 0 7f53e18a1000-7f53e18a4000 ---p 00000000 00:00 0 7f53e18a4000-7f53e1969000 rwxp 00000000 00:00 0 7f53e1969000-7f53e196c000 ---p 00000000 00:00 0 7f53e196c000-7f53e1a31000 rwxp 00000000 00:00 0 7f53e1a31000-7f53e1a34000 ---p 00000000 00:00 0 7f53e1a34000-7f53e1af9000 rwxp 00000000 00:00 0 7f53e1af9000-7f53e1afc000 ---p 00000000 00:00 0 7f53e1afc000-7f53e1bc1000 rwxp 00000000 00:00 0 7f53e1bc1000-7f53e1bc4000 ---p 00000000 00:00 0 7f53e1bc4000-7f53e1c89000 rwxp 00000000 00:00 0 7f53e1c89000-7f53e1c8c000 ---p 00000000 00:00 0 7f53e1c8c000-7f53e1d51000 rwxp 00000000 00:00 0 7f53e1d51000-7f53e1d54000 ---p 00000000 00:00 0 7f53e1d54000-7f53e1e19000 rwxp 00000000 00:00 0 7f53e1e19000-7f53e1e1c000 ---p 00000000 00:00 0 7f53e1e1c000-7f53e1ee1000 rwxp 00000000 00:00 0 7f53e1ee1000-7f53e1ee4000 ---p 00000000 00:00 0 7f53e1ee4000-7f53e1fa9000 rwxp 00000000 00:00 0 7f53e1fa9000-7f53e1fac000 ---p 00000000 00:00 0 7f53e1fac000-7f53e2071000 rwxp 00000000 00:00 0 7f53e2071000-7f53e2074000 ---p 00000000 00:00 0 7f53e2074000-7f53e2139000 rwxp 00000000 00:00 0 7f53e2139000-7f53e213c000 ---p 00000000 00:00 0 7f53e213c000-7f53e2201000 rwxp 00000000 00:00 0 7f53e2201000-7f53e2208000 r-xp 00000000 fd:00 928246 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so 7f53e2208000-7f53e2307000 ---p 00007000 fd:00 928246 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so 7f53e2307000-7f53e2309000 rwxp 00006000 fd:00 928246 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so 7f53e2309000-7f53e230c000 ---p 00000000 00:00 0 7f53e230c000-7f53e23d1000 rwxp 00000000 00:00 0 7f53e23d1000-7f53e23d4000 ---p 00000000 00:00 0 7f53e23d4000-7f53e2499000 rwxp 00000000 00:00 0 7f53e2499000-7f53e249e000 r-xp 00000000 fd:00 656088 /lib64/libnss_dns-2.12.so 7f53e249e000-7f53e269d000 ---p 00005000 fd:00 656088 /lib64/libnss_dns-2.12.so 7f53e269d000-7f53e269e000 r-xp 00004000 fd:00 656088 /lib64/libnss_dns-2.12.so 7f53e269e000-7f53e269f000 rwxp 00005000 fd:00 656088 /lib64/libnss_dns-2.12.so 7f53e269f000-7f53e26a2000 ---p 00000000 00:00 0 7f53e26a2000-7f53e2767000 rwxp 00000000 00:00 0 7f53e2767000-7f53e276a000 ---p 00000000 00:00 0 7f53e276a000-7f53e282f000 rwxp 00000000 00:00 0 7f53e282f000-7f53e2832000 ---p 00000000 00:00 0 7f53e2832000-7f53e28f7000 rwxp 00000000 00:00 0 7f53e28f7000-7f53e28fa000 ---p 00000000 00:00 0 7f53e28fa000-7f53e29bf000 rwxp 00000000 00:00 0 7f53e29bf000-7f53e29c2000 ---p 00000000 00:00 0 7f53e29c2000-7f53e2a87000 rwxp 00000000 00:00 0 7f53e2a87000-7f53e2a8a000 ---p 00000000 00:00 0 7f53e2a8a000-7f53e2b4f000 rwxp 00000000 00:00 0 7f53e2b4f000-7f53e2b52000 ---p 00000000 00:00 0 7f53e2b52000-7f53e2c17000 rwxp 00000000 00:00 0 7f53e2c17000-7f53e2c1a000 ---p 00000000 00:00 0 7f53e2c1a000-7f53e2cdf000 rwxp 00000000 00:00 0 7f53e2cdf000-7f53e2ce2000 ---p 00000000 00:00 0 7f53e2ce2000-7f53e2da7000 rwxp 00000000 00:00 0 7f53e2da7000-7f53e2daa000 ---p 00000000 00:00 0 7f53e2daa000-7f53e2e6f000 rwxp 00000000 00:00 0 7f53e2e6f000-7f53e2e72000 ---p 00000000 00:00 0 7f53e2e72000-7f53e2f37000 rwxp 00000000 00:00 0 7f53e2f37000-7f53e2f3a000 ---p 00000000 00:00 0 7f53e2f3a000-7f53f4000000 rwxp 00000000 00:00 0 7f53f4000000-7f53f4040000 rwxp 00000000 00:00 0 7f53f4040000-7f53f8000000 ---p 00000000 00:00 0 7f53f805f000-7f53f806e000 r-xs 00667000 fd:00 928264 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/charsets.jar 7f53f806e000-7f53f807d000 r-xs 00667000 fd:00 928264 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/charsets.jar 7f53f807d000-7f53f8080000 ---p 00000000 00:00 0 7f53f8080000-7f53f8145000 rwxp 00000000 00:00 0 7f53f8145000-7f53f8148000 ---p 00000000 00:00 0 7f53f8148000-7f53f820d000 rwxp 00000000 00:00 0 7f53f820d000-7f53f8210000 ---p 00000000 00:00 0 7f53f8210000-7f53f82d5000 rwxp 00000000 00:00 0 7f53f8339000-7f53f833c000 ---p 00000000 00:00 0 7f53f833c000-7f53f8401000 rwxp 00000000 00:00 0 7f53f8401000-7f53f8404000 ---p 00000000 00:00 0 7f53f8404000-7f53f84c9000 rwxp 00000000 00:00 0 7f53f84c9000-7f53f84cc000 ---p 00000000 00:00 0 7f53f84cc000-7f53f8591000 rwxp 00000000 00:00 0 7f53f8591000-7f53f8594000 ---p 00000000 00:00 0 7f53f8594000-7f53f8659000 rwxp 00000000 00:00 0 7f53f8659000-7f53f865c000 ---p 00000000 00:00 0 7f53f865c000-7f53f8721000 rwxp 00000000 00:00 0 7f53f8721000-7f53f8724000 ---p 00000000 00:00 0 7f53f8724000-7f53f87e9000 rwxp 00000000 00:00 0 7f53f87e9000-7f53f87ec000 ---p 00000000 00:00 0 7f53f87ec000-7f53f88b1000 rwxp 00000000 00:00 0 7f53f88b1000-7f53f88b4000 ---p 00000000 00:00 0 7f53f88b4000-7f53f8979000 rwxp 00000000 00:00 0 7f53f8979000-7f53f897c000 r-xs 00027000 fd:00 1447062 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/sunjce_provider.jar 7f53f897c000-7f53f897f000 ---p 00000000 00:00 0 7f53f897f000-7f53f8a44000 rwxp 00000000 00:00 0 7f53f8a44000-7f53f8a45000 ---p 00000000 00:00 0 7f53f8a45000-7f53f8b45000 rwxp 00000000 00:00 0 7f53f8b45000-7f53f8b48000 ---p 00000000 00:00 0 7f53f8b48000-7f53f8c0d000 rwxp 00000000 00:00 0 7f53f8c0d000-7f53f8c10000 ---p 00000000 00:00 0 7f53f8c10000-7f53f8cd5000 rwxp 00000000 00:00 0 7f53f8cd5000-7f53f8cd8000 ---p 00000000 00:00 0 7f53f8cd8000-7f53f8d9d000 rwxp 00000000 00:00 0 7f53f8d9d000-7f53f8da0000 ---p 00000000 00:00 0 7f53f8da0000-7f53f8e65000 rwxp 00000000 00:00 0 7f53f8e65000-7f53f8e6b000 r-xp 00000000 fd:00 928241 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so 7f53f8e6b000-7f53f8f6a000 ---p 00006000 fd:00 928241 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so 7f53f8f6a000-7f53f8f6c000 rwxp 00005000 fd:00 928241 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so 7f53f8f6c000-7f53f8f7f000 r-xp 00000000 fd:00 928245 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so 7f53f8f7f000-7f53f9080000 ---p 00013000 fd:00 928245 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so 7f53f9080000-7f53f9083000 rwxp 00014000 fd:00 928245 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so 7f53f9083000-7f53f9086000 ---p 00000000 00:00 0 7f53f9086000-7f53f914b000 rwxp 00000000 00:00 0 7f53f914b000-7f53f914e000 ---p 00000000 00:00 0 7f53f914e000-7f53f924c000 rwxp 00000000 00:00 0 7f53f924c000-7f53f924f000 ---p 00000000 00:00 0 7f53f924f000-7f53f934d000 rwxp 00000000 00:00 0 7f53f934d000-7f53f9350000 ---p 00000000 00:00 0 7f53f9350000-7f53f9415000 rwxp 00000000 00:00 0 7f53f9415000-7f53f9418000 ---p 00000000 00:00 0 7f53f9418000-7f53f94dd000 rwxp 00000000 00:00 0 7f53f94dd000-7f53f94e0000 ---p 00000000 00:00 0 7f53f94e0000-7f53f95a5000 rwxp 00000000 00:00 0 7f53f95a5000-7f53f95a8000 ---p 00000000 00:00 0 7f53f95a8000-7f53f966d000 rwxp 00000000 00:00 0 7f53f966d000-7f53f966e000 ---p 00000000 00:00 0 7f53f966e000-7f53f97a2000 rwxp 00000000 00:00 0 7f53f97a2000-7f53f9939000 r-xs 0307a000 fd:00 928317 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/rt.jar 7f53f9939000-7f53fa0e9000 rwxp 00000000 00:00 0 7f53fa0e9000-7f53fa0ea000 ---p 00000000 00:00 0 7f53fa0ea000-7f53fadf6000 rwxp 00000000 00:00 0 7f53fadf6000-7f53fadf7000 ---p 00000000 00:00 0 7f53fadf7000-7f53faef7000 rwxp 00000000 00:00 0 7f53faef7000-7f53faef8000 ---p 00000000 00:00 0 7f53faef8000-7f53faff8000 rwxp 00000000 00:00 0 7f53faff8000-7f53faff9000 ---p 00000000 00:00 0 7f53faff9000-7f53fb0f9000 rwxp 00000000 00:00 0 7f53fb0f9000-7f53fb0fa000 ---p 00000000 00:00 0 7f53fb0fa000-7f53fb1fa000 rwxp 00000000 00:00 0 7f53fb1fa000-7f53fb1fb000 ---p 00000000 00:00 0 7f53fb1fb000-7f53fb2fb000 rwxp 00000000 00:00 0 7f53fb2fb000-7f53fb2fc000 ---p 00000000 00:00 0 7f53fb2fc000-7f53fb3fc000 rwxp 00000000 00:00 0 7f53fb3fc000-7f53fb3fd000 ---p 00000000 00:00 0 7f53fb3fd000-7f53fb4fd000 rwxp 00000000 00:00 0 7f53fb4fd000-7f53fb4fe000 ---p 00000000 00:00 0 7f53fb4fe000-7f53fb5fe000 rwxp 00000000 00:00 0 7f53fb5fe000-7f53fb5ff000 ---p 00000000 00:00 0 7f53fb5ff000-7f53fb6ff000 rwxp 00000000 00:00 0 7f53fb6ff000-7f53fb700000 ---p 00000000 00:00 0 7f53fb700000-7f53fc000000 rwxp 00000000 00:00 0 7f53fc000000-7f53fc145000 rwxp 00000000 00:00 0 7f53fc145000-7f5400000000 ---p 00000000 00:00 0 7f5400000000-7f540016f000 rwxp 00000000 00:00 0 7f540016f000-7f5404000000 ---p 00000000 00:00 0 7f5404000000-7f540406a000 rwxp 00000000 00:00 0 7f540406a000-7f5408000000 ---p 00000000 00:00 0 7f5408000000-7f5408004000 r-xs 00035000 fd:00 1447063 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/sunpkcs11.jar 7f5408004000-7f540800c000 r-xs 00115000 fd:00 928316 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/resources.jar 7f540800c000-7f5408012000 r-xs 00095000 fd:00 928303 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/jsse.jar 7f5408012000-7f540801f000 r-xs 000b5000 fd:00 2228415 /opt/tomcat/lib/tomcat-coyote.jar 7f540801f000-7f5408024000 r-xs 0003a000 fd:00 2228406 /opt/tomcat/lib/catalina-tribes.jar 7f5408024000-7f5408025000 r-xs 00005000 fd:00 2228421 /opt/tomcat/lib/tomcat-util.jar 7f5408025000-7f5408027000 r-xs 0000b000 fd:00 2228419 /opt/tomcat/lib/tomcat-i18n-ja.jar 7f5408027000-7f540802b000 r-xs 00036000 fd:00 2228416 /opt/tomcat/lib/tomcat-dbcp.jar 7f540802b000-7f540802c000 r-xs 00001000 fd:00 2228414 /opt/tomcat/lib/tomcat-api.jar 7f540802c000-7f540803c000 r-xs 0019c000 fd:00 2228408 /opt/tomcat/lib/ecj-3.7.2.jar 7f540803c000-7f540803f000 r-xs 0001c000 fd:00 2228420 /opt/tomcat/lib/tomcat-jdbc.jar 7f540803f000-7f5408042000 r-xs 00013000 fd:00 2228412 /opt/tomcat/lib/jsp-api.jar 7f5408042000-7f5408044000 r-xs 0000a000 fd:00 2228418 /opt/tomcat/lib/tomcat-i18n-fr.jar 7f5408044000-7f5408047000 r-xs 0001c000 fd:00 2228410 /opt/tomcat/lib/jasper-el.jar 7f5408047000-7f540804a000 r-xs 00029000 fd:00 2228413 /opt/tomcat/lib/servlet-api.jar 7f540804a000-7f540804c000 r-xs 0000c000 fd:00 2228404 /opt/tomcat/lib/catalina-ant.jar 7f540804c000-7f540805f000 r-xs 00169000 fd:00 2228407 /opt/tomcat/lib/catalina.jar 7f540805f000-7f5408090000 rwxp 00000000 00:00 0 7f5408090000-7f5408091000 ---p 00000000 00:00 0 7f5408091000-7f5408191000 rwxp 00000000 00:00 0 7f5408191000-7f5408192000 ---p 00000000 00:00 0 7f5408192000-7f540b4d9000 rwxp 00000000 00:00 0 7f540b4d9000-7f540b4da000 rwxp 00000000 00:00 0 7f540b4da000-7f540b4db000 ---p 00000000 00:00 0 7f540b4db000-7f540b5db000 rwxp 00000000 00:00 0 7f540b5db000-7f540b5dc000 ---p 00000000 00:00 0 7f540b5dc000-7f540b6dc000 rwxp 00000000 00:00 0 7f540b6dc000-7f540b6dd000 ---p 00000000 00:00 0 7f540b6dd000-7f540b7dd000 rwxp 00000000 00:00 0 7f540b7dd000-7f540b7de000 ---p 00000000 00:00 0 7f540b7de000-7f541bcde000 rwxp 00000000 00:00 0 7f541bcde000-7f541bcec000 r-xp 00000000 fd:00 928254 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so 7f541bcec000-7f541bdee000 ---p 0000e000 fd:00 928254 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so 7f541bdee000-7f541bdf1000 rwxp 00010000 fd:00 928254 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so 7f541bdf1000-7f541bdf2000 rwxp 00000000 00:00 0 7f541bdf2000-7f541bdfe000 r-xp 00000000 fd:00 656090 /lib64/libnss_files-2.12.so 7f541bdfe000-7f541bffe000 ---p 0000c000 fd:00 656090 /lib64/libnss_files-2.12.so 7f541bffe000-7f541bfff000 r-xp 0000c000 fd:00 656090 /lib64/libnss_files-2.12.so 7f541bfff000-7f541c000000 rwxp 0000d000 fd:00 656090 /lib64/libnss_files-2.12.so 7f541c000000-7f541c470000 rwxp 00000000 00:00 0 7f541c470000-7f5420000000 ---p 00000000 00:00 0 7f5420002000-7f5420005000 r-xs 00013000 fd:00 928301 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/jce.jar 7f5420005000-7f5420008000 r-xs 000cc000 fd:00 1447060 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/localedata.jar 7f5420008000-7f5420009000 r-xs 00003000 fd:00 2228403 /opt/tomcat/lib/annotations-api.jar 7f5420009000-7f542000b000 r-xs 00011000 fd:00 2228417 /opt/tomcat/lib/tomcat-i18n-es.jar 7f542000b000-7f5420013000 r-xs 00089000 fd:00 2228411 /opt/tomcat/lib/jasper.jar 7f5420013000-7f5420015000 r-xs 0000a000 fd:00 2228409 /opt/tomcat/lib/el-api.jar 7f5420015000-7f5420018000 r-xs 0001e000 fd:00 2228405 /opt/tomcat/lib/catalina-ha.jar 7f5420018000-7f5420019000 rwxp 00000000 00:00 0 7f5420019000-7f542001b000 r-xs 00008000 fd:00 2228399 /opt/tomcat/bin/tomcat-juli.jar 7f542001b000-7f542001c000 r-xs 00005000 fd:00 2228392 /opt/tomcat/bin/commons-daemon.jar 7f542001c000-7f542001e000 r-xs 00006000 fd:00 2228388 /opt/tomcat/bin/bootstrap.jar 7f542001e000-7f5420047000 r-xp 00000000 fd:00 928233 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so 7f5420047000-7f5420146000 ---p 00029000 fd:00 928233 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so 7f5420146000-7f542014d000 rwxp 00028000 fd:00 928233 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so 7f542014d000-7f542015a000 r-xp 00000000 fd:00 928253 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so 7f542015a000-7f5420259000 ---p 0000d000 fd:00 928253 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so 7f5420259000-7f542025c000 rwxp 0000c000 fd:00 928253 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so 7f542025c000-7f542025f000 ---p 00000000 00:00 0 7f542025f000-7f5420324000 rwxp 00000000 00:00 0 7f5420324000-7f5420c3f000 r-xp 00000000 fd:00 928262 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so 7f5420c3f000-7f5420d40000 ---p 0091b000 fd:00 928262 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so 7f5420d40000-7f5420ef5000 rwxp 0091c000 fd:00 928262 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so 7f5420ef5000-7f5420f33000 rwxp 00000000 00:00 0 7f5420f33000-7f5420f3b000 rwxs 00000000 fd:00 795098 /tmp/hsperfdata_ramire79/28861 7f5420f3b000-7f5420f3c000 rwxp 00000000 00:00 0 7f5420f3c000-7f5420f3d000 r-xp 00000000 00:00 0 7f5420f3d000-7f5420f3f000 rwxp 00000000 00:00 0 7fff4984d000-7fff49863000 rwxp 00000000 00:00 0 [stack] 7fff499cf000-7fff499d0000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] VM Arguments: jvm_args: -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Xms12g -Xmx12g -Xss800k -XX:OldSize=8g -XX:NewSize=4g -XX:MaxNewSize=4g -XX:NewRatio=3 -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:InitialCodeCacheSize=256m -XX:ReservedCodeCacheSize=256m -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=15 -XX:StackShadowPages=10 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+UseTLAB -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads=12 -XX:+ParallelRefProcEnabled -XX:CMSMarkStackSize=16M -XX:CMSMarkStackSizeMax=16M -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:PrintCMSStatistics=2 -XX:+PrintVMOptions -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCTaskTimeStamps -XX:+PrintCommandLineFlags -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCDateStamps -Xloggc:/opt/tomcat/logs/gc.log -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dcom.sun.management.snmp.interface=0.0.0.0 -Dcom.sun.management.snmp.port=8161 -Dcom.sun.management.snmp.acl=false -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=qa1.kuali.utoronto.ca -Djava.endorsed.dirs=/opt/tomcat/endorsed -Dcatalina.base=/opt/tomcat -Dcatalina.home=/opt/tomcat -Djava.io.tmpdir=/opt/tomcat/temp java_command: org.apache.catalina.startup.Bootstrap start Launcher Type: SUN_STANDARD Environment Variables: PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ramire79/bin LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/../lib/amd64 SHELL=/bin/bash Signal Handlers: SIGSEGV: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGBUS: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGFPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGPIPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGXFSZ: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGILL: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGUSR2: [libjvm.so+0x711de0], sa_mask[0]=0x00000000, sa_flags=0x10000004 SIGHUP: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGTERM: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGQUIT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 --------------- S Y S T E M --------------- OS:Red Hat Enterprise Linux Server release 6.3 (Santiago) uname:Linux 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 libc:glibc 2.12 NPTL 2.12 rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 4096, AS infinity load average:6.24 3.43 1.80 /proc/meminfo: MemTotal: 16334044 kB MemFree: 5305268 kB Buffers: 136684 kB Cached: 502616 kB SwapCached: 0 kB Active: 10435928 kB Inactive: 205704 kB Active(anon): 10002492 kB Inactive(anon): 16 kB Active(file): 433436 kB Inactive(file): 205688 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 6160376 kB SwapFree: 6160376 kB Dirty: 208 kB Writeback: 0 kB AnonPages: 10002112 kB Mapped: 30296 kB Shmem: 184 kB Slab: 162636 kB SReclaimable: 126780 kB SUnreclaim: 35856 kB KernelStack: 2840 kB PageTables: 25960 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 14327396 kB Committed_AS: 14826588 kB VmallocTotal: 34359738367 kB VmallocUsed: 304312 kB VmallocChunk: 34359428600 kB HardwareCorrupted: 0 kB AnonHugePages: 9627648 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M: 16766976 kB CPU:total 6 (1 cores per cpu, 1 threads per core) family 16 model 8 stepping 0, cmov, cx8, fxsr, mmx, sse, sse2, sse3, popcnt, mmxext, 3dnowpref, lzcnt, sse4a /proc/cpuinfo: processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 8 model name: Six-Core AMD Opteron(tm) Processor 2439 SE stepping: 0 cpu MHz: 2800.113 cache size: 512 KB fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch bogomips: 5600.22 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 1 vendor_id: AuthenticAMD cpu family: 16 model: 8 model name: Six-Core AMD Opteron(tm) Processor 2439 SE stepping: 0 cpu MHz: 2800.113 cache size: 512 KB fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch bogomips: 5600.22 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 2 vendor_id: AuthenticAMD cpu family: 16 model: 8 model name: Six-Core AMD Opteron(tm) Processor 2439 SE stepping: 0 cpu MHz: 2800.113 cache size: 512 KB fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch bogomips: 5600.22 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 3 vendor_id: AuthenticAMD cpu family: 16 model: 8 model name: Six-Core AMD Opteron(tm) Processor 2439 SE stepping: 0 cpu MHz: 2800.113 cache size: 512 KB fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch bogomips: 5600.22 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 4 vendor_id: AuthenticAMD cpu family: 16 model: 8 model name: Six-Core AMD Opteron(tm) Processor 2439 SE stepping: 0 cpu MHz: 2800.113 cache size: 512 KB fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch bogomips: 5600.22 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 5 vendor_id: AuthenticAMD cpu family: 16 model: 8 model name: Six-Core AMD Opteron(tm) Processor 2439 SE stepping: 0 cpu MHz: 2800.113 cache size: 512 KB fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch bogomips: 5600.22 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Memory: 4k page, physical 16334044k(5305268k free), swap 6160376k(6160376k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (20.8-b03) for linux-amd64 JRE (1.6.0_33-b03), built on May 9 2012 09:57:57 by "java_re" with gcc 3.2.2 (SuSE Linux) time: Tue Oct 2 17:06:26 2012 elapsed time: 1663 seconds [root at course-search-as-qa bin]# From ysr1729 at gmail.com Wed Oct 3 08:35:21 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 3 Oct 2012 01:35:21 -0700 Subject: JVM fatal error in Par_ConcMarkingClosure::trim_queue In-Reply-To: <1D532B6B8971C641B23B36BF463156BA37D5AE0A@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> References: <1D532B6B8971C641B23B36BF463156BA37D5AE0A@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Message-ID: Hi John -- Why are you using -XX:ParallelCMSThreads=12 on a 6 processor machine, while using -XX:ParallelGCThreads=4. Recall that the former determines the number of parallel marking threads in the concurrent marking phase while the latter is the number of parallel GC threads used in the stop-world phases (minor gc's and CMS remark pauses). Of course, one still shouldn't crash just because you used options that seem counter-intuitive to performance .... The crash is in the multi-threaded concurrent marking code. You could try dropping -XX:ParallelCMSThreads=12 entirely and add -XX:-CMSConcurrentMTEnabled, thus turning off parallel marking to see if it makes any difference. It probably won't because crashes during marking typically imply either a bug in GC or more likely a card-marking error (typically a missed card-mark in JIT'd code which leads to a GC error). Otherwise, if the crash persists with verification enabled, you might want to see if that gets you closer to the root case: -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeGC -XX:+VerufyDuringGC (at considerable slow down in the GC's because of the verification). Typically the verification slows everything so much that many crashes will refuse to reproduce. Hopefully someone else will have better suggestions... or know about this bug... best regards. -- ramki On Tue, Oct 2, 2012 at 5:41 PM, John Calvin wrote: > Has anyone seen the bug below before? > > John Calvin > Manager, Data Centres > Enterprise Infrastructure Solutions, > Information + Technology Services > University of Toronto > (416) 978-6878 > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f54206e9127, pid=28861, tid=139998890891008 > # > # JRE version: 6.0_33-b03 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode > linux-amd64 compressed oops) > # Problematic frame: > # V [libjvm.so+0x3c5127] Par_ConcMarkingClosure::trim_queue(unsigned > long)+0x77 > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007f541c0ab000): GCTaskThread [stack: > 0x0000000000000000,0x0000000000000000] [id=28867] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), > si_addr=0x00000000039003b8 > > Registers: > RAX=0x0000000000000001, RBX=0x00007f5408290c10, RCX=0x0000000000000003, > RDX=0x00000000039003a8 > RSP=0x00007f5408290bb0, RBP=0x00007f5408290be0, RSI=0x00000006a33e40b0, > RDI=0x00007f5420dc61e0 > R8 =0x0000000000000001, R9 =0x0000000000000001, R10=0x00000006a33e40b0, > R11=0x00007f53fa7f0010 > R12=0x0000000000000000, R13=0x0000000000000000, R14=0x0000000000000001, > R15=0x0000000000000005 > RIP=0x00007f54206e9127, EFLAGS=0x0000000000010202, > CSGSFS=0x0000000000000033, ERR=0x0000000000000004 > TRAPNO=0x000000000000000e > > Top of Stack: (sp=0x00007f5408290bb0) > 0x00007f5408290bb0: 00007f53fa1e8958 00000006a33e40b0 > 0x00007f5408290bc0: 00007f5408290c10 00007f541c0aa8f8 > 0x00007f5408290bd0: 00007f541c0c10b0 00007f53fa1e8860 > 0x00007f5408290be0: 00007f5408290ca0 00007f54206e933a > 0x00007f5408290bf0: 00007f53fa1e8970 00007f53fa1e8940 > 0x00007f5408290c00: 00007f541c0c0d64 00000006a3a64d68 > 0x00007f5408290c10: 00007f5420da2570 00007fff499cf800 > 0x00007f5408290c20: 00007f541c1045e0 00007f541c0aa5a0 > 0x00007f5408290c30: 00007f541c0aaa08 00007fff499cf801 > 0x00007f5408290c40: 00007f53fa1e8860 00000005c0000000 > 0x00007f5408290c50: 0000000048000000 00007f541c0aa7b8 > 0x00007f5408290c60: 00007f541c0aa8f8 00007f541c0c10b0 > 0x00007f5408290c70: 00000000506b5751 00007f5420daa148 > 0x00007f5408290c80: 00007f53fa1e8860 00007f5408290d00 > 0x00007f5408290c90: 0000000000000005 00007f5408290cb0 > 0x00007f5408290ca0: 00007f5408290d50 00007f54206e88ef > 0x00007f5408290cb0: 00007f541c0ab000 00007f541c0abde0 > 0x00007f5408290cc0: 00007f541c0abe10 00007f541c0abe20 > 0x00007f5408290cd0: 00007f541c0ac1f8 00007f541c0ac200 > 0x00007f5408290ce0: 00007f541c0ab9c0 00007f541c0ab9f0 > 0x00007f5408290cf0: 00007f541c0aba00 00007f541c0abdd8 > 0x00007f5408290d00: 0000000000000000 000000006313f392 > 0x00007f5408290d10: 00007f541c0ab001 0000000000000005 > 0x00007f5408290d20: 00007f541c0ab000 0000000000000005 > 0x00007f5408290d30: 00007f541c0ab000 00007f541c0aaf10 > 0x00007f5408290d40: 00007f5408290d70 0000000000000007 > 0x00007f5408290d50: 00007f5408290dc0 00007f5420b9d05c > 0x00007f5408290d60: 00007f541c0aaf10 00007f5420a2fa01 > 0x00007f5408290d70: 00007f541c0ab000 00007f53fa1e8860 > 0x00007f5408290d80: 00007f5400000002 00007f541c0ab000 > 0x00007f5408290d90: 00007f541c0aaf10 00007f5420a2c705 > 0x00007f5408290da0: 00007f541c0ab000 00007f541c0acb70 > > Instructions: (pc=0x00007f54206e9127) > 0x00007f54206e9107: 45 67 80 00 48 8b 75 d8 80 3a 00 74 5e 48 8b 3d > 0x00007f54206e9117: 0d 4b 80 00 8b 56 08 8b 4f 08 48 d3 e2 48 03 17 > 0x00007f54206e9127: 48 8b 42 10 48 8d 7a 10 48 89 da ff 90 98 01 00 > 0x00007f54206e9137: 00 48 8b 0d 51 39 80 00 31 d2 48 8b 7b 30 8b 01 > > Register to memory mapping: > > RAX=0x0000000000000001 is an unknown value > RBX=0x00007f5408290c10 is an unknown value > RCX=0x0000000000000003 is an unknown value > RDX=0x00000000039003a8 is an unknown value > RSP=0x00007f5408290bb0 is an unknown value > RBP=0x00007f5408290be0 is an unknown value > RSI=0x00000006a33e40b0 is an oop > [C > - klass: {type array char} > - length: 215 > RDI=0x00007f5420dc61e0: in > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > at 0x00007f5420324000 > R8 =0x0000000000000001 is an unknown value > R9 =0x0000000000000001 is an unknown value > R10=0x00000006a33e40b0 is an oop > [C > - klass: {type array char} > - length: 215 > R11=0x00007f53fa7f0010 is an unknown value > R12=0x0000000000000000 is an unknown value > R13=0x0000000000000000 is an unknown value > R14=0x0000000000000001 is an unknown value > R15=0x0000000000000005 is an unknown value > > > Stack: [0x0000000000000000,0x0000000000000000], sp=0x00007f5408290bb0, > free space=136717666882k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0x3c5127] Par_ConcMarkingClosure::trim_queue(unsigned > long)+0x77 > V [libjvm.so+0x3c533a] CMSConcMarkingTask::do_work_steal(int)+0xfa > V [libjvm.so+0x3c48ef] CMSConcMarkingTask::work(int)+0xef > V [libjvm.so+0x87905c] YieldingFlexibleGangWorker::loop()+0xbc > V [libjvm.so+0x876234] GangWorker::run()+0x24 > V [libjvm.so+0x7117af] java_start(Thread*)+0x13f > > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00007f53dc012000 JavaThread "Thread-6442" daemon [_thread_in_Java, > id=5169, stack(0x00007f5395b2e000,0x00007f5395bf6000)] > 0x00007f5380007000 JavaThread "Thread-6441" daemon [_thread_blocked, > id=5168, stack(0x00007f539503e000,0x00007f5395106000)] > 0x00007f5328005800 JavaThread "Thread-6440" daemon [_thread_blocked, > id=5167, stack(0x00007f539599e000,0x00007f5395a66000)] > 0x00007f53d8002000 JavaThread "Thread-6439" daemon [_thread_in_Java, > id=5166, stack(0x00007f5395bf6000,0x00007f5395cbe000)] > 0x00007f5340001800 JavaThread "Thread-6438" daemon [_thread_blocked, > id=5165, stack(0x00007f53f8401000,0x00007f53f84c9000)] > 0x00007f540009e800 JavaThread "Thread-6436" daemon [_thread_blocked, > id=5163, stack(0x00007f5395a66000,0x00007f5395b2e000)] > 0x00007f53a802e800 JavaThread "http-bio-8080-exec-34" daemon > [_thread_blocked, id=4007, stack(0x00007f5395296000,0x00007f539535e000)] > 0x00007f53a802d000 JavaThread "http-bio-8080-exec-33" daemon > [_thread_in_native, id=4006, stack(0x00007f539535e000,0x00007f5395426000)] > 0x00007f53a802b800 JavaThread "http-bio-8080-exec-32" daemon > [_thread_blocked, id=4004, stack(0x00007f5395426000,0x00007f53954ee000)] > 0x00007f53a802a800 JavaThread "http-bio-8080-exec-31" daemon > [_thread_blocked, id=4003, stack(0x00007f53954ee000,0x00007f53955b6000)] > 0x00007f53a802a000 JavaThread "http-bio-8080-exec-30" daemon > [_thread_blocked, id=4002, stack(0x00007f53f8591000,0x00007f53f8659000)] > 0x00007f53a8029000 JavaThread "http-bio-8080-exec-29" daemon > [_thread_blocked, id=3998, stack(0x00007f53f8339000,0x00007f53f8401000)] > 0x00007f53a8027000 JavaThread "http-bio-8080-exec-28" daemon > [_thread_blocked, id=3988, stack(0x00007f53955b6000,0x00007f539567e000)] > 0x00007f53a8025000 JavaThread "http-bio-8080-exec-27" daemon > [_thread_blocked, id=3987, stack(0x00007f539567e000,0x00007f5395746000)] > 0x00007f53a8023000 JavaThread "http-bio-8080-exec-26" daemon > [_thread_blocked, id=3986, stack(0x00007f5395746000,0x00007f539580e000)] > 0x00007f53a8021000 JavaThread "http-bio-8080-exec-25" daemon > [_thread_blocked, id=3985, stack(0x00007f539580e000,0x00007f53958d6000)] > 0x00007f53a8020000 JavaThread "http-bio-8080-exec-24" daemon > [_thread_blocked, id=3981, stack(0x00007f5395f18000,0x00007f5395fe0000)] > 0x00007f53a801f000 JavaThread "http-bio-8080-exec-23" daemon > [_thread_in_Java, id=3980, stack(0x00007f53e1199000,0x00007f53e1261000)] > 0x00007f5384007800 JavaThread "ThreadService-1" daemon [_thread_blocked, > id=3574, stack(0x00007f5395e4e000,0x00007f5395f16000)] > 0x00007f53a801d800 JavaThread "http-bio-8080-exec-22" daemon > [_thread_blocked, id=3232, stack(0x00007f5395fe0000,0x00007f53960a8000)] > 0x00007f53a801c000 JavaThread "http-bio-8080-exec-21" daemon > [_thread_blocked, id=3230, stack(0x00007f53960a8000,0x00007f5396170000)] > 0x00007f53a801a000 JavaThread "http-bio-8080-exec-20" daemon > [_thread_in_native, id=3229, stack(0x00007f53e0069000,0x00007f53e0131000)] > 0x00007f53a8019000 JavaThread "http-bio-8080-exec-19" daemon > [_thread_blocked, id=3227, stack(0x00007f53e0131000,0x00007f53e01f9000)] > 0x00007f53a8017800 JavaThread "http-bio-8080-exec-18" daemon > [_thread_blocked, id=3225, stack(0x00007f53f84c9000,0x00007f53f8591000)] > 0x00007f53a8016800 JavaThread "http-bio-8080-exec-17" daemon > [_thread_blocked, id=3220, stack(0x00007f53e1009000,0x00007f53e10d1000)] > 0x00007f53a8015800 JavaThread "http-bio-8080-exec-16" daemon > [_thread_blocked, id=3219, stack(0x00007f5395cbe000,0x00007f5395d86000)] > 0x00007f53a8014800 JavaThread "http-bio-8080-exec-15" daemon > [_thread_blocked, id=1686, stack(0x00007f53e01f9000,0x00007f53e02c1000)] > 0x00007f53a8013800 JavaThread "http-bio-8080-exec-14" daemon > [_thread_in_Java, id=1685, stack(0x00007f53e0f41000,0x00007f53e1009000)] > 0x00007f53a8012800 JavaThread "http-bio-8080-exec-13" daemon > [_thread_blocked, id=1244, stack(0x00007f53f8659000,0x00007f53f8721000)] > 0x00007f53a8011800 JavaThread "http-bio-8080-exec-12" daemon > [_thread_blocked, id=1243, stack(0x00007f53f8721000,0x00007f53f87e9000)] > 0x00007f53a8010800 JavaThread "http-bio-8080-exec-11" daemon > [_thread_blocked, id=764, stack(0x00007f53e06a9000,0x00007f53e0771000)] > 0x00007f53a800f800 JavaThread "http-bio-8080-exec-10" daemon > [_thread_blocked, id=29120, stack(0x00007f53e0a91000,0x00007f53e0b59000)] > 0x00007f53a800e800 JavaThread "http-bio-8080-exec-9" daemon > [_thread_blocked, id=29118, stack(0x00007f53e0901000,0x00007f53e09c9000)] > 0x00007f53a800d800 JavaThread "http-bio-8080-exec-8" daemon > [_thread_in_vm, id=29116, stack(0x00007f53e09c9000,0x00007f53e0a91000)] > 0x00007f53a800c800 JavaThread "http-bio-8080-exec-7" daemon > [_thread_blocked, id=29114, stack(0x00007f53e0839000,0x00007f53e0901000)] > 0x00007f53a800b800 JavaThread "http-bio-8080-exec-6" daemon > [_thread_blocked, id=29112, stack(0x00007f53e0519000,0x00007f53e05e1000)] > 0x00007f53a800a800 JavaThread "http-bio-8080-exec-5" daemon > [_thread_in_Java, id=29110, stack(0x00007f53e0389000,0x00007f53e0451000)] > 0x00007f53a8009800 JavaThread "http-bio-8080-exec-4" daemon > [_thread_in_Java, id=29093, stack(0x00007f53e0ce9000,0x00007f53e0db1000)] > 0x00007f53a8008800 JavaThread "http-bio-8080-exec-3" daemon > [_thread_blocked, id=29091, stack(0x00007f53e0451000,0x00007f53e0519000)] > 0x00007f53a8007800 JavaThread "http-bio-8080-exec-2" daemon > [_thread_blocked, id=29089, stack(0x00007f53f87e9000,0x00007f53f88b1000)] > 0x00007f53a8007000 JavaThread "http-bio-8080-exec-1" daemon > [_thread_blocked, id=29028, stack(0x00007f53f88b1000,0x00007f53f8979000)] > 0x00007f541c0f8800 JavaThread "ajp-bio-8009-AsyncTimeout" daemon > [_thread_blocked, id=28995, stack(0x00007f53e0771000,0x00007f53e0839000)] > 0x00007f541c0f7000 JavaThread "ajp-bio-8009-Acceptor-0" daemon > [_thread_in_native, id=28994, stack(0x00007f53e02c1000,0x00007f53e0389000)] > 0x00007f541c0f5800 JavaThread "http-bio-8080-AsyncTimeout" daemon > [_thread_blocked, id=28993, stack(0x00007f53e0c21000,0x00007f53e0ce9000)] > 0x00007f541c0f4800 JavaThread "http-bio-8080-Acceptor-0" daemon > [_thread_in_native, id=28992, stack(0x00007f53e0e79000,0x00007f53e0f41000)] > 0x00007f541c40a000 JavaThread > "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon > [_thread_blocked, id=28991, stack(0x00007f53e0b59000,0x00007f53e0c21000)] > 0x00007f5360e07000 JavaThread "kuali-course-search/KSB-pool-1-thread-1" > [_thread_blocked, id=28990, stack(0x00007f53e05e1000,0x00007f53e06a9000)] > 0x00007f5360b7f800 JavaThread "KSB-Scheduled-pool-1-thread-2" > [_thread_blocked, id=28989, stack(0x00007f53e0db1000,0x00007f53e0e79000)] > 0x00007f5360c5e800 JavaThread "locationCacheManager" daemon > [_thread_blocked, id=28954, stack(0x00007f53e10d1000,0x00007f53e1199000)] > 0x00007f5361344800 JavaThread "krmsCacheManager" daemon > [_thread_blocked, id=28952, stack(0x00007f53e1261000,0x00007f53e1329000)] > 0x00007f536106b800 JavaThread "Timer-1" daemon [_thread_blocked, > id=28951, stack(0x00007f53e1329000,0x00007f53e13f1000)] > 0x00007f5360da0800 JavaThread > "notificationScheduler_QuartzSchedulerThread" [_thread_blocked, id=28950, > stack(0x00007f53e13f1000,0x00007f53e14b9000)] > 0x00007f53613b2800 JavaThread "notificationScheduler_Worker-10" > [_thread_blocked, id=28949, stack(0x00007f53e14b9000,0x00007f53e1581000)] > 0x00007f5360ee7000 JavaThread "notificationScheduler_Worker-9" > [_thread_blocked, id=28948, stack(0x00007f53e1581000,0x00007f53e1649000)] > 0x00007f5360f6b800 JavaThread "notificationScheduler_Worker-8" > [_thread_blocked, id=28947, stack(0x00007f53e1649000,0x00007f53e1711000)] > 0x00007f5360e44800 JavaThread "notificationScheduler_Worker-7" > [_thread_blocked, id=28946, stack(0x00007f53e1711000,0x00007f53e17d9000)] > 0x00007f5361310800 JavaThread "notificationScheduler_Worker-6" > [_thread_blocked, id=28945, stack(0x00007f53e17d9000,0x00007f53e18a1000)] > 0x00007f536134a800 JavaThread "notificationScheduler_Worker-5" > [_thread_blocked, id=28944, stack(0x00007f53e18a1000,0x00007f53e1969000)] > 0x00007f5361094000 JavaThread "notificationScheduler_Worker-4" > [_thread_blocked, id=28943, stack(0x00007f53e1969000,0x00007f53e1a31000)] > 0x00007f5360cf9800 JavaThread "notificationScheduler_Worker-3" > [_thread_blocked, id=28942, stack(0x00007f53e1a31000,0x00007f53e1af9000)] > 0x00007f5360aec800 JavaThread "notificationScheduler_Worker-2" > [_thread_blocked, id=28941, stack(0x00007f53e1af9000,0x00007f53e1bc1000)] > 0x00007f5361008800 JavaThread "notificationScheduler_Worker-1" > [_thread_blocked, id=28940, stack(0x00007f53e1bc1000,0x00007f53e1c89000)] > 0x00007f5361064800 JavaThread "pool-3-thread-1" [_thread_blocked, > id=28939, stack(0x00007f53e1c89000,0x00007f53e1d51000)] > 0x00007f5361089000 JavaThread "ServerPluginRegistry-pool-2-thread-2" > [_thread_blocked, id=28938, stack(0x00007f53e1d51000,0x00007f53e1e19000)] > 0x00007f5360c01800 JavaThread "ServerPluginRegistry-pool-2-thread-1" > [_thread_blocked, id=28937, stack(0x00007f53e1e19000,0x00007f53e1ee1000)] > 0x00007f5360cd7000 JavaThread "kewCacheManager" daemon [_thread_blocked, > id=28935, stack(0x00007f53e1ee1000,0x00007f53e1fa9000)] > 0x00007f5360eff800 JavaThread "KSB-Scheduled-pool-1-thread-1" > [_thread_blocked, id=28934, stack(0x00007f53e1fa9000,0x00007f53e2071000)] > 0x00007f5361080000 JavaThread "kimCacheManager" daemon [_thread_blocked, > id=28933, stack(0x00007f53e2071000,0x00007f53e2139000)] > 0x00007f5360d5a800 JavaThread "coreServiceCacheManager" daemon > [_thread_blocked, id=28932, stack(0x00007f53e23d1000,0x00007f53e2499000)] > 0x00007f5360ec0000 JavaThread "Thread-4" daemon [_thread_blocked, > id=28931, stack(0x00007f53e2139000,0x00007f53e2201000)] > 0x00007f5384005800 JavaThread "ThreadService-0" daemon [_thread_blocked, > id=28930, stack(0x00007f53e2309000,0x00007f53e23d1000)] > 0x00007f5360b4c000 JavaThread "Timer-0" daemon [_thread_blocked, > id=28927, stack(0x00007f53e269f000,0x00007f53e2767000)] > 0x00007f53606bd000 JavaThread "rice.ksb.scheduler_QuartzSchedulerThread" > [_thread_blocked, id=28926, stack(0x00007f53e2767000,0x00007f53e282f000)] > 0x00007f5360a74000 JavaThread "rice.ksb.scheduler_Worker-10" > [_thread_blocked, id=28925, stack(0x00007f53e282f000,0x00007f53e28f7000)] > 0x00007f5360bc5800 JavaThread "rice.ksb.scheduler_Worker-9" > [_thread_blocked, id=28924, stack(0x00007f53e28f7000,0x00007f53e29bf000)] > 0x00007f5360ba3800 JavaThread "rice.ksb.scheduler_Worker-8" > [_thread_blocked, id=28923, stack(0x00007f53e29bf000,0x00007f53e2a87000)] > 0x00007f5360bb4800 JavaThread "rice.ksb.scheduler_Worker-7" > [_thread_blocked, id=28922, stack(0x00007f53e2a87000,0x00007f53e2b4f000)] > 0x00007f5360bbe000 JavaThread "rice.ksb.scheduler_Worker-6" > [_thread_blocked, id=28921, stack(0x00007f53e2b4f000,0x00007f53e2c17000)] > 0x00007f5360a0f800 JavaThread "rice.ksb.scheduler_Worker-5" > [_thread_blocked, id=28920, stack(0x00007f53e2c17000,0x00007f53e2cdf000)] > 0x00007f5360a98000 JavaThread "rice.ksb.scheduler_Worker-4" > [_thread_blocked, id=28919, stack(0x00007f53e2cdf000,0x00007f53e2da7000)] > 0x00007f5360c98000 JavaThread "rice.ksb.scheduler_Worker-3" > [_thread_blocked, id=28918, stack(0x00007f53e2da7000,0x00007f53e2e6f000)] > 0x00007f53606f1000 JavaThread "rice.ksb.scheduler_Worker-2" > [_thread_blocked, id=28917, stack(0x00007f53e2e6f000,0x00007f53e2f37000)] > 0x00007f5360c93000 JavaThread "rice.ksb.scheduler_Worker-1" > [_thread_blocked, id=28916, stack(0x00007f53e2f37000,0x00007f53e2fff000)] > 0x00007f5360afa000 JavaThread "JotmClock" daemon [_thread_blocked, > id=28915, stack(0x00007f53f807d000,0x00007f53f8145000)] > 0x00007f5360a78000 JavaThread "JotmBatch" daemon [_thread_blocked, > id=28914, stack(0x00007f53f8145000,0x00007f53f820d000)] > 0x00007f5360b4f800 JavaThread "RMI Reaper" [_thread_blocked, id=28913, > stack(0x00007f53f820d000,0x00007f53f82d5000)] > 0x00007f541c338000 JavaThread "GC Daemon" daemon [_thread_blocked, > id=28893, stack(0x00007f53f897c000,0x00007f53f8a44000)] > 0x00007f541c211800 JavaThread "RMI TCP Accept-0" daemon > [_thread_in_native, id=28891, stack(0x00007f53f8b45000,0x00007f53f8c0d000)] > 0x00007f541c20b800 JavaThread "RMI TCP Accept-8999" daemon > [_thread_in_native, id=28890, stack(0x00007f53f8c0d000,0x00007f53f8cd5000)] > 0x00007f541c204000 JavaThread "RMI TCP Accept-0" daemon > [_thread_in_native, id=28889, stack(0x00007f53f8cd5000,0x00007f53f8d9d000)] > 0x00007f541c1bc000 JavaThread "CommunicatorServer" daemon > [_thread_in_native, id=28888, stack(0x00007f53f8d9d000,0x00007f53f8e65000)] > 0x00007f541c135800 JavaThread "Low Memory Detector" daemon > [_thread_blocked, id=28887, stack(0x00007f53f9083000,0x00007f53f914b000)] > 0x00007f541c132800 JavaThread "C2 CompilerThread1" daemon > [_thread_blocked, id=28886, stack(0x00007f53f914b000,0x00007f53f924c000)] > 0x00007f541c130800 JavaThread "C2 CompilerThread0" daemon > [_thread_blocked, id=28885, stack(0x00007f53f924c000,0x00007f53f934d000)] > 0x00007f541c12e800 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=28884, stack(0x00007f53f934d000,0x00007f53f9415000)] > 0x00007f541c12c800 JavaThread "Surrogate Locker Thread (Concurrent GC)" > daemon [_thread_blocked, id=28883, > stack(0x00007f53f9415000,0x00007f53f94dd000)] > 0x00007f541c10f800 JavaThread "Finalizer" daemon [_thread_blocked, > id=28882, stack(0x00007f53f94dd000,0x00007f53f95a5000)] > 0x00007f541c10e000 JavaThread "Reference Handler" daemon > [_thread_blocked, id=28881, stack(0x00007f53f95a5000,0x00007f53f966d000)] > 0x00007f541c008800 JavaThread "main" [_thread_in_native, id=28862, > stack(0x00007f542025c000,0x00007f5420324000)] > > Other Threads: > 0x00007f541c107000 VMThread [stack: > 0x00007f53f966d000,0x00007f53f976e000] [id=28880] > 0x00007f541c214000 WatcherThread [stack: > 0x00007f53f8a44000,0x00007f53f8b45000] [id=28892] > > =>0x00007f541c0ab000 (exited) GCTaskThread [stack: > 0x0000000000000000,0x0000000000000000] [id=28867] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap > par new generation total 3947584K, used 2152986K [0x00000004c0000000, > 0x00000005c0000000, 0x00000005c0000000) > eden space 3700864K, 51% used [0x00000004c0000000, 0x0000000534596ac0, > 0x00000005a1e20000) > from space 246720K, 100% used [0x00000005a1e20000, 0x00000005b0f10000, > 0x00000005b0f10000) > to space 246720K, 0% used [0x00000005b0f10000, 0x00000005b0f10000, > 0x00000005c0000000) > concurrent mark-sweep generation total 8388608K, used 5088536K > [0x00000005c0000000, 0x00000007c0000000, 0x00000007c0000000) > concurrent-mark-sweep perm gen total 1048576K, used 108044K > [0x00000007c0000000, 0x0000000800000000, 0x0000000800000000) > > Code Cache [0x00007f540bcde000, 0x00007f541bcde000, 0x00007f541bcde000) > total_blobs=5085 nmethods=4325 adapters=711 free_code_cache=248021120 > largest_free_block=21760 > > Dynamic libraries: > 40000000-40009000 r-xp 00000000 fd:00 795119 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/bin/java > 40108000-4010b000 rwxp 00008000 fd:00 795119 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/bin/java > 405fb000-40661000 rwxp 00000000 00:00 0 > [heap] > 4c0000000-800000000 rwxp 00000000 00:00 0 > 32c5a00000-32c5a20000 r-xp 00000000 fd:00 656068 > /lib64/ld-2.12.so > 32c5c1f000-32c5c20000 r-xp 0001f000 fd:00 656068 > /lib64/ld-2.12.so > 32c5c20000-32c5c21000 rwxp 00020000 fd:00 656068 > /lib64/ld-2.12.so > 32c5c21000-32c5c22000 rwxp 00000000 00:00 0 > 32c5e00000-32c5e02000 r-xp 00000000 fd:00 656091 > /lib64/libdl-2.12.so > 32c5e02000-32c6002000 ---p 00002000 fd:00 656091 > /lib64/libdl-2.12.so > 32c6002000-32c6003000 r-xp 00002000 fd:00 656091 > /lib64/libdl-2.12.so > 32c6003000-32c6004000 rwxp 00003000 fd:00 656091 > /lib64/libdl-2.12.so > 32c6200000-32c6389000 r-xp 00000000 fd:00 656075 > /lib64/libc-2.12.so > 32c6389000-32c6588000 ---p 00189000 fd:00 656075 > /lib64/libc-2.12.so > 32c6588000-32c658c000 r-xp 00188000 fd:00 656075 > /lib64/libc-2.12.so > 32c658c000-32c658d000 rwxp 0018c000 fd:00 656075 > /lib64/libc-2.12.so > 32c658d000-32c6592000 rwxp 00000000 00:00 0 > 32c6600000-32c6617000 r-xp 00000000 fd:00 658369 > /lib64/libpthread-2.12.so > 32c6617000-32c6817000 ---p 00017000 fd:00 658369 > /lib64/libpthread-2.12.so > 32c6817000-32c6818000 r-xp 00017000 fd:00 658369 > /lib64/libpthread-2.12.so > 32c6818000-32c6819000 rwxp 00018000 fd:00 658369 > /lib64/libpthread-2.12.so > 32c6819000-32c681d000 rwxp 00000000 00:00 0 > 32c6a00000-32c6a83000 r-xp 00000000 fd:00 656864 > /lib64/libm-2.12.so > 32c6a83000-32c6c82000 ---p 00083000 fd:00 656864 > /lib64/libm-2.12.so > 32c6c82000-32c6c83000 r-xp 00082000 fd:00 656864 > /lib64/libm-2.12.so > 32c6c83000-32c6c84000 rwxp 00083000 fd:00 656864 > /lib64/libm-2.12.so > 32c6e00000-32c6e07000 r-xp 00000000 fd:00 656195 > /lib64/librt-2.12.so > 32c6e07000-32c7006000 ---p 00007000 fd:00 656195 > /lib64/librt-2.12.so > 32c7006000-32c7007000 r-xp 00006000 fd:00 656195 > /lib64/librt-2.12.so > 32c7007000-32c7008000 rwxp 00007000 fd:00 656195 > /lib64/librt-2.12.so > 32c8200000-32c8216000 r-xp 00000000 fd:00 659776 > /lib64/libresolv-2.12.so > 32c8216000-32c8416000 ---p 00016000 fd:00 659776 > /lib64/libresolv-2.12.so > 32c8416000-32c8417000 r-xp 00016000 fd:00 659776 > /lib64/libresolv-2.12.so > 32c8417000-32c8418000 rwxp 00017000 fd:00 659776 > /lib64/libresolv-2.12.so > 32c8418000-32c841a000 rwxp 00000000 00:00 0 > 32c9600000-32c9616000 r-xp 00000000 fd:00 658286 > /lib64/libnsl-2.12.so > 32c9616000-32c9815000 ---p 00016000 fd:00 658286 > /lib64/libnsl-2.12.so > 32c9815000-32c9816000 r-xp 00015000 fd:00 658286 > /lib64/libnsl-2.12.so > 32c9816000-32c9817000 rwxp 00016000 fd:00 658286 > /lib64/libnsl-2.12.so > 32c9817000-32c9819000 rwxp 00000000 00:00 0 > 3e6fc00000-3e6fc07000 r-xp 00000000 fd:00 922346 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so > 3e6fc07000-3e6fd08000 ---p 00007000 fd:00 922346 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so > 3e6fd08000-3e6fd0a000 rwxp 00008000 fd:00 922346 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so > 7f5328000000-7f532804e000 rwxp 00000000 00:00 0 > 7f532804e000-7f532c000000 ---p 00000000 00:00 0 > 7f5330000000-7f533004d000 rwxp 00000000 00:00 0 > 7f533004d000-7f5334000000 ---p 00000000 00:00 0 > 7f5334000000-7f533408c000 rwxp 00000000 00:00 0 > 7f533408c000-7f5338000000 ---p 00000000 00:00 0 > 7f5338000000-7f533805f000 rwxp 00000000 00:00 0 > 7f533805f000-7f533c000000 ---p 00000000 00:00 0 > 7f533c000000-7f533c021000 rwxp 00000000 00:00 0 > 7f533c021000-7f5340000000 ---p 00000000 00:00 0 > 7f5340000000-7f534006c000 rwxp 00000000 00:00 0 > 7f534006c000-7f5344000000 ---p 00000000 00:00 0 > 7f5344000000-7f5344021000 rwxp 00000000 00:00 0 > 7f5344021000-7f5348000000 ---p 00000000 00:00 0 > 7f5348000000-7f534806e000 rwxp 00000000 00:00 0 > 7f534806e000-7f534c000000 ---p 00000000 00:00 0 > 7f534c000000-7f534c065000 rwxp 00000000 00:00 0 > 7f534c065000-7f5350000000 ---p 00000000 00:00 0 > 7f5350000000-7f5350079000 rwxp 00000000 00:00 0 > 7f5350079000-7f5354000000 ---p 00000000 00:00 0 > 7f5354000000-7f5354021000 rwxp 00000000 00:00 0 > 7f5354021000-7f5358000000 ---p 00000000 00:00 0 > 7f5358000000-7f5358021000 rwxp 00000000 00:00 0 > 7f5358021000-7f535c000000 ---p 00000000 00:00 0 > 7f535c000000-7f535c021000 rwxp 00000000 00:00 0 > 7f535c021000-7f5360000000 ---p 00000000 00:00 0 > 7f5360000000-7f5361bd3000 rwxp 00000000 00:00 0 > 7f5361bd3000-7f5364000000 ---p 00000000 00:00 0 > 7f5364000000-7f5364a01000 rwxp 00000000 00:00 0 > 7f5364a01000-7f5368000000 ---p 00000000 00:00 0 > 7f5368000000-7f5368046000 rwxp 00000000 00:00 0 > 7f5368046000-7f536c000000 ---p 00000000 00:00 0 > 7f536c000000-7f536c1a5000 rwxp 00000000 00:00 0 > 7f536c1a5000-7f5370000000 ---p 00000000 00:00 0 > 7f5370000000-7f5370045000 rwxp 00000000 00:00 0 > 7f5370045000-7f5374000000 ---p 00000000 00:00 0 > 7f5374000000-7f5374044000 rwxp 00000000 00:00 0 > 7f5374044000-7f5378000000 ---p 00000000 00:00 0 > 7f5378000000-7f5378045000 rwxp 00000000 00:00 0 > 7f5378045000-7f537c000000 ---p 00000000 00:00 0 > 7f537c000000-7f537c062000 rwxp 00000000 00:00 0 > 7f537c062000-7f5380000000 ---p 00000000 00:00 0 > 7f5380000000-7f538004a000 rwxp 00000000 00:00 0 > 7f538004a000-7f5384000000 ---p 00000000 00:00 0 > 7f5384000000-7f5384095000 rwxp 00000000 00:00 0 > 7f5384095000-7f5388000000 ---p 00000000 00:00 0 > 7f5388000000-7f538bffa000 rwxp 00000000 00:00 0 > 7f538bffa000-7f538c000000 ---p 00000000 00:00 0 > 7f538c000000-7f538fffd000 rwxp 00000000 00:00 0 > 7f538fffd000-7f5390000000 ---p 00000000 00:00 0 > 7f5390000000-7f5390021000 rwxp 00000000 00:00 0 > 7f5390021000-7f5394000000 ---p 00000000 00:00 0 > 7f539503e000-7f5395041000 ---p 00000000 00:00 0 > 7f5395041000-7f5395106000 rwxp 00000000 00:00 0 > 7f5395106000-7f5395109000 ---p 00000000 00:00 0 > 7f5395109000-7f53951ce000 rwxp 00000000 00:00 0 > 7f53951ce000-7f53951d1000 ---p 00000000 00:00 0 > 7f53951d1000-7f5395296000 rwxp 00000000 00:00 0 > 7f5395296000-7f5395299000 ---p 00000000 00:00 0 > 7f5395299000-7f539535e000 rwxp 00000000 00:00 0 > 7f539535e000-7f5395361000 ---p 00000000 00:00 0 > 7f5395361000-7f5395426000 rwxp 00000000 00:00 0 > 7f5395426000-7f5395429000 ---p 00000000 00:00 0 > 7f5395429000-7f53954ee000 rwxp 00000000 00:00 0 > 7f53954ee000-7f53954f1000 ---p 00000000 00:00 0 > 7f53954f1000-7f53955b6000 rwxp 00000000 00:00 0 > 7f53955b6000-7f53955b9000 ---p 00000000 00:00 0 > 7f53955b9000-7f539567e000 rwxp 00000000 00:00 0 > 7f539567e000-7f5395681000 ---p 00000000 00:00 0 > 7f5395681000-7f5395746000 rwxp 00000000 00:00 0 > 7f5395746000-7f5395749000 ---p 00000000 00:00 0 > 7f5395749000-7f539580e000 rwxp 00000000 00:00 0 > 7f539580e000-7f5395811000 ---p 00000000 00:00 0 > 7f5395811000-7f53958d6000 rwxp 00000000 00:00 0 > 7f53958d6000-7f53958d9000 ---p 00000000 00:00 0 > 7f53958d9000-7f539599e000 rwxp 00000000 00:00 0 > 7f539599e000-7f53959a1000 ---p 00000000 00:00 0 > 7f53959a1000-7f5395a66000 rwxp 00000000 00:00 0 > 7f5395a66000-7f5395a69000 ---p 00000000 00:00 0 > 7f5395a69000-7f5395b2e000 rwxp 00000000 00:00 0 > 7f5395b2e000-7f5395b31000 ---p 00000000 00:00 0 > 7f5395b31000-7f5395bf6000 rwxp 00000000 00:00 0 > 7f5395bf6000-7f5395bf9000 ---p 00000000 00:00 0 > 7f5395bf9000-7f5395cbe000 rwxp 00000000 00:00 0 > 7f5395cbe000-7f5395cc1000 ---p 00000000 00:00 0 > 7f5395cc1000-7f5395d86000 rwxp 00000000 00:00 0 > 7f5395d86000-7f5395d89000 ---p 00000000 00:00 0 > 7f5395d89000-7f5395e4e000 rwxp 00000000 00:00 0 > 7f5395e4e000-7f5395e51000 ---p 00000000 00:00 0 > 7f5395e51000-7f5395f16000 rwxp 00000000 00:00 0 > 7f5395f18000-7f5395f1b000 ---p 00000000 00:00 0 > 7f5395f1b000-7f5395fe0000 rwxp 00000000 00:00 0 > 7f5395fe0000-7f5395fe3000 ---p 00000000 00:00 0 > 7f5395fe3000-7f53960a8000 rwxp 00000000 00:00 0 > 7f53960a8000-7f53960ab000 ---p 00000000 00:00 0 > 7f53960ab000-7f5396170000 rwxp 00000000 00:00 0 > 7f5396170000-7f539c000000 r-xp 00000000 fd:00 534941 > /usr/lib/locale/locale-archive > 7f539c000000-7f539c054000 rwxp 00000000 00:00 0 > 7f539c054000-7f53a0000000 ---p 00000000 00:00 0 > 7f53a0000000-7f53a008a000 rwxp 00000000 00:00 0 > 7f53a008a000-7f53a4000000 ---p 00000000 00:00 0 > 7f53a4000000-7f53a4222000 rwxp 00000000 00:00 0 > 7f53a4222000-7f53a8000000 ---p 00000000 00:00 0 > 7f53a8000000-7f53a8030000 rwxp 00000000 00:00 0 > 7f53a8030000-7f53ac000000 ---p 00000000 00:00 0 > 7f53ac000000-7f53ac021000 rwxp 00000000 00:00 0 > 7f53ac021000-7f53b0000000 ---p 00000000 00:00 0 > 7f53b0000000-7f53b01b8000 rwxp 00000000 00:00 0 > 7f53b01b8000-7f53b4000000 ---p 00000000 00:00 0 > 7f53b4000000-7f53b41ef000 rwxp 00000000 00:00 0 > 7f53b41ef000-7f53b8000000 ---p 00000000 00:00 0 > 7f53b8000000-7f53b8021000 rwxp 00000000 00:00 0 > 7f53b8021000-7f53bc000000 ---p 00000000 00:00 0 > 7f53bc000000-7f53bc185000 rwxp 00000000 00:00 0 > 7f53bc185000-7f53c0000000 ---p 00000000 00:00 0 > 7f53c0000000-7f53c017d000 rwxp 00000000 00:00 0 > 7f53c017d000-7f53c4000000 ---p 00000000 00:00 0 > 7f53c4000000-7f53c4021000 rwxp 00000000 00:00 0 > 7f53c4021000-7f53c8000000 ---p 00000000 00:00 0 > 7f53c8000000-7f53c81a7000 rwxp 00000000 00:00 0 > 7f53c81a7000-7f53cc000000 ---p 00000000 00:00 0 > 7f53cc000000-7f53cc021000 rwxp 00000000 00:00 0 > 7f53cc021000-7f53d0000000 ---p 00000000 00:00 0 > 7f53d0000000-7f53d005d000 rwxp 00000000 00:00 0 > 7f53d005d000-7f53d4000000 ---p 00000000 00:00 0 > 7f53d4000000-7f53d41a6000 rwxp 00000000 00:00 0 > 7f53d41a6000-7f53d8000000 ---p 00000000 00:00 0 > 7f53d8000000-7f53d81a8000 rwxp 00000000 00:00 0 > 7f53d81a8000-7f53dc000000 ---p 00000000 00:00 0 > 7f53dc000000-7f53dc2c7000 rwxp 00000000 00:00 0 > 7f53dc2c7000-7f53e0000000 ---p 00000000 00:00 0 > 7f53e0069000-7f53e006c000 ---p 00000000 00:00 0 > 7f53e006c000-7f53e0131000 rwxp 00000000 00:00 0 > 7f53e0131000-7f53e0134000 ---p 00000000 00:00 0 > 7f53e0134000-7f53e01f9000 rwxp 00000000 00:00 0 > 7f53e01f9000-7f53e01fc000 ---p 00000000 00:00 0 > 7f53e01fc000-7f53e02c1000 rwxp 00000000 00:00 0 > 7f53e02c1000-7f53e02c4000 ---p 00000000 00:00 0 > 7f53e02c4000-7f53e0389000 rwxp 00000000 00:00 0 > 7f53e0389000-7f53e038c000 ---p 00000000 00:00 0 > 7f53e038c000-7f53e0451000 rwxp 00000000 00:00 0 > 7f53e0451000-7f53e0454000 ---p 00000000 00:00 0 > 7f53e0454000-7f53e0519000 rwxp 00000000 00:00 0 > 7f53e0519000-7f53e051c000 ---p 00000000 00:00 0 > 7f53e051c000-7f53e05e1000 rwxp 00000000 00:00 0 > 7f53e05e1000-7f53e05e4000 ---p 00000000 00:00 0 > 7f53e05e4000-7f53e06a9000 rwxp 00000000 00:00 0 > 7f53e06a9000-7f53e06ac000 ---p 00000000 00:00 0 > 7f53e06ac000-7f53e0771000 rwxp 00000000 00:00 0 > 7f53e0771000-7f53e0774000 ---p 00000000 00:00 0 > 7f53e0774000-7f53e0839000 rwxp 00000000 00:00 0 > 7f53e0839000-7f53e083c000 ---p 00000000 00:00 0 > 7f53e083c000-7f53e0901000 rwxp 00000000 00:00 0 > 7f53e0901000-7f53e0904000 ---p 00000000 00:00 0 > 7f53e0904000-7f53e09c9000 rwxp 00000000 00:00 0 > 7f53e09c9000-7f53e09cc000 ---p 00000000 00:00 0 > 7f53e09cc000-7f53e0a91000 rwxp 00000000 00:00 0 > 7f53e0a91000-7f53e0a94000 ---p 00000000 00:00 0 > 7f53e0a94000-7f53e0b59000 rwxp 00000000 00:00 0 > 7f53e0b59000-7f53e0b5c000 ---p 00000000 00:00 0 > 7f53e0b5c000-7f53e0c21000 rwxp 00000000 00:00 0 > 7f53e0c21000-7f53e0c24000 ---p 00000000 00:00 0 > 7f53e0c24000-7f53e0ce9000 rwxp 00000000 00:00 0 > 7f53e0ce9000-7f53e0cec000 ---p 00000000 00:00 0 > 7f53e0cec000-7f53e0db1000 rwxp 00000000 00:00 0 > 7f53e0db1000-7f53e0db4000 ---p 00000000 00:00 0 > 7f53e0db4000-7f53e0e79000 rwxp 00000000 00:00 0 > 7f53e0e79000-7f53e0e7c000 ---p 00000000 00:00 0 > 7f53e0e7c000-7f53e0f41000 rwxp 00000000 00:00 0 > 7f53e0f41000-7f53e0f44000 ---p 00000000 00:00 0 > 7f53e0f44000-7f53e1009000 rwxp 00000000 00:00 0 > 7f53e1009000-7f53e100c000 ---p 00000000 00:00 0 > 7f53e100c000-7f53e10d1000 rwxp 00000000 00:00 0 > 7f53e10d1000-7f53e10d4000 ---p 00000000 00:00 0 > 7f53e10d4000-7f53e1199000 rwxp 00000000 00:00 0 > 7f53e1199000-7f53e119c000 ---p 00000000 00:00 0 > 7f53e119c000-7f53e1261000 rwxp 00000000 00:00 0 > 7f53e1261000-7f53e1264000 ---p 00000000 00:00 0 > 7f53e1264000-7f53e1329000 rwxp 00000000 00:00 0 > 7f53e1329000-7f53e132c000 ---p 00000000 00:00 0 > 7f53e132c000-7f53e13f1000 rwxp 00000000 00:00 0 > 7f53e13f1000-7f53e13f4000 ---p 00000000 00:00 0 > 7f53e13f4000-7f53e14b9000 rwxp 00000000 00:00 0 > 7f53e14b9000-7f53e14bc000 ---p 00000000 00:00 0 > 7f53e14bc000-7f53e1581000 rwxp 00000000 00:00 0 > 7f53e1581000-7f53e1584000 ---p 00000000 00:00 0 > 7f53e1584000-7f53e1649000 rwxp 00000000 00:00 0 > 7f53e1649000-7f53e164c000 ---p 00000000 00:00 0 > 7f53e164c000-7f53e1711000 rwxp 00000000 00:00 0 > 7f53e1711000-7f53e1714000 ---p 00000000 00:00 0 > 7f53e1714000-7f53e17d9000 rwxp 00000000 00:00 0 > 7f53e17d9000-7f53e17dc000 ---p 00000000 00:00 0 > 7f53e17dc000-7f53e18a1000 rwxp 00000000 00:00 0 > 7f53e18a1000-7f53e18a4000 ---p 00000000 00:00 0 > 7f53e18a4000-7f53e1969000 rwxp 00000000 00:00 0 > 7f53e1969000-7f53e196c000 ---p 00000000 00:00 0 > 7f53e196c000-7f53e1a31000 rwxp 00000000 00:00 0 > 7f53e1a31000-7f53e1a34000 ---p 00000000 00:00 0 > 7f53e1a34000-7f53e1af9000 rwxp 00000000 00:00 0 > 7f53e1af9000-7f53e1afc000 ---p 00000000 00:00 0 > 7f53e1afc000-7f53e1bc1000 rwxp 00000000 00:00 0 > 7f53e1bc1000-7f53e1bc4000 ---p 00000000 00:00 0 > 7f53e1bc4000-7f53e1c89000 rwxp 00000000 00:00 0 > 7f53e1c89000-7f53e1c8c000 ---p 00000000 00:00 0 > 7f53e1c8c000-7f53e1d51000 rwxp 00000000 00:00 0 > 7f53e1d51000-7f53e1d54000 ---p 00000000 00:00 0 > 7f53e1d54000-7f53e1e19000 rwxp 00000000 00:00 0 > 7f53e1e19000-7f53e1e1c000 ---p 00000000 00:00 0 > 7f53e1e1c000-7f53e1ee1000 rwxp 00000000 00:00 0 > 7f53e1ee1000-7f53e1ee4000 ---p 00000000 00:00 0 > 7f53e1ee4000-7f53e1fa9000 rwxp 00000000 00:00 0 > 7f53e1fa9000-7f53e1fac000 ---p 00000000 00:00 0 > 7f53e1fac000-7f53e2071000 rwxp 00000000 00:00 0 > 7f53e2071000-7f53e2074000 ---p 00000000 00:00 0 > 7f53e2074000-7f53e2139000 rwxp 00000000 00:00 0 > 7f53e2139000-7f53e213c000 ---p 00000000 00:00 0 > 7f53e213c000-7f53e2201000 rwxp 00000000 00:00 0 > 7f53e2201000-7f53e2208000 r-xp 00000000 fd:00 928246 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so > 7f53e2208000-7f53e2307000 ---p 00007000 fd:00 928246 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so > 7f53e2307000-7f53e2309000 rwxp 00006000 fd:00 928246 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so > 7f53e2309000-7f53e230c000 ---p 00000000 00:00 0 > 7f53e230c000-7f53e23d1000 rwxp 00000000 00:00 0 > 7f53e23d1000-7f53e23d4000 ---p 00000000 00:00 0 > 7f53e23d4000-7f53e2499000 rwxp 00000000 00:00 0 > 7f53e2499000-7f53e249e000 r-xp 00000000 fd:00 656088 > /lib64/libnss_dns-2.12.so > 7f53e249e000-7f53e269d000 ---p 00005000 fd:00 656088 > /lib64/libnss_dns-2.12.so > 7f53e269d000-7f53e269e000 r-xp 00004000 fd:00 656088 > /lib64/libnss_dns-2.12.so > 7f53e269e000-7f53e269f000 rwxp 00005000 fd:00 656088 > /lib64/libnss_dns-2.12.so > 7f53e269f000-7f53e26a2000 ---p 00000000 00:00 0 > 7f53e26a2000-7f53e2767000 rwxp 00000000 00:00 0 > 7f53e2767000-7f53e276a000 ---p 00000000 00:00 0 > 7f53e276a000-7f53e282f000 rwxp 00000000 00:00 0 > 7f53e282f000-7f53e2832000 ---p 00000000 00:00 0 > 7f53e2832000-7f53e28f7000 rwxp 00000000 00:00 0 > 7f53e28f7000-7f53e28fa000 ---p 00000000 00:00 0 > 7f53e28fa000-7f53e29bf000 rwxp 00000000 00:00 0 > 7f53e29bf000-7f53e29c2000 ---p 00000000 00:00 0 > 7f53e29c2000-7f53e2a87000 rwxp 00000000 00:00 0 > 7f53e2a87000-7f53e2a8a000 ---p 00000000 00:00 0 > 7f53e2a8a000-7f53e2b4f000 rwxp 00000000 00:00 0 > 7f53e2b4f000-7f53e2b52000 ---p 00000000 00:00 0 > 7f53e2b52000-7f53e2c17000 rwxp 00000000 00:00 0 > 7f53e2c17000-7f53e2c1a000 ---p 00000000 00:00 0 > 7f53e2c1a000-7f53e2cdf000 rwxp 00000000 00:00 0 > 7f53e2cdf000-7f53e2ce2000 ---p 00000000 00:00 0 > 7f53e2ce2000-7f53e2da7000 rwxp 00000000 00:00 0 > 7f53e2da7000-7f53e2daa000 ---p 00000000 00:00 0 > 7f53e2daa000-7f53e2e6f000 rwxp 00000000 00:00 0 > 7f53e2e6f000-7f53e2e72000 ---p 00000000 00:00 0 > 7f53e2e72000-7f53e2f37000 rwxp 00000000 00:00 0 > 7f53e2f37000-7f53e2f3a000 ---p 00000000 00:00 0 > 7f53e2f3a000-7f53f4000000 rwxp 00000000 00:00 0 > 7f53f4000000-7f53f4040000 rwxp 00000000 00:00 0 > 7f53f4040000-7f53f8000000 ---p 00000000 00:00 0 > 7f53f805f000-7f53f806e000 r-xs 00667000 fd:00 928264 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/charsets.jar > 7f53f806e000-7f53f807d000 r-xs 00667000 fd:00 928264 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/charsets.jar > 7f53f807d000-7f53f8080000 ---p 00000000 00:00 0 > 7f53f8080000-7f53f8145000 rwxp 00000000 00:00 0 > 7f53f8145000-7f53f8148000 ---p 00000000 00:00 0 > 7f53f8148000-7f53f820d000 rwxp 00000000 00:00 0 > 7f53f820d000-7f53f8210000 ---p 00000000 00:00 0 > 7f53f8210000-7f53f82d5000 rwxp 00000000 00:00 0 > 7f53f8339000-7f53f833c000 ---p 00000000 00:00 0 > 7f53f833c000-7f53f8401000 rwxp 00000000 00:00 0 > 7f53f8401000-7f53f8404000 ---p 00000000 00:00 0 > 7f53f8404000-7f53f84c9000 rwxp 00000000 00:00 0 > 7f53f84c9000-7f53f84cc000 ---p 00000000 00:00 0 > 7f53f84cc000-7f53f8591000 rwxp 00000000 00:00 0 > 7f53f8591000-7f53f8594000 ---p 00000000 00:00 0 > 7f53f8594000-7f53f8659000 rwxp 00000000 00:00 0 > 7f53f8659000-7f53f865c000 ---p 00000000 00:00 0 > 7f53f865c000-7f53f8721000 rwxp 00000000 00:00 0 > 7f53f8721000-7f53f8724000 ---p 00000000 00:00 0 > 7f53f8724000-7f53f87e9000 rwxp 00000000 00:00 0 > 7f53f87e9000-7f53f87ec000 ---p 00000000 00:00 0 > 7f53f87ec000-7f53f88b1000 rwxp 00000000 00:00 0 > 7f53f88b1000-7f53f88b4000 ---p 00000000 00:00 0 > 7f53f88b4000-7f53f8979000 rwxp 00000000 00:00 0 > 7f53f8979000-7f53f897c000 r-xs 00027000 fd:00 1447062 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/sunjce_provider.jar > 7f53f897c000-7f53f897f000 ---p 00000000 00:00 0 > 7f53f897f000-7f53f8a44000 rwxp 00000000 00:00 0 > 7f53f8a44000-7f53f8a45000 ---p 00000000 00:00 0 > 7f53f8a45000-7f53f8b45000 rwxp 00000000 00:00 0 > 7f53f8b45000-7f53f8b48000 ---p 00000000 00:00 0 > 7f53f8b48000-7f53f8c0d000 rwxp 00000000 00:00 0 > 7f53f8c0d000-7f53f8c10000 ---p 00000000 00:00 0 > 7f53f8c10000-7f53f8cd5000 rwxp 00000000 00:00 0 > 7f53f8cd5000-7f53f8cd8000 ---p 00000000 00:00 0 > 7f53f8cd8000-7f53f8d9d000 rwxp 00000000 00:00 0 > 7f53f8d9d000-7f53f8da0000 ---p 00000000 00:00 0 > 7f53f8da0000-7f53f8e65000 rwxp 00000000 00:00 0 > 7f53f8e65000-7f53f8e6b000 r-xp 00000000 fd:00 928241 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so > 7f53f8e6b000-7f53f8f6a000 ---p 00006000 fd:00 928241 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so > 7f53f8f6a000-7f53f8f6c000 rwxp 00005000 fd:00 928241 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so > 7f53f8f6c000-7f53f8f7f000 r-xp 00000000 fd:00 928245 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so > 7f53f8f7f000-7f53f9080000 ---p 00013000 fd:00 928245 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so > 7f53f9080000-7f53f9083000 rwxp 00014000 fd:00 928245 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so > 7f53f9083000-7f53f9086000 ---p 00000000 00:00 0 > 7f53f9086000-7f53f914b000 rwxp 00000000 00:00 0 > 7f53f914b000-7f53f914e000 ---p 00000000 00:00 0 > 7f53f914e000-7f53f924c000 rwxp 00000000 00:00 0 > 7f53f924c000-7f53f924f000 ---p 00000000 00:00 0 > 7f53f924f000-7f53f934d000 rwxp 00000000 00:00 0 > 7f53f934d000-7f53f9350000 ---p 00000000 00:00 0 > 7f53f9350000-7f53f9415000 rwxp 00000000 00:00 0 > 7f53f9415000-7f53f9418000 ---p 00000000 00:00 0 > 7f53f9418000-7f53f94dd000 rwxp 00000000 00:00 0 > 7f53f94dd000-7f53f94e0000 ---p 00000000 00:00 0 > 7f53f94e0000-7f53f95a5000 rwxp 00000000 00:00 0 > 7f53f95a5000-7f53f95a8000 ---p 00000000 00:00 0 > 7f53f95a8000-7f53f966d000 rwxp 00000000 00:00 0 > 7f53f966d000-7f53f966e000 ---p 00000000 00:00 0 > 7f53f966e000-7f53f97a2000 rwxp 00000000 00:00 0 > 7f53f97a2000-7f53f9939000 r-xs 0307a000 fd:00 928317 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/rt.jar > 7f53f9939000-7f53fa0e9000 rwxp 00000000 00:00 0 > 7f53fa0e9000-7f53fa0ea000 ---p 00000000 00:00 0 > 7f53fa0ea000-7f53fadf6000 rwxp 00000000 00:00 0 > 7f53fadf6000-7f53fadf7000 ---p 00000000 00:00 0 > 7f53fadf7000-7f53faef7000 rwxp 00000000 00:00 0 > 7f53faef7000-7f53faef8000 ---p 00000000 00:00 0 > 7f53faef8000-7f53faff8000 rwxp 00000000 00:00 0 > 7f53faff8000-7f53faff9000 ---p 00000000 00:00 0 > 7f53faff9000-7f53fb0f9000 rwxp 00000000 00:00 0 > 7f53fb0f9000-7f53fb0fa000 ---p 00000000 00:00 0 > 7f53fb0fa000-7f53fb1fa000 rwxp 00000000 00:00 0 > 7f53fb1fa000-7f53fb1fb000 ---p 00000000 00:00 0 > 7f53fb1fb000-7f53fb2fb000 rwxp 00000000 00:00 0 > 7f53fb2fb000-7f53fb2fc000 ---p 00000000 00:00 0 > 7f53fb2fc000-7f53fb3fc000 rwxp 00000000 00:00 0 > 7f53fb3fc000-7f53fb3fd000 ---p 00000000 00:00 0 > 7f53fb3fd000-7f53fb4fd000 rwxp 00000000 00:00 0 > 7f53fb4fd000-7f53fb4fe000 ---p 00000000 00:00 0 > 7f53fb4fe000-7f53fb5fe000 rwxp 00000000 00:00 0 > 7f53fb5fe000-7f53fb5ff000 ---p 00000000 00:00 0 > 7f53fb5ff000-7f53fb6ff000 rwxp 00000000 00:00 0 > 7f53fb6ff000-7f53fb700000 ---p 00000000 00:00 0 > 7f53fb700000-7f53fc000000 rwxp 00000000 00:00 0 > 7f53fc000000-7f53fc145000 rwxp 00000000 00:00 0 > 7f53fc145000-7f5400000000 ---p 00000000 00:00 0 > 7f5400000000-7f540016f000 rwxp 00000000 00:00 0 > 7f540016f000-7f5404000000 ---p 00000000 00:00 0 > 7f5404000000-7f540406a000 rwxp 00000000 00:00 0 > 7f540406a000-7f5408000000 ---p 00000000 00:00 0 > 7f5408000000-7f5408004000 r-xs 00035000 fd:00 1447063 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/sunpkcs11.jar > 7f5408004000-7f540800c000 r-xs 00115000 fd:00 928316 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/resources.jar > 7f540800c000-7f5408012000 r-xs 00095000 fd:00 928303 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/jsse.jar > 7f5408012000-7f540801f000 r-xs 000b5000 fd:00 2228415 > /opt/tomcat/lib/tomcat-coyote.jar > 7f540801f000-7f5408024000 r-xs 0003a000 fd:00 2228406 > /opt/tomcat/lib/catalina-tribes.jar > 7f5408024000-7f5408025000 r-xs 00005000 fd:00 2228421 > /opt/tomcat/lib/tomcat-util.jar > 7f5408025000-7f5408027000 r-xs 0000b000 fd:00 2228419 > /opt/tomcat/lib/tomcat-i18n-ja.jar > 7f5408027000-7f540802b000 r-xs 00036000 fd:00 2228416 > /opt/tomcat/lib/tomcat-dbcp.jar > 7f540802b000-7f540802c000 r-xs 00001000 fd:00 2228414 > /opt/tomcat/lib/tomcat-api.jar > 7f540802c000-7f540803c000 r-xs 0019c000 fd:00 2228408 > /opt/tomcat/lib/ecj-3.7.2.jar > 7f540803c000-7f540803f000 r-xs 0001c000 fd:00 2228420 > /opt/tomcat/lib/tomcat-jdbc.jar > 7f540803f000-7f5408042000 r-xs 00013000 fd:00 2228412 > /opt/tomcat/lib/jsp-api.jar > 7f5408042000-7f5408044000 r-xs 0000a000 fd:00 2228418 > /opt/tomcat/lib/tomcat-i18n-fr.jar > 7f5408044000-7f5408047000 r-xs 0001c000 fd:00 2228410 > /opt/tomcat/lib/jasper-el.jar > 7f5408047000-7f540804a000 r-xs 00029000 fd:00 2228413 > /opt/tomcat/lib/servlet-api.jar > 7f540804a000-7f540804c000 r-xs 0000c000 fd:00 2228404 > /opt/tomcat/lib/catalina-ant.jar > 7f540804c000-7f540805f000 r-xs 00169000 fd:00 2228407 > /opt/tomcat/lib/catalina.jar > 7f540805f000-7f5408090000 rwxp 00000000 00:00 0 > 7f5408090000-7f5408091000 ---p 00000000 00:00 0 > 7f5408091000-7f5408191000 rwxp 00000000 00:00 0 > 7f5408191000-7f5408192000 ---p 00000000 00:00 0 > 7f5408192000-7f540b4d9000 rwxp 00000000 00:00 0 > 7f540b4d9000-7f540b4da000 rwxp 00000000 00:00 0 > 7f540b4da000-7f540b4db000 ---p 00000000 00:00 0 > 7f540b4db000-7f540b5db000 rwxp 00000000 00:00 0 > 7f540b5db000-7f540b5dc000 ---p 00000000 00:00 0 > 7f540b5dc000-7f540b6dc000 rwxp 00000000 00:00 0 > 7f540b6dc000-7f540b6dd000 ---p 00000000 00:00 0 > 7f540b6dd000-7f540b7dd000 rwxp 00000000 00:00 0 > 7f540b7dd000-7f540b7de000 ---p 00000000 00:00 0 > 7f540b7de000-7f541bcde000 rwxp 00000000 00:00 0 > 7f541bcde000-7f541bcec000 r-xp 00000000 fd:00 928254 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so > 7f541bcec000-7f541bdee000 ---p 0000e000 fd:00 928254 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so > 7f541bdee000-7f541bdf1000 rwxp 00010000 fd:00 928254 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so > 7f541bdf1000-7f541bdf2000 rwxp 00000000 00:00 0 > 7f541bdf2000-7f541bdfe000 r-xp 00000000 fd:00 656090 > /lib64/libnss_files-2.12.so > 7f541bdfe000-7f541bffe000 ---p 0000c000 fd:00 656090 > /lib64/libnss_files-2.12.so > 7f541bffe000-7f541bfff000 r-xp 0000c000 fd:00 656090 > /lib64/libnss_files-2.12.so > 7f541bfff000-7f541c000000 rwxp 0000d000 fd:00 656090 > /lib64/libnss_files-2.12.so > 7f541c000000-7f541c470000 rwxp 00000000 00:00 0 > 7f541c470000-7f5420000000 ---p 00000000 00:00 0 > 7f5420002000-7f5420005000 r-xs 00013000 fd:00 928301 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/jce.jar > 7f5420005000-7f5420008000 r-xs 000cc000 fd:00 1447060 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/localedata.jar > 7f5420008000-7f5420009000 r-xs 00003000 fd:00 2228403 > /opt/tomcat/lib/annotations-api.jar > 7f5420009000-7f542000b000 r-xs 00011000 fd:00 2228417 > /opt/tomcat/lib/tomcat-i18n-es.jar > 7f542000b000-7f5420013000 r-xs 00089000 fd:00 2228411 > /opt/tomcat/lib/jasper.jar > 7f5420013000-7f5420015000 r-xs 0000a000 fd:00 2228409 > /opt/tomcat/lib/el-api.jar > 7f5420015000-7f5420018000 r-xs 0001e000 fd:00 2228405 > /opt/tomcat/lib/catalina-ha.jar > 7f5420018000-7f5420019000 rwxp 00000000 00:00 0 > 7f5420019000-7f542001b000 r-xs 00008000 fd:00 2228399 > /opt/tomcat/bin/tomcat-juli.jar > 7f542001b000-7f542001c000 r-xs 00005000 fd:00 2228392 > /opt/tomcat/bin/commons-daemon.jar > 7f542001c000-7f542001e000 r-xs 00006000 fd:00 2228388 > /opt/tomcat/bin/bootstrap.jar > 7f542001e000-7f5420047000 r-xp 00000000 fd:00 928233 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so > 7f5420047000-7f5420146000 ---p 00029000 fd:00 928233 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so > 7f5420146000-7f542014d000 rwxp 00028000 fd:00 928233 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so > 7f542014d000-7f542015a000 r-xp 00000000 fd:00 928253 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so > 7f542015a000-7f5420259000 ---p 0000d000 fd:00 928253 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so > 7f5420259000-7f542025c000 rwxp 0000c000 fd:00 928253 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so > 7f542025c000-7f542025f000 ---p 00000000 00:00 0 > 7f542025f000-7f5420324000 rwxp 00000000 00:00 0 > 7f5420324000-7f5420c3f000 r-xp 00000000 fd:00 928262 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > 7f5420c3f000-7f5420d40000 ---p 0091b000 fd:00 928262 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > 7f5420d40000-7f5420ef5000 rwxp 0091c000 fd:00 928262 > /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > 7f5420ef5000-7f5420f33000 rwxp 00000000 00:00 0 > 7f5420f33000-7f5420f3b000 rwxs 00000000 fd:00 795098 > /tmp/hsperfdata_ramire79/28861 > 7f5420f3b000-7f5420f3c000 rwxp 00000000 00:00 0 > 7f5420f3c000-7f5420f3d000 r-xp 00000000 00:00 0 > 7f5420f3d000-7f5420f3f000 rwxp 00000000 00:00 0 > 7fff4984d000-7fff49863000 rwxp 00000000 00:00 0 > [stack] > 7fff499cf000-7fff499d0000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > > VM Arguments: > jvm_args: > -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Xms12g > -Xmx12g -Xss800k -XX:OldSize=8g -XX:NewSize=4g -XX:MaxNewSize=4g > -XX:NewRatio=3 -XX:PermSize=1024m -XX:MaxPermSize=1024m > -XX:InitialCodeCacheSize=256m -XX:ReservedCodeCacheSize=256m > -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=15 > -XX:StackShadowPages=10 -XX:+UseCompressedOops -XX:+DisableExplicitGC > -XX:+UseTLAB -XX:+UseParNewGC -XX:+UseConcMarkSweepGC > -XX:ParallelCMSThreads=12 -XX:+ParallelRefProcEnabled > -XX:CMSMarkStackSize=16M -XX:CMSMarkStackSizeMax=16M > -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled > -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled > -XX:+CMSPermGenSweepingEnabled -XX:PrintCMSStatistics=2 -XX:+PrintVMOptions > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCTaskTimeStamps > -XX:+PrintCommandLineFlags -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCDateStamps > -Xloggc:/opt/tomcat/logs/gc.log > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Dcom.sun.management.snmp.interface=0.0.0.0 > -Dcom.sun.management.snmp.port=8161 -Dcom.sun.management.snmp.acl=false > -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.authenticate=false > -Djava.rmi.server.hostname=qa1.kuali.utoronto.ca-Djava.endorsed.dirs=/opt/tomcat/endorsed -Dcatalina.base=/opt/tomcat > -Dcatalina.home=/opt/tomcat -Djava.io.tmpdir=/opt/tomcat/temp > java_command: org.apache.catalina.startup.Bootstrap start > Launcher Type: SUN_STANDARD > > Environment Variables: > > PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ramire79/bin > > LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/../lib/amd64 > SHELL=/bin/bash > > Signal Handlers: > SIGSEGV: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGBUS: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGFPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGPIPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGXFSZ: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGILL: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGUSR2: [libjvm.so+0x711de0], sa_mask[0]=0x00000000, sa_flags=0x10000004 > SIGHUP: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGTERM: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGQUIT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > > > --------------- S Y S T E M --------------- > > OS:Red Hat Enterprise Linux Server release 6.3 (Santiago) > > uname:Linux 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 > x86_64 > libc:glibc 2.12 NPTL 2.12 > rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 4096, AS infinity > load average:6.24 3.43 1.80 > > /proc/meminfo: > MemTotal: 16334044 kB > MemFree: 5305268 kB > Buffers: 136684 kB > Cached: 502616 kB > SwapCached: 0 kB > Active: 10435928 kB > Inactive: 205704 kB > Active(anon): 10002492 kB > Inactive(anon): 16 kB > Active(file): 433436 kB > Inactive(file): 205688 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 6160376 kB > SwapFree: 6160376 kB > Dirty: 208 kB > Writeback: 0 kB > AnonPages: 10002112 kB > Mapped: 30296 kB > Shmem: 184 kB > Slab: 162636 kB > SReclaimable: 126780 kB > SUnreclaim: 35856 kB > KernelStack: 2840 kB > PageTables: 25960 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 14327396 kB > Committed_AS: 14826588 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 304312 kB > VmallocChunk: 34359428600 kB > HardwareCorrupted: 0 kB > AnonHugePages: 9627648 kB > HugePages_Total: 0 > HugePages_Free: 0 > HugePages_Rsvd: 0 > HugePages_Surp: 0 > Hugepagesize: 2048 kB > DirectMap4k: 10240 kB > DirectMap2M: 16766976 kB > > > CPU:total 6 (1 cores per cpu, 1 threads per core) family 16 model 8 > stepping 0, cmov, cx8, fxsr, mmx, sse, sse2, sse3, popcnt, mmxext, > 3dnowpref, lzcnt, sse4a > > /proc/cpuinfo: > processor: 0 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext > 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni > cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 1 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext > 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni > cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 2 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext > 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni > cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 3 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext > 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni > cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 4 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext > 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni > cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 5 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext > 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni > cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > > > Memory: 4k page, physical 16334044k(5305268k free), swap 6160376k(6160376k > free) > > vm_info: Java HotSpot(TM) 64-Bit Server VM (20.8-b03) for linux-amd64 JRE > (1.6.0_33-b03), built on May 9 2012 09:57:57 by "java_re" with gcc 3.2.2 > (SuSE Linux) > > time: Tue Oct 2 17:06:26 2012 > elapsed time: 1663 seconds > > [root at course-search-as-qa bin]# > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Oct 3 15:22:48 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 03 Oct 2012 08:22:48 -0700 Subject: JVM fatal error in Par_ConcMarkingClosure::trim_queue In-Reply-To: <1D532B6B8971C641B23B36BF463156BA37D5AE0A@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> References: <1D532B6B8971C641B23B36BF463156BA37D5AE0A@arborexmbx1.UTORARBOR.UTORAD.Utoronto.ca> Message-ID: <506C5848.2060909@oracle.com> There was this bug 6967162 - CMS: 6u18 on Solaris/sparc: crash at void ParScanThreadState::trim_queues which was closed as not reproducible. I recall a fix in this area of code that had to do with how parts of arrays where taken and returned to the work stealing queues but have not been able to find it. Jon On 10/2/2012 5:41 PM, John Calvin wrote: > Has anyone seen the bug below before? > > John Calvin > Manager, Data Centres > Enterprise Infrastructure Solutions, > Information + Technology Services > University of Toronto > (416) 978-6878 > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f54206e9127, pid=28861, tid=139998890891008 > # > # JRE version: 6.0_33-b03 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode linux-amd64 compressed oops) > # Problematic frame: > # V [libjvm.so+0x3c5127] Par_ConcMarkingClosure::trim_queue(unsigned long)+0x77 > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007f541c0ab000): GCTaskThread [stack: 0x0000000000000000,0x0000000000000000] [id=28867] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000000039003b8 > > Registers: > RAX=0x0000000000000001, RBX=0x00007f5408290c10, RCX=0x0000000000000003, RDX=0x00000000039003a8 > RSP=0x00007f5408290bb0, RBP=0x00007f5408290be0, RSI=0x00000006a33e40b0, RDI=0x00007f5420dc61e0 > R8 =0x0000000000000001, R9 =0x0000000000000001, R10=0x00000006a33e40b0, R11=0x00007f53fa7f0010 > R12=0x0000000000000000, R13=0x0000000000000000, R14=0x0000000000000001, R15=0x0000000000000005 > RIP=0x00007f54206e9127, EFLAGS=0x0000000000010202, CSGSFS=0x0000000000000033, ERR=0x0000000000000004 > TRAPNO=0x000000000000000e > > Top of Stack: (sp=0x00007f5408290bb0) > 0x00007f5408290bb0: 00007f53fa1e8958 00000006a33e40b0 > 0x00007f5408290bc0: 00007f5408290c10 00007f541c0aa8f8 > 0x00007f5408290bd0: 00007f541c0c10b0 00007f53fa1e8860 > 0x00007f5408290be0: 00007f5408290ca0 00007f54206e933a > 0x00007f5408290bf0: 00007f53fa1e8970 00007f53fa1e8940 > 0x00007f5408290c00: 00007f541c0c0d64 00000006a3a64d68 > 0x00007f5408290c10: 00007f5420da2570 00007fff499cf800 > 0x00007f5408290c20: 00007f541c1045e0 00007f541c0aa5a0 > 0x00007f5408290c30: 00007f541c0aaa08 00007fff499cf801 > 0x00007f5408290c40: 00007f53fa1e8860 00000005c0000000 > 0x00007f5408290c50: 0000000048000000 00007f541c0aa7b8 > 0x00007f5408290c60: 00007f541c0aa8f8 00007f541c0c10b0 > 0x00007f5408290c70: 00000000506b5751 00007f5420daa148 > 0x00007f5408290c80: 00007f53fa1e8860 00007f5408290d00 > 0x00007f5408290c90: 0000000000000005 00007f5408290cb0 > 0x00007f5408290ca0: 00007f5408290d50 00007f54206e88ef > 0x00007f5408290cb0: 00007f541c0ab000 00007f541c0abde0 > 0x00007f5408290cc0: 00007f541c0abe10 00007f541c0abe20 > 0x00007f5408290cd0: 00007f541c0ac1f8 00007f541c0ac200 > 0x00007f5408290ce0: 00007f541c0ab9c0 00007f541c0ab9f0 > 0x00007f5408290cf0: 00007f541c0aba00 00007f541c0abdd8 > 0x00007f5408290d00: 0000000000000000 000000006313f392 > 0x00007f5408290d10: 00007f541c0ab001 0000000000000005 > 0x00007f5408290d20: 00007f541c0ab000 0000000000000005 > 0x00007f5408290d30: 00007f541c0ab000 00007f541c0aaf10 > 0x00007f5408290d40: 00007f5408290d70 0000000000000007 > 0x00007f5408290d50: 00007f5408290dc0 00007f5420b9d05c > 0x00007f5408290d60: 00007f541c0aaf10 00007f5420a2fa01 > 0x00007f5408290d70: 00007f541c0ab000 00007f53fa1e8860 > 0x00007f5408290d80: 00007f5400000002 00007f541c0ab000 > 0x00007f5408290d90: 00007f541c0aaf10 00007f5420a2c705 > 0x00007f5408290da0: 00007f541c0ab000 00007f541c0acb70 > > Instructions: (pc=0x00007f54206e9127) > 0x00007f54206e9107: 45 67 80 00 48 8b 75 d8 80 3a 00 74 5e 48 8b 3d > 0x00007f54206e9117: 0d 4b 80 00 8b 56 08 8b 4f 08 48 d3 e2 48 03 17 > 0x00007f54206e9127: 48 8b 42 10 48 8d 7a 10 48 89 da ff 90 98 01 00 > 0x00007f54206e9137: 00 48 8b 0d 51 39 80 00 31 d2 48 8b 7b 30 8b 01 > > Register to memory mapping: > > RAX=0x0000000000000001 is an unknown value > RBX=0x00007f5408290c10 is an unknown value > RCX=0x0000000000000003 is an unknown value > RDX=0x00000000039003a8 is an unknown value > RSP=0x00007f5408290bb0 is an unknown value > RBP=0x00007f5408290be0 is an unknown value > RSI=0x00000006a33e40b0 is an oop > [C > - klass: {type array char} > - length: 215 > RDI=0x00007f5420dc61e0: in /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so at 0x00007f5420324000 > R8 =0x0000000000000001 is an unknown value > R9 =0x0000000000000001 is an unknown value > R10=0x00000006a33e40b0 is an oop > [C > - klass: {type array char} > - length: 215 > R11=0x00007f53fa7f0010 is an unknown value > R12=0x0000000000000000 is an unknown value > R13=0x0000000000000000 is an unknown value > R14=0x0000000000000001 is an unknown value > R15=0x0000000000000005 is an unknown value > > > Stack: [0x0000000000000000,0x0000000000000000], sp=0x00007f5408290bb0, free space=136717666882k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x3c5127] Par_ConcMarkingClosure::trim_queue(unsigned long)+0x77 > V [libjvm.so+0x3c533a] CMSConcMarkingTask::do_work_steal(int)+0xfa > V [libjvm.so+0x3c48ef] CMSConcMarkingTask::work(int)+0xef > V [libjvm.so+0x87905c] YieldingFlexibleGangWorker::loop()+0xbc > V [libjvm.so+0x876234] GangWorker::run()+0x24 > V [libjvm.so+0x7117af] java_start(Thread*)+0x13f > > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00007f53dc012000 JavaThread "Thread-6442" daemon [_thread_in_Java, id=5169, stack(0x00007f5395b2e000,0x00007f5395bf6000)] > 0x00007f5380007000 JavaThread "Thread-6441" daemon [_thread_blocked, id=5168, stack(0x00007f539503e000,0x00007f5395106000)] > 0x00007f5328005800 JavaThread "Thread-6440" daemon [_thread_blocked, id=5167, stack(0x00007f539599e000,0x00007f5395a66000)] > 0x00007f53d8002000 JavaThread "Thread-6439" daemon [_thread_in_Java, id=5166, stack(0x00007f5395bf6000,0x00007f5395cbe000)] > 0x00007f5340001800 JavaThread "Thread-6438" daemon [_thread_blocked, id=5165, stack(0x00007f53f8401000,0x00007f53f84c9000)] > 0x00007f540009e800 JavaThread "Thread-6436" daemon [_thread_blocked, id=5163, stack(0x00007f5395a66000,0x00007f5395b2e000)] > 0x00007f53a802e800 JavaThread "http-bio-8080-exec-34" daemon [_thread_blocked, id=4007, stack(0x00007f5395296000,0x00007f539535e000)] > 0x00007f53a802d000 JavaThread "http-bio-8080-exec-33" daemon [_thread_in_native, id=4006, stack(0x00007f539535e000,0x00007f5395426000)] > 0x00007f53a802b800 JavaThread "http-bio-8080-exec-32" daemon [_thread_blocked, id=4004, stack(0x00007f5395426000,0x00007f53954ee000)] > 0x00007f53a802a800 JavaThread "http-bio-8080-exec-31" daemon [_thread_blocked, id=4003, stack(0x00007f53954ee000,0x00007f53955b6000)] > 0x00007f53a802a000 JavaThread "http-bio-8080-exec-30" daemon [_thread_blocked, id=4002, stack(0x00007f53f8591000,0x00007f53f8659000)] > 0x00007f53a8029000 JavaThread "http-bio-8080-exec-29" daemon [_thread_blocked, id=3998, stack(0x00007f53f8339000,0x00007f53f8401000)] > 0x00007f53a8027000 JavaThread "http-bio-8080-exec-28" daemon [_thread_blocked, id=3988, stack(0x00007f53955b6000,0x00007f539567e000)] > 0x00007f53a8025000 JavaThread "http-bio-8080-exec-27" daemon [_thread_blocked, id=3987, stack(0x00007f539567e000,0x00007f5395746000)] > 0x00007f53a8023000 JavaThread "http-bio-8080-exec-26" daemon [_thread_blocked, id=3986, stack(0x00007f5395746000,0x00007f539580e000)] > 0x00007f53a8021000 JavaThread "http-bio-8080-exec-25" daemon [_thread_blocked, id=3985, stack(0x00007f539580e000,0x00007f53958d6000)] > 0x00007f53a8020000 JavaThread "http-bio-8080-exec-24" daemon [_thread_blocked, id=3981, stack(0x00007f5395f18000,0x00007f5395fe0000)] > 0x00007f53a801f000 JavaThread "http-bio-8080-exec-23" daemon [_thread_in_Java, id=3980, stack(0x00007f53e1199000,0x00007f53e1261000)] > 0x00007f5384007800 JavaThread "ThreadService-1" daemon [_thread_blocked, id=3574, stack(0x00007f5395e4e000,0x00007f5395f16000)] > 0x00007f53a801d800 JavaThread "http-bio-8080-exec-22" daemon [_thread_blocked, id=3232, stack(0x00007f5395fe0000,0x00007f53960a8000)] > 0x00007f53a801c000 JavaThread "http-bio-8080-exec-21" daemon [_thread_blocked, id=3230, stack(0x00007f53960a8000,0x00007f5396170000)] > 0x00007f53a801a000 JavaThread "http-bio-8080-exec-20" daemon [_thread_in_native, id=3229, stack(0x00007f53e0069000,0x00007f53e0131000)] > 0x00007f53a8019000 JavaThread "http-bio-8080-exec-19" daemon [_thread_blocked, id=3227, stack(0x00007f53e0131000,0x00007f53e01f9000)] > 0x00007f53a8017800 JavaThread "http-bio-8080-exec-18" daemon [_thread_blocked, id=3225, stack(0x00007f53f84c9000,0x00007f53f8591000)] > 0x00007f53a8016800 JavaThread "http-bio-8080-exec-17" daemon [_thread_blocked, id=3220, stack(0x00007f53e1009000,0x00007f53e10d1000)] > 0x00007f53a8015800 JavaThread "http-bio-8080-exec-16" daemon [_thread_blocked, id=3219, stack(0x00007f5395cbe000,0x00007f5395d86000)] > 0x00007f53a8014800 JavaThread "http-bio-8080-exec-15" daemon [_thread_blocked, id=1686, stack(0x00007f53e01f9000,0x00007f53e02c1000)] > 0x00007f53a8013800 JavaThread "http-bio-8080-exec-14" daemon [_thread_in_Java, id=1685, stack(0x00007f53e0f41000,0x00007f53e1009000)] > 0x00007f53a8012800 JavaThread "http-bio-8080-exec-13" daemon [_thread_blocked, id=1244, stack(0x00007f53f8659000,0x00007f53f8721000)] > 0x00007f53a8011800 JavaThread "http-bio-8080-exec-12" daemon [_thread_blocked, id=1243, stack(0x00007f53f8721000,0x00007f53f87e9000)] > 0x00007f53a8010800 JavaThread "http-bio-8080-exec-11" daemon [_thread_blocked, id=764, stack(0x00007f53e06a9000,0x00007f53e0771000)] > 0x00007f53a800f800 JavaThread "http-bio-8080-exec-10" daemon [_thread_blocked, id=29120, stack(0x00007f53e0a91000,0x00007f53e0b59000)] > 0x00007f53a800e800 JavaThread "http-bio-8080-exec-9" daemon [_thread_blocked, id=29118, stack(0x00007f53e0901000,0x00007f53e09c9000)] > 0x00007f53a800d800 JavaThread "http-bio-8080-exec-8" daemon [_thread_in_vm, id=29116, stack(0x00007f53e09c9000,0x00007f53e0a91000)] > 0x00007f53a800c800 JavaThread "http-bio-8080-exec-7" daemon [_thread_blocked, id=29114, stack(0x00007f53e0839000,0x00007f53e0901000)] > 0x00007f53a800b800 JavaThread "http-bio-8080-exec-6" daemon [_thread_blocked, id=29112, stack(0x00007f53e0519000,0x00007f53e05e1000)] > 0x00007f53a800a800 JavaThread "http-bio-8080-exec-5" daemon [_thread_in_Java, id=29110, stack(0x00007f53e0389000,0x00007f53e0451000)] > 0x00007f53a8009800 JavaThread "http-bio-8080-exec-4" daemon [_thread_in_Java, id=29093, stack(0x00007f53e0ce9000,0x00007f53e0db1000)] > 0x00007f53a8008800 JavaThread "http-bio-8080-exec-3" daemon [_thread_blocked, id=29091, stack(0x00007f53e0451000,0x00007f53e0519000)] > 0x00007f53a8007800 JavaThread "http-bio-8080-exec-2" daemon [_thread_blocked, id=29089, stack(0x00007f53f87e9000,0x00007f53f88b1000)] > 0x00007f53a8007000 JavaThread "http-bio-8080-exec-1" daemon [_thread_blocked, id=29028, stack(0x00007f53f88b1000,0x00007f53f8979000)] > 0x00007f541c0f8800 JavaThread "ajp-bio-8009-AsyncTimeout" daemon [_thread_blocked, id=28995, stack(0x00007f53e0771000,0x00007f53e0839000)] > 0x00007f541c0f7000 JavaThread "ajp-bio-8009-Acceptor-0" daemon [_thread_in_native, id=28994, stack(0x00007f53e02c1000,0x00007f53e0389000)] > 0x00007f541c0f5800 JavaThread "http-bio-8080-AsyncTimeout" daemon [_thread_blocked, id=28993, stack(0x00007f53e0c21000,0x00007f53e0ce9000)] > 0x00007f541c0f4800 JavaThread "http-bio-8080-Acceptor-0" daemon [_thread_in_native, id=28992, stack(0x00007f53e0e79000,0x00007f53e0f41000)] > 0x00007f541c40a000 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=28991, stack(0x00007f53e0b59000,0x00007f53e0c21000)] > 0x00007f5360e07000 JavaThread "kuali-course-search/KSB-pool-1-thread-1" [_thread_blocked, id=28990, stack(0x00007f53e05e1000,0x00007f53e06a9000)] > 0x00007f5360b7f800 JavaThread "KSB-Scheduled-pool-1-thread-2" [_thread_blocked, id=28989, stack(0x00007f53e0db1000,0x00007f53e0e79000)] > 0x00007f5360c5e800 JavaThread "locationCacheManager" daemon [_thread_blocked, id=28954, stack(0x00007f53e10d1000,0x00007f53e1199000)] > 0x00007f5361344800 JavaThread "krmsCacheManager" daemon [_thread_blocked, id=28952, stack(0x00007f53e1261000,0x00007f53e1329000)] > 0x00007f536106b800 JavaThread "Timer-1" daemon [_thread_blocked, id=28951, stack(0x00007f53e1329000,0x00007f53e13f1000)] > 0x00007f5360da0800 JavaThread "notificationScheduler_QuartzSchedulerThread" [_thread_blocked, id=28950, stack(0x00007f53e13f1000,0x00007f53e14b9000)] > 0x00007f53613b2800 JavaThread "notificationScheduler_Worker-10" [_thread_blocked, id=28949, stack(0x00007f53e14b9000,0x00007f53e1581000)] > 0x00007f5360ee7000 JavaThread "notificationScheduler_Worker-9" [_thread_blocked, id=28948, stack(0x00007f53e1581000,0x00007f53e1649000)] > 0x00007f5360f6b800 JavaThread "notificationScheduler_Worker-8" [_thread_blocked, id=28947, stack(0x00007f53e1649000,0x00007f53e1711000)] > 0x00007f5360e44800 JavaThread "notificationScheduler_Worker-7" [_thread_blocked, id=28946, stack(0x00007f53e1711000,0x00007f53e17d9000)] > 0x00007f5361310800 JavaThread "notificationScheduler_Worker-6" [_thread_blocked, id=28945, stack(0x00007f53e17d9000,0x00007f53e18a1000)] > 0x00007f536134a800 JavaThread "notificationScheduler_Worker-5" [_thread_blocked, id=28944, stack(0x00007f53e18a1000,0x00007f53e1969000)] > 0x00007f5361094000 JavaThread "notificationScheduler_Worker-4" [_thread_blocked, id=28943, stack(0x00007f53e1969000,0x00007f53e1a31000)] > 0x00007f5360cf9800 JavaThread "notificationScheduler_Worker-3" [_thread_blocked, id=28942, stack(0x00007f53e1a31000,0x00007f53e1af9000)] > 0x00007f5360aec800 JavaThread "notificationScheduler_Worker-2" [_thread_blocked, id=28941, stack(0x00007f53e1af9000,0x00007f53e1bc1000)] > 0x00007f5361008800 JavaThread "notificationScheduler_Worker-1" [_thread_blocked, id=28940, stack(0x00007f53e1bc1000,0x00007f53e1c89000)] > 0x00007f5361064800 JavaThread "pool-3-thread-1" [_thread_blocked, id=28939, stack(0x00007f53e1c89000,0x00007f53e1d51000)] > 0x00007f5361089000 JavaThread "ServerPluginRegistry-pool-2-thread-2" [_thread_blocked, id=28938, stack(0x00007f53e1d51000,0x00007f53e1e19000)] > 0x00007f5360c01800 JavaThread "ServerPluginRegistry-pool-2-thread-1" [_thread_blocked, id=28937, stack(0x00007f53e1e19000,0x00007f53e1ee1000)] > 0x00007f5360cd7000 JavaThread "kewCacheManager" daemon [_thread_blocked, id=28935, stack(0x00007f53e1ee1000,0x00007f53e1fa9000)] > 0x00007f5360eff800 JavaThread "KSB-Scheduled-pool-1-thread-1" [_thread_blocked, id=28934, stack(0x00007f53e1fa9000,0x00007f53e2071000)] > 0x00007f5361080000 JavaThread "kimCacheManager" daemon [_thread_blocked, id=28933, stack(0x00007f53e2071000,0x00007f53e2139000)] > 0x00007f5360d5a800 JavaThread "coreServiceCacheManager" daemon [_thread_blocked, id=28932, stack(0x00007f53e23d1000,0x00007f53e2499000)] > 0x00007f5360ec0000 JavaThread "Thread-4" daemon [_thread_blocked, id=28931, stack(0x00007f53e2139000,0x00007f53e2201000)] > 0x00007f5384005800 JavaThread "ThreadService-0" daemon [_thread_blocked, id=28930, stack(0x00007f53e2309000,0x00007f53e23d1000)] > 0x00007f5360b4c000 JavaThread "Timer-0" daemon [_thread_blocked, id=28927, stack(0x00007f53e269f000,0x00007f53e2767000)] > 0x00007f53606bd000 JavaThread "rice.ksb.scheduler_QuartzSchedulerThread" [_thread_blocked, id=28926, stack(0x00007f53e2767000,0x00007f53e282f000)] > 0x00007f5360a74000 JavaThread "rice.ksb.scheduler_Worker-10" [_thread_blocked, id=28925, stack(0x00007f53e282f000,0x00007f53e28f7000)] > 0x00007f5360bc5800 JavaThread "rice.ksb.scheduler_Worker-9" [_thread_blocked, id=28924, stack(0x00007f53e28f7000,0x00007f53e29bf000)] > 0x00007f5360ba3800 JavaThread "rice.ksb.scheduler_Worker-8" [_thread_blocked, id=28923, stack(0x00007f53e29bf000,0x00007f53e2a87000)] > 0x00007f5360bb4800 JavaThread "rice.ksb.scheduler_Worker-7" [_thread_blocked, id=28922, stack(0x00007f53e2a87000,0x00007f53e2b4f000)] > 0x00007f5360bbe000 JavaThread "rice.ksb.scheduler_Worker-6" [_thread_blocked, id=28921, stack(0x00007f53e2b4f000,0x00007f53e2c17000)] > 0x00007f5360a0f800 JavaThread "rice.ksb.scheduler_Worker-5" [_thread_blocked, id=28920, stack(0x00007f53e2c17000,0x00007f53e2cdf000)] > 0x00007f5360a98000 JavaThread "rice.ksb.scheduler_Worker-4" [_thread_blocked, id=28919, stack(0x00007f53e2cdf000,0x00007f53e2da7000)] > 0x00007f5360c98000 JavaThread "rice.ksb.scheduler_Worker-3" [_thread_blocked, id=28918, stack(0x00007f53e2da7000,0x00007f53e2e6f000)] > 0x00007f53606f1000 JavaThread "rice.ksb.scheduler_Worker-2" [_thread_blocked, id=28917, stack(0x00007f53e2e6f000,0x00007f53e2f37000)] > 0x00007f5360c93000 JavaThread "rice.ksb.scheduler_Worker-1" [_thread_blocked, id=28916, stack(0x00007f53e2f37000,0x00007f53e2fff000)] > 0x00007f5360afa000 JavaThread "JotmClock" daemon [_thread_blocked, id=28915, stack(0x00007f53f807d000,0x00007f53f8145000)] > 0x00007f5360a78000 JavaThread "JotmBatch" daemon [_thread_blocked, id=28914, stack(0x00007f53f8145000,0x00007f53f820d000)] > 0x00007f5360b4f800 JavaThread "RMI Reaper" [_thread_blocked, id=28913, stack(0x00007f53f820d000,0x00007f53f82d5000)] > 0x00007f541c338000 JavaThread "GC Daemon" daemon [_thread_blocked, id=28893, stack(0x00007f53f897c000,0x00007f53f8a44000)] > 0x00007f541c211800 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=28891, stack(0x00007f53f8b45000,0x00007f53f8c0d000)] > 0x00007f541c20b800 JavaThread "RMI TCP Accept-8999" daemon [_thread_in_native, id=28890, stack(0x00007f53f8c0d000,0x00007f53f8cd5000)] > 0x00007f541c204000 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=28889, stack(0x00007f53f8cd5000,0x00007f53f8d9d000)] > 0x00007f541c1bc000 JavaThread "CommunicatorServer" daemon [_thread_in_native, id=28888, stack(0x00007f53f8d9d000,0x00007f53f8e65000)] > 0x00007f541c135800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=28887, stack(0x00007f53f9083000,0x00007f53f914b000)] > 0x00007f541c132800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=28886, stack(0x00007f53f914b000,0x00007f53f924c000)] > 0x00007f541c130800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=28885, stack(0x00007f53f924c000,0x00007f53f934d000)] > 0x00007f541c12e800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=28884, stack(0x00007f53f934d000,0x00007f53f9415000)] > 0x00007f541c12c800 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=28883, stack(0x00007f53f9415000,0x00007f53f94dd000)] > 0x00007f541c10f800 JavaThread "Finalizer" daemon [_thread_blocked, id=28882, stack(0x00007f53f94dd000,0x00007f53f95a5000)] > 0x00007f541c10e000 JavaThread "Reference Handler" daemon [_thread_blocked, id=28881, stack(0x00007f53f95a5000,0x00007f53f966d000)] > 0x00007f541c008800 JavaThread "main" [_thread_in_native, id=28862, stack(0x00007f542025c000,0x00007f5420324000)] > > Other Threads: > 0x00007f541c107000 VMThread [stack: 0x00007f53f966d000,0x00007f53f976e000] [id=28880] > 0x00007f541c214000 WatcherThread [stack: 0x00007f53f8a44000,0x00007f53f8b45000] [id=28892] > > =>0x00007f541c0ab000 (exited) GCTaskThread [stack: 0x0000000000000000,0x0000000000000000] [id=28867] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap > par new generation total 3947584K, used 2152986K [0x00000004c0000000, 0x00000005c0000000, 0x00000005c0000000) > eden space 3700864K, 51% used [0x00000004c0000000, 0x0000000534596ac0, 0x00000005a1e20000) > from space 246720K, 100% used [0x00000005a1e20000, 0x00000005b0f10000, 0x00000005b0f10000) > to space 246720K, 0% used [0x00000005b0f10000, 0x00000005b0f10000, 0x00000005c0000000) > concurrent mark-sweep generation total 8388608K, used 5088536K [0x00000005c0000000, 0x00000007c0000000, 0x00000007c0000000) > concurrent-mark-sweep perm gen total 1048576K, used 108044K [0x00000007c0000000, 0x0000000800000000, 0x0000000800000000) > > Code Cache [0x00007f540bcde000, 0x00007f541bcde000, 0x00007f541bcde000) > total_blobs=5085 nmethods=4325 adapters=711 free_code_cache=248021120 largest_free_block=21760 > > Dynamic libraries: > 40000000-40009000 r-xp 00000000 fd:00 795119 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/bin/java > 40108000-4010b000 rwxp 00008000 fd:00 795119 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/bin/java > 405fb000-40661000 rwxp 00000000 00:00 0 [heap] > 4c0000000-800000000 rwxp 00000000 00:00 0 > 32c5a00000-32c5a20000 r-xp 00000000 fd:00 656068 /lib64/ld-2.12.so > 32c5c1f000-32c5c20000 r-xp 0001f000 fd:00 656068 /lib64/ld-2.12.so > 32c5c20000-32c5c21000 rwxp 00020000 fd:00 656068 /lib64/ld-2.12.so > 32c5c21000-32c5c22000 rwxp 00000000 00:00 0 > 32c5e00000-32c5e02000 r-xp 00000000 fd:00 656091 /lib64/libdl-2.12.so > 32c5e02000-32c6002000 ---p 00002000 fd:00 656091 /lib64/libdl-2.12.so > 32c6002000-32c6003000 r-xp 00002000 fd:00 656091 /lib64/libdl-2.12.so > 32c6003000-32c6004000 rwxp 00003000 fd:00 656091 /lib64/libdl-2.12.so > 32c6200000-32c6389000 r-xp 00000000 fd:00 656075 /lib64/libc-2.12.so > 32c6389000-32c6588000 ---p 00189000 fd:00 656075 /lib64/libc-2.12.so > 32c6588000-32c658c000 r-xp 00188000 fd:00 656075 /lib64/libc-2.12.so > 32c658c000-32c658d000 rwxp 0018c000 fd:00 656075 /lib64/libc-2.12.so > 32c658d000-32c6592000 rwxp 00000000 00:00 0 > 32c6600000-32c6617000 r-xp 00000000 fd:00 658369 /lib64/libpthread-2.12.so > 32c6617000-32c6817000 ---p 00017000 fd:00 658369 /lib64/libpthread-2.12.so > 32c6817000-32c6818000 r-xp 00017000 fd:00 658369 /lib64/libpthread-2.12.so > 32c6818000-32c6819000 rwxp 00018000 fd:00 658369 /lib64/libpthread-2.12.so > 32c6819000-32c681d000 rwxp 00000000 00:00 0 > 32c6a00000-32c6a83000 r-xp 00000000 fd:00 656864 /lib64/libm-2.12.so > 32c6a83000-32c6c82000 ---p 00083000 fd:00 656864 /lib64/libm-2.12.so > 32c6c82000-32c6c83000 r-xp 00082000 fd:00 656864 /lib64/libm-2.12.so > 32c6c83000-32c6c84000 rwxp 00083000 fd:00 656864 /lib64/libm-2.12.so > 32c6e00000-32c6e07000 r-xp 00000000 fd:00 656195 /lib64/librt-2.12.so > 32c6e07000-32c7006000 ---p 00007000 fd:00 656195 /lib64/librt-2.12.so > 32c7006000-32c7007000 r-xp 00006000 fd:00 656195 /lib64/librt-2.12.so > 32c7007000-32c7008000 rwxp 00007000 fd:00 656195 /lib64/librt-2.12.so > 32c8200000-32c8216000 r-xp 00000000 fd:00 659776 /lib64/libresolv-2.12.so > 32c8216000-32c8416000 ---p 00016000 fd:00 659776 /lib64/libresolv-2.12.so > 32c8416000-32c8417000 r-xp 00016000 fd:00 659776 /lib64/libresolv-2.12.so > 32c8417000-32c8418000 rwxp 00017000 fd:00 659776 /lib64/libresolv-2.12.so > 32c8418000-32c841a000 rwxp 00000000 00:00 0 > 32c9600000-32c9616000 r-xp 00000000 fd:00 658286 /lib64/libnsl-2.12.so > 32c9616000-32c9815000 ---p 00016000 fd:00 658286 /lib64/libnsl-2.12.so > 32c9815000-32c9816000 r-xp 00015000 fd:00 658286 /lib64/libnsl-2.12.so > 32c9816000-32c9817000 rwxp 00016000 fd:00 658286 /lib64/libnsl-2.12.so > 32c9817000-32c9819000 rwxp 00000000 00:00 0 > 3e6fc00000-3e6fc07000 r-xp 00000000 fd:00 922346 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so > 3e6fc07000-3e6fd08000 ---p 00007000 fd:00 922346 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so > 3e6fd08000-3e6fd0a000 rwxp 00008000 fd:00 922346 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/jli/libjli.so > 7f5328000000-7f532804e000 rwxp 00000000 00:00 0 > 7f532804e000-7f532c000000 ---p 00000000 00:00 0 > 7f5330000000-7f533004d000 rwxp 00000000 00:00 0 > 7f533004d000-7f5334000000 ---p 00000000 00:00 0 > 7f5334000000-7f533408c000 rwxp 00000000 00:00 0 > 7f533408c000-7f5338000000 ---p 00000000 00:00 0 > 7f5338000000-7f533805f000 rwxp 00000000 00:00 0 > 7f533805f000-7f533c000000 ---p 00000000 00:00 0 > 7f533c000000-7f533c021000 rwxp 00000000 00:00 0 > 7f533c021000-7f5340000000 ---p 00000000 00:00 0 > 7f5340000000-7f534006c000 rwxp 00000000 00:00 0 > 7f534006c000-7f5344000000 ---p 00000000 00:00 0 > 7f5344000000-7f5344021000 rwxp 00000000 00:00 0 > 7f5344021000-7f5348000000 ---p 00000000 00:00 0 > 7f5348000000-7f534806e000 rwxp 00000000 00:00 0 > 7f534806e000-7f534c000000 ---p 00000000 00:00 0 > 7f534c000000-7f534c065000 rwxp 00000000 00:00 0 > 7f534c065000-7f5350000000 ---p 00000000 00:00 0 > 7f5350000000-7f5350079000 rwxp 00000000 00:00 0 > 7f5350079000-7f5354000000 ---p 00000000 00:00 0 > 7f5354000000-7f5354021000 rwxp 00000000 00:00 0 > 7f5354021000-7f5358000000 ---p 00000000 00:00 0 > 7f5358000000-7f5358021000 rwxp 00000000 00:00 0 > 7f5358021000-7f535c000000 ---p 00000000 00:00 0 > 7f535c000000-7f535c021000 rwxp 00000000 00:00 0 > 7f535c021000-7f5360000000 ---p 00000000 00:00 0 > 7f5360000000-7f5361bd3000 rwxp 00000000 00:00 0 > 7f5361bd3000-7f5364000000 ---p 00000000 00:00 0 > 7f5364000000-7f5364a01000 rwxp 00000000 00:00 0 > 7f5364a01000-7f5368000000 ---p 00000000 00:00 0 > 7f5368000000-7f5368046000 rwxp 00000000 00:00 0 > 7f5368046000-7f536c000000 ---p 00000000 00:00 0 > 7f536c000000-7f536c1a5000 rwxp 00000000 00:00 0 > 7f536c1a5000-7f5370000000 ---p 00000000 00:00 0 > 7f5370000000-7f5370045000 rwxp 00000000 00:00 0 > 7f5370045000-7f5374000000 ---p 00000000 00:00 0 > 7f5374000000-7f5374044000 rwxp 00000000 00:00 0 > 7f5374044000-7f5378000000 ---p 00000000 00:00 0 > 7f5378000000-7f5378045000 rwxp 00000000 00:00 0 > 7f5378045000-7f537c000000 ---p 00000000 00:00 0 > 7f537c000000-7f537c062000 rwxp 00000000 00:00 0 > 7f537c062000-7f5380000000 ---p 00000000 00:00 0 > 7f5380000000-7f538004a000 rwxp 00000000 00:00 0 > 7f538004a000-7f5384000000 ---p 00000000 00:00 0 > 7f5384000000-7f5384095000 rwxp 00000000 00:00 0 > 7f5384095000-7f5388000000 ---p 00000000 00:00 0 > 7f5388000000-7f538bffa000 rwxp 00000000 00:00 0 > 7f538bffa000-7f538c000000 ---p 00000000 00:00 0 > 7f538c000000-7f538fffd000 rwxp 00000000 00:00 0 > 7f538fffd000-7f5390000000 ---p 00000000 00:00 0 > 7f5390000000-7f5390021000 rwxp 00000000 00:00 0 > 7f5390021000-7f5394000000 ---p 00000000 00:00 0 > 7f539503e000-7f5395041000 ---p 00000000 00:00 0 > 7f5395041000-7f5395106000 rwxp 00000000 00:00 0 > 7f5395106000-7f5395109000 ---p 00000000 00:00 0 > 7f5395109000-7f53951ce000 rwxp 00000000 00:00 0 > 7f53951ce000-7f53951d1000 ---p 00000000 00:00 0 > 7f53951d1000-7f5395296000 rwxp 00000000 00:00 0 > 7f5395296000-7f5395299000 ---p 00000000 00:00 0 > 7f5395299000-7f539535e000 rwxp 00000000 00:00 0 > 7f539535e000-7f5395361000 ---p 00000000 00:00 0 > 7f5395361000-7f5395426000 rwxp 00000000 00:00 0 > 7f5395426000-7f5395429000 ---p 00000000 00:00 0 > 7f5395429000-7f53954ee000 rwxp 00000000 00:00 0 > 7f53954ee000-7f53954f1000 ---p 00000000 00:00 0 > 7f53954f1000-7f53955b6000 rwxp 00000000 00:00 0 > 7f53955b6000-7f53955b9000 ---p 00000000 00:00 0 > 7f53955b9000-7f539567e000 rwxp 00000000 00:00 0 > 7f539567e000-7f5395681000 ---p 00000000 00:00 0 > 7f5395681000-7f5395746000 rwxp 00000000 00:00 0 > 7f5395746000-7f5395749000 ---p 00000000 00:00 0 > 7f5395749000-7f539580e000 rwxp 00000000 00:00 0 > 7f539580e000-7f5395811000 ---p 00000000 00:00 0 > 7f5395811000-7f53958d6000 rwxp 00000000 00:00 0 > 7f53958d6000-7f53958d9000 ---p 00000000 00:00 0 > 7f53958d9000-7f539599e000 rwxp 00000000 00:00 0 > 7f539599e000-7f53959a1000 ---p 00000000 00:00 0 > 7f53959a1000-7f5395a66000 rwxp 00000000 00:00 0 > 7f5395a66000-7f5395a69000 ---p 00000000 00:00 0 > 7f5395a69000-7f5395b2e000 rwxp 00000000 00:00 0 > 7f5395b2e000-7f5395b31000 ---p 00000000 00:00 0 > 7f5395b31000-7f5395bf6000 rwxp 00000000 00:00 0 > 7f5395bf6000-7f5395bf9000 ---p 00000000 00:00 0 > 7f5395bf9000-7f5395cbe000 rwxp 00000000 00:00 0 > 7f5395cbe000-7f5395cc1000 ---p 00000000 00:00 0 > 7f5395cc1000-7f5395d86000 rwxp 00000000 00:00 0 > 7f5395d86000-7f5395d89000 ---p 00000000 00:00 0 > 7f5395d89000-7f5395e4e000 rwxp 00000000 00:00 0 > 7f5395e4e000-7f5395e51000 ---p 00000000 00:00 0 > 7f5395e51000-7f5395f16000 rwxp 00000000 00:00 0 > 7f5395f18000-7f5395f1b000 ---p 00000000 00:00 0 > 7f5395f1b000-7f5395fe0000 rwxp 00000000 00:00 0 > 7f5395fe0000-7f5395fe3000 ---p 00000000 00:00 0 > 7f5395fe3000-7f53960a8000 rwxp 00000000 00:00 0 > 7f53960a8000-7f53960ab000 ---p 00000000 00:00 0 > 7f53960ab000-7f5396170000 rwxp 00000000 00:00 0 > 7f5396170000-7f539c000000 r-xp 00000000 fd:00 534941 /usr/lib/locale/locale-archive > 7f539c000000-7f539c054000 rwxp 00000000 00:00 0 > 7f539c054000-7f53a0000000 ---p 00000000 00:00 0 > 7f53a0000000-7f53a008a000 rwxp 00000000 00:00 0 > 7f53a008a000-7f53a4000000 ---p 00000000 00:00 0 > 7f53a4000000-7f53a4222000 rwxp 00000000 00:00 0 > 7f53a4222000-7f53a8000000 ---p 00000000 00:00 0 > 7f53a8000000-7f53a8030000 rwxp 00000000 00:00 0 > 7f53a8030000-7f53ac000000 ---p 00000000 00:00 0 > 7f53ac000000-7f53ac021000 rwxp 00000000 00:00 0 > 7f53ac021000-7f53b0000000 ---p 00000000 00:00 0 > 7f53b0000000-7f53b01b8000 rwxp 00000000 00:00 0 > 7f53b01b8000-7f53b4000000 ---p 00000000 00:00 0 > 7f53b4000000-7f53b41ef000 rwxp 00000000 00:00 0 > 7f53b41ef000-7f53b8000000 ---p 00000000 00:00 0 > 7f53b8000000-7f53b8021000 rwxp 00000000 00:00 0 > 7f53b8021000-7f53bc000000 ---p 00000000 00:00 0 > 7f53bc000000-7f53bc185000 rwxp 00000000 00:00 0 > 7f53bc185000-7f53c0000000 ---p 00000000 00:00 0 > 7f53c0000000-7f53c017d000 rwxp 00000000 00:00 0 > 7f53c017d000-7f53c4000000 ---p 00000000 00:00 0 > 7f53c4000000-7f53c4021000 rwxp 00000000 00:00 0 > 7f53c4021000-7f53c8000000 ---p 00000000 00:00 0 > 7f53c8000000-7f53c81a7000 rwxp 00000000 00:00 0 > 7f53c81a7000-7f53cc000000 ---p 00000000 00:00 0 > 7f53cc000000-7f53cc021000 rwxp 00000000 00:00 0 > 7f53cc021000-7f53d0000000 ---p 00000000 00:00 0 > 7f53d0000000-7f53d005d000 rwxp 00000000 00:00 0 > 7f53d005d000-7f53d4000000 ---p 00000000 00:00 0 > 7f53d4000000-7f53d41a6000 rwxp 00000000 00:00 0 > 7f53d41a6000-7f53d8000000 ---p 00000000 00:00 0 > 7f53d8000000-7f53d81a8000 rwxp 00000000 00:00 0 > 7f53d81a8000-7f53dc000000 ---p 00000000 00:00 0 > 7f53dc000000-7f53dc2c7000 rwxp 00000000 00:00 0 > 7f53dc2c7000-7f53e0000000 ---p 00000000 00:00 0 > 7f53e0069000-7f53e006c000 ---p 00000000 00:00 0 > 7f53e006c000-7f53e0131000 rwxp 00000000 00:00 0 > 7f53e0131000-7f53e0134000 ---p 00000000 00:00 0 > 7f53e0134000-7f53e01f9000 rwxp 00000000 00:00 0 > 7f53e01f9000-7f53e01fc000 ---p 00000000 00:00 0 > 7f53e01fc000-7f53e02c1000 rwxp 00000000 00:00 0 > 7f53e02c1000-7f53e02c4000 ---p 00000000 00:00 0 > 7f53e02c4000-7f53e0389000 rwxp 00000000 00:00 0 > 7f53e0389000-7f53e038c000 ---p 00000000 00:00 0 > 7f53e038c000-7f53e0451000 rwxp 00000000 00:00 0 > 7f53e0451000-7f53e0454000 ---p 00000000 00:00 0 > 7f53e0454000-7f53e0519000 rwxp 00000000 00:00 0 > 7f53e0519000-7f53e051c000 ---p 00000000 00:00 0 > 7f53e051c000-7f53e05e1000 rwxp 00000000 00:00 0 > 7f53e05e1000-7f53e05e4000 ---p 00000000 00:00 0 > 7f53e05e4000-7f53e06a9000 rwxp 00000000 00:00 0 > 7f53e06a9000-7f53e06ac000 ---p 00000000 00:00 0 > 7f53e06ac000-7f53e0771000 rwxp 00000000 00:00 0 > 7f53e0771000-7f53e0774000 ---p 00000000 00:00 0 > 7f53e0774000-7f53e0839000 rwxp 00000000 00:00 0 > 7f53e0839000-7f53e083c000 ---p 00000000 00:00 0 > 7f53e083c000-7f53e0901000 rwxp 00000000 00:00 0 > 7f53e0901000-7f53e0904000 ---p 00000000 00:00 0 > 7f53e0904000-7f53e09c9000 rwxp 00000000 00:00 0 > 7f53e09c9000-7f53e09cc000 ---p 00000000 00:00 0 > 7f53e09cc000-7f53e0a91000 rwxp 00000000 00:00 0 > 7f53e0a91000-7f53e0a94000 ---p 00000000 00:00 0 > 7f53e0a94000-7f53e0b59000 rwxp 00000000 00:00 0 > 7f53e0b59000-7f53e0b5c000 ---p 00000000 00:00 0 > 7f53e0b5c000-7f53e0c21000 rwxp 00000000 00:00 0 > 7f53e0c21000-7f53e0c24000 ---p 00000000 00:00 0 > 7f53e0c24000-7f53e0ce9000 rwxp 00000000 00:00 0 > 7f53e0ce9000-7f53e0cec000 ---p 00000000 00:00 0 > 7f53e0cec000-7f53e0db1000 rwxp 00000000 00:00 0 > 7f53e0db1000-7f53e0db4000 ---p 00000000 00:00 0 > 7f53e0db4000-7f53e0e79000 rwxp 00000000 00:00 0 > 7f53e0e79000-7f53e0e7c000 ---p 00000000 00:00 0 > 7f53e0e7c000-7f53e0f41000 rwxp 00000000 00:00 0 > 7f53e0f41000-7f53e0f44000 ---p 00000000 00:00 0 > 7f53e0f44000-7f53e1009000 rwxp 00000000 00:00 0 > 7f53e1009000-7f53e100c000 ---p 00000000 00:00 0 > 7f53e100c000-7f53e10d1000 rwxp 00000000 00:00 0 > 7f53e10d1000-7f53e10d4000 ---p 00000000 00:00 0 > 7f53e10d4000-7f53e1199000 rwxp 00000000 00:00 0 > 7f53e1199000-7f53e119c000 ---p 00000000 00:00 0 > 7f53e119c000-7f53e1261000 rwxp 00000000 00:00 0 > 7f53e1261000-7f53e1264000 ---p 00000000 00:00 0 > 7f53e1264000-7f53e1329000 rwxp 00000000 00:00 0 > 7f53e1329000-7f53e132c000 ---p 00000000 00:00 0 > 7f53e132c000-7f53e13f1000 rwxp 00000000 00:00 0 > 7f53e13f1000-7f53e13f4000 ---p 00000000 00:00 0 > 7f53e13f4000-7f53e14b9000 rwxp 00000000 00:00 0 > 7f53e14b9000-7f53e14bc000 ---p 00000000 00:00 0 > 7f53e14bc000-7f53e1581000 rwxp 00000000 00:00 0 > 7f53e1581000-7f53e1584000 ---p 00000000 00:00 0 > 7f53e1584000-7f53e1649000 rwxp 00000000 00:00 0 > 7f53e1649000-7f53e164c000 ---p 00000000 00:00 0 > 7f53e164c000-7f53e1711000 rwxp 00000000 00:00 0 > 7f53e1711000-7f53e1714000 ---p 00000000 00:00 0 > 7f53e1714000-7f53e17d9000 rwxp 00000000 00:00 0 > 7f53e17d9000-7f53e17dc000 ---p 00000000 00:00 0 > 7f53e17dc000-7f53e18a1000 rwxp 00000000 00:00 0 > 7f53e18a1000-7f53e18a4000 ---p 00000000 00:00 0 > 7f53e18a4000-7f53e1969000 rwxp 00000000 00:00 0 > 7f53e1969000-7f53e196c000 ---p 00000000 00:00 0 > 7f53e196c000-7f53e1a31000 rwxp 00000000 00:00 0 > 7f53e1a31000-7f53e1a34000 ---p 00000000 00:00 0 > 7f53e1a34000-7f53e1af9000 rwxp 00000000 00:00 0 > 7f53e1af9000-7f53e1afc000 ---p 00000000 00:00 0 > 7f53e1afc000-7f53e1bc1000 rwxp 00000000 00:00 0 > 7f53e1bc1000-7f53e1bc4000 ---p 00000000 00:00 0 > 7f53e1bc4000-7f53e1c89000 rwxp 00000000 00:00 0 > 7f53e1c89000-7f53e1c8c000 ---p 00000000 00:00 0 > 7f53e1c8c000-7f53e1d51000 rwxp 00000000 00:00 0 > 7f53e1d51000-7f53e1d54000 ---p 00000000 00:00 0 > 7f53e1d54000-7f53e1e19000 rwxp 00000000 00:00 0 > 7f53e1e19000-7f53e1e1c000 ---p 00000000 00:00 0 > 7f53e1e1c000-7f53e1ee1000 rwxp 00000000 00:00 0 > 7f53e1ee1000-7f53e1ee4000 ---p 00000000 00:00 0 > 7f53e1ee4000-7f53e1fa9000 rwxp 00000000 00:00 0 > 7f53e1fa9000-7f53e1fac000 ---p 00000000 00:00 0 > 7f53e1fac000-7f53e2071000 rwxp 00000000 00:00 0 > 7f53e2071000-7f53e2074000 ---p 00000000 00:00 0 > 7f53e2074000-7f53e2139000 rwxp 00000000 00:00 0 > 7f53e2139000-7f53e213c000 ---p 00000000 00:00 0 > 7f53e213c000-7f53e2201000 rwxp 00000000 00:00 0 > 7f53e2201000-7f53e2208000 r-xp 00000000 fd:00 928246 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so > 7f53e2208000-7f53e2307000 ---p 00007000 fd:00 928246 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so > 7f53e2307000-7f53e2309000 rwxp 00006000 fd:00 928246 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnio.so > 7f53e2309000-7f53e230c000 ---p 00000000 00:00 0 > 7f53e230c000-7f53e23d1000 rwxp 00000000 00:00 0 > 7f53e23d1000-7f53e23d4000 ---p 00000000 00:00 0 > 7f53e23d4000-7f53e2499000 rwxp 00000000 00:00 0 > 7f53e2499000-7f53e249e000 r-xp 00000000 fd:00 656088 /lib64/libnss_dns-2.12.so > 7f53e249e000-7f53e269d000 ---p 00005000 fd:00 656088 /lib64/libnss_dns-2.12.so > 7f53e269d000-7f53e269e000 r-xp 00004000 fd:00 656088 /lib64/libnss_dns-2.12.so > 7f53e269e000-7f53e269f000 rwxp 00005000 fd:00 656088 /lib64/libnss_dns-2.12.so > 7f53e269f000-7f53e26a2000 ---p 00000000 00:00 0 > 7f53e26a2000-7f53e2767000 rwxp 00000000 00:00 0 > 7f53e2767000-7f53e276a000 ---p 00000000 00:00 0 > 7f53e276a000-7f53e282f000 rwxp 00000000 00:00 0 > 7f53e282f000-7f53e2832000 ---p 00000000 00:00 0 > 7f53e2832000-7f53e28f7000 rwxp 00000000 00:00 0 > 7f53e28f7000-7f53e28fa000 ---p 00000000 00:00 0 > 7f53e28fa000-7f53e29bf000 rwxp 00000000 00:00 0 > 7f53e29bf000-7f53e29c2000 ---p 00000000 00:00 0 > 7f53e29c2000-7f53e2a87000 rwxp 00000000 00:00 0 > 7f53e2a87000-7f53e2a8a000 ---p 00000000 00:00 0 > 7f53e2a8a000-7f53e2b4f000 rwxp 00000000 00:00 0 > 7f53e2b4f000-7f53e2b52000 ---p 00000000 00:00 0 > 7f53e2b52000-7f53e2c17000 rwxp 00000000 00:00 0 > 7f53e2c17000-7f53e2c1a000 ---p 00000000 00:00 0 > 7f53e2c1a000-7f53e2cdf000 rwxp 00000000 00:00 0 > 7f53e2cdf000-7f53e2ce2000 ---p 00000000 00:00 0 > 7f53e2ce2000-7f53e2da7000 rwxp 00000000 00:00 0 > 7f53e2da7000-7f53e2daa000 ---p 00000000 00:00 0 > 7f53e2daa000-7f53e2e6f000 rwxp 00000000 00:00 0 > 7f53e2e6f000-7f53e2e72000 ---p 00000000 00:00 0 > 7f53e2e72000-7f53e2f37000 rwxp 00000000 00:00 0 > 7f53e2f37000-7f53e2f3a000 ---p 00000000 00:00 0 > 7f53e2f3a000-7f53f4000000 rwxp 00000000 00:00 0 > 7f53f4000000-7f53f4040000 rwxp 00000000 00:00 0 > 7f53f4040000-7f53f8000000 ---p 00000000 00:00 0 > 7f53f805f000-7f53f806e000 r-xs 00667000 fd:00 928264 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/charsets.jar > 7f53f806e000-7f53f807d000 r-xs 00667000 fd:00 928264 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/charsets.jar > 7f53f807d000-7f53f8080000 ---p 00000000 00:00 0 > 7f53f8080000-7f53f8145000 rwxp 00000000 00:00 0 > 7f53f8145000-7f53f8148000 ---p 00000000 00:00 0 > 7f53f8148000-7f53f820d000 rwxp 00000000 00:00 0 > 7f53f820d000-7f53f8210000 ---p 00000000 00:00 0 > 7f53f8210000-7f53f82d5000 rwxp 00000000 00:00 0 > 7f53f8339000-7f53f833c000 ---p 00000000 00:00 0 > 7f53f833c000-7f53f8401000 rwxp 00000000 00:00 0 > 7f53f8401000-7f53f8404000 ---p 00000000 00:00 0 > 7f53f8404000-7f53f84c9000 rwxp 00000000 00:00 0 > 7f53f84c9000-7f53f84cc000 ---p 00000000 00:00 0 > 7f53f84cc000-7f53f8591000 rwxp 00000000 00:00 0 > 7f53f8591000-7f53f8594000 ---p 00000000 00:00 0 > 7f53f8594000-7f53f8659000 rwxp 00000000 00:00 0 > 7f53f8659000-7f53f865c000 ---p 00000000 00:00 0 > 7f53f865c000-7f53f8721000 rwxp 00000000 00:00 0 > 7f53f8721000-7f53f8724000 ---p 00000000 00:00 0 > 7f53f8724000-7f53f87e9000 rwxp 00000000 00:00 0 > 7f53f87e9000-7f53f87ec000 ---p 00000000 00:00 0 > 7f53f87ec000-7f53f88b1000 rwxp 00000000 00:00 0 > 7f53f88b1000-7f53f88b4000 ---p 00000000 00:00 0 > 7f53f88b4000-7f53f8979000 rwxp 00000000 00:00 0 > 7f53f8979000-7f53f897c000 r-xs 00027000 fd:00 1447062 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/sunjce_provider.jar > 7f53f897c000-7f53f897f000 ---p 00000000 00:00 0 > 7f53f897f000-7f53f8a44000 rwxp 00000000 00:00 0 > 7f53f8a44000-7f53f8a45000 ---p 00000000 00:00 0 > 7f53f8a45000-7f53f8b45000 rwxp 00000000 00:00 0 > 7f53f8b45000-7f53f8b48000 ---p 00000000 00:00 0 > 7f53f8b48000-7f53f8c0d000 rwxp 00000000 00:00 0 > 7f53f8c0d000-7f53f8c10000 ---p 00000000 00:00 0 > 7f53f8c10000-7f53f8cd5000 rwxp 00000000 00:00 0 > 7f53f8cd5000-7f53f8cd8000 ---p 00000000 00:00 0 > 7f53f8cd8000-7f53f8d9d000 rwxp 00000000 00:00 0 > 7f53f8d9d000-7f53f8da0000 ---p 00000000 00:00 0 > 7f53f8da0000-7f53f8e65000 rwxp 00000000 00:00 0 > 7f53f8e65000-7f53f8e6b000 r-xp 00000000 fd:00 928241 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so > 7f53f8e6b000-7f53f8f6a000 ---p 00006000 fd:00 928241 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so > 7f53f8f6a000-7f53f8f6c000 rwxp 00005000 fd:00 928241 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libmanagement.so > 7f53f8f6c000-7f53f8f7f000 r-xp 00000000 fd:00 928245 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so > 7f53f8f7f000-7f53f9080000 ---p 00013000 fd:00 928245 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so > 7f53f9080000-7f53f9083000 rwxp 00014000 fd:00 928245 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libnet.so > 7f53f9083000-7f53f9086000 ---p 00000000 00:00 0 > 7f53f9086000-7f53f914b000 rwxp 00000000 00:00 0 > 7f53f914b000-7f53f914e000 ---p 00000000 00:00 0 > 7f53f914e000-7f53f924c000 rwxp 00000000 00:00 0 > 7f53f924c000-7f53f924f000 ---p 00000000 00:00 0 > 7f53f924f000-7f53f934d000 rwxp 00000000 00:00 0 > 7f53f934d000-7f53f9350000 ---p 00000000 00:00 0 > 7f53f9350000-7f53f9415000 rwxp 00000000 00:00 0 > 7f53f9415000-7f53f9418000 ---p 00000000 00:00 0 > 7f53f9418000-7f53f94dd000 rwxp 00000000 00:00 0 > 7f53f94dd000-7f53f94e0000 ---p 00000000 00:00 0 > 7f53f94e0000-7f53f95a5000 rwxp 00000000 00:00 0 > 7f53f95a5000-7f53f95a8000 ---p 00000000 00:00 0 > 7f53f95a8000-7f53f966d000 rwxp 00000000 00:00 0 > 7f53f966d000-7f53f966e000 ---p 00000000 00:00 0 > 7f53f966e000-7f53f97a2000 rwxp 00000000 00:00 0 > 7f53f97a2000-7f53f9939000 r-xs 0307a000 fd:00 928317 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/rt.jar > 7f53f9939000-7f53fa0e9000 rwxp 00000000 00:00 0 > 7f53fa0e9000-7f53fa0ea000 ---p 00000000 00:00 0 > 7f53fa0ea000-7f53fadf6000 rwxp 00000000 00:00 0 > 7f53fadf6000-7f53fadf7000 ---p 00000000 00:00 0 > 7f53fadf7000-7f53faef7000 rwxp 00000000 00:00 0 > 7f53faef7000-7f53faef8000 ---p 00000000 00:00 0 > 7f53faef8000-7f53faff8000 rwxp 00000000 00:00 0 > 7f53faff8000-7f53faff9000 ---p 00000000 00:00 0 > 7f53faff9000-7f53fb0f9000 rwxp 00000000 00:00 0 > 7f53fb0f9000-7f53fb0fa000 ---p 00000000 00:00 0 > 7f53fb0fa000-7f53fb1fa000 rwxp 00000000 00:00 0 > 7f53fb1fa000-7f53fb1fb000 ---p 00000000 00:00 0 > 7f53fb1fb000-7f53fb2fb000 rwxp 00000000 00:00 0 > 7f53fb2fb000-7f53fb2fc000 ---p 00000000 00:00 0 > 7f53fb2fc000-7f53fb3fc000 rwxp 00000000 00:00 0 > 7f53fb3fc000-7f53fb3fd000 ---p 00000000 00:00 0 > 7f53fb3fd000-7f53fb4fd000 rwxp 00000000 00:00 0 > 7f53fb4fd000-7f53fb4fe000 ---p 00000000 00:00 0 > 7f53fb4fe000-7f53fb5fe000 rwxp 00000000 00:00 0 > 7f53fb5fe000-7f53fb5ff000 ---p 00000000 00:00 0 > 7f53fb5ff000-7f53fb6ff000 rwxp 00000000 00:00 0 > 7f53fb6ff000-7f53fb700000 ---p 00000000 00:00 0 > 7f53fb700000-7f53fc000000 rwxp 00000000 00:00 0 > 7f53fc000000-7f53fc145000 rwxp 00000000 00:00 0 > 7f53fc145000-7f5400000000 ---p 00000000 00:00 0 > 7f5400000000-7f540016f000 rwxp 00000000 00:00 0 > 7f540016f000-7f5404000000 ---p 00000000 00:00 0 > 7f5404000000-7f540406a000 rwxp 00000000 00:00 0 > 7f540406a000-7f5408000000 ---p 00000000 00:00 0 > 7f5408000000-7f5408004000 r-xs 00035000 fd:00 1447063 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/sunpkcs11.jar > 7f5408004000-7f540800c000 r-xs 00115000 fd:00 928316 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/resources.jar > 7f540800c000-7f5408012000 r-xs 00095000 fd:00 928303 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/jsse.jar > 7f5408012000-7f540801f000 r-xs 000b5000 fd:00 2228415 /opt/tomcat/lib/tomcat-coyote.jar > 7f540801f000-7f5408024000 r-xs 0003a000 fd:00 2228406 /opt/tomcat/lib/catalina-tribes.jar > 7f5408024000-7f5408025000 r-xs 00005000 fd:00 2228421 /opt/tomcat/lib/tomcat-util.jar > 7f5408025000-7f5408027000 r-xs 0000b000 fd:00 2228419 /opt/tomcat/lib/tomcat-i18n-ja.jar > 7f5408027000-7f540802b000 r-xs 00036000 fd:00 2228416 /opt/tomcat/lib/tomcat-dbcp.jar > 7f540802b000-7f540802c000 r-xs 00001000 fd:00 2228414 /opt/tomcat/lib/tomcat-api.jar > 7f540802c000-7f540803c000 r-xs 0019c000 fd:00 2228408 /opt/tomcat/lib/ecj-3.7.2.jar > 7f540803c000-7f540803f000 r-xs 0001c000 fd:00 2228420 /opt/tomcat/lib/tomcat-jdbc.jar > 7f540803f000-7f5408042000 r-xs 00013000 fd:00 2228412 /opt/tomcat/lib/jsp-api.jar > 7f5408042000-7f5408044000 r-xs 0000a000 fd:00 2228418 /opt/tomcat/lib/tomcat-i18n-fr.jar > 7f5408044000-7f5408047000 r-xs 0001c000 fd:00 2228410 /opt/tomcat/lib/jasper-el.jar > 7f5408047000-7f540804a000 r-xs 00029000 fd:00 2228413 /opt/tomcat/lib/servlet-api.jar > 7f540804a000-7f540804c000 r-xs 0000c000 fd:00 2228404 /opt/tomcat/lib/catalina-ant.jar > 7f540804c000-7f540805f000 r-xs 00169000 fd:00 2228407 /opt/tomcat/lib/catalina.jar > 7f540805f000-7f5408090000 rwxp 00000000 00:00 0 > 7f5408090000-7f5408091000 ---p 00000000 00:00 0 > 7f5408091000-7f5408191000 rwxp 00000000 00:00 0 > 7f5408191000-7f5408192000 ---p 00000000 00:00 0 > 7f5408192000-7f540b4d9000 rwxp 00000000 00:00 0 > 7f540b4d9000-7f540b4da000 rwxp 00000000 00:00 0 > 7f540b4da000-7f540b4db000 ---p 00000000 00:00 0 > 7f540b4db000-7f540b5db000 rwxp 00000000 00:00 0 > 7f540b5db000-7f540b5dc000 ---p 00000000 00:00 0 > 7f540b5dc000-7f540b6dc000 rwxp 00000000 00:00 0 > 7f540b6dc000-7f540b6dd000 ---p 00000000 00:00 0 > 7f540b6dd000-7f540b7dd000 rwxp 00000000 00:00 0 > 7f540b7dd000-7f540b7de000 ---p 00000000 00:00 0 > 7f540b7de000-7f541bcde000 rwxp 00000000 00:00 0 > 7f541bcde000-7f541bcec000 r-xp 00000000 fd:00 928254 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so > 7f541bcec000-7f541bdee000 ---p 0000e000 fd:00 928254 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so > 7f541bdee000-7f541bdf1000 rwxp 00010000 fd:00 928254 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libzip.so > 7f541bdf1000-7f541bdf2000 rwxp 00000000 00:00 0 > 7f541bdf2000-7f541bdfe000 r-xp 00000000 fd:00 656090 /lib64/libnss_files-2.12.so > 7f541bdfe000-7f541bffe000 ---p 0000c000 fd:00 656090 /lib64/libnss_files-2.12.so > 7f541bffe000-7f541bfff000 r-xp 0000c000 fd:00 656090 /lib64/libnss_files-2.12.so > 7f541bfff000-7f541c000000 rwxp 0000d000 fd:00 656090 /lib64/libnss_files-2.12.so > 7f541c000000-7f541c470000 rwxp 00000000 00:00 0 > 7f541c470000-7f5420000000 ---p 00000000 00:00 0 > 7f5420002000-7f5420005000 r-xs 00013000 fd:00 928301 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/jce.jar > 7f5420005000-7f5420008000 r-xs 000cc000 fd:00 1447060 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/ext/localedata.jar > 7f5420008000-7f5420009000 r-xs 00003000 fd:00 2228403 /opt/tomcat/lib/annotations-api.jar > 7f5420009000-7f542000b000 r-xs 00011000 fd:00 2228417 /opt/tomcat/lib/tomcat-i18n-es.jar > 7f542000b000-7f5420013000 r-xs 00089000 fd:00 2228411 /opt/tomcat/lib/jasper.jar > 7f5420013000-7f5420015000 r-xs 0000a000 fd:00 2228409 /opt/tomcat/lib/el-api.jar > 7f5420015000-7f5420018000 r-xs 0001e000 fd:00 2228405 /opt/tomcat/lib/catalina-ha.jar > 7f5420018000-7f5420019000 rwxp 00000000 00:00 0 > 7f5420019000-7f542001b000 r-xs 00008000 fd:00 2228399 /opt/tomcat/bin/tomcat-juli.jar > 7f542001b000-7f542001c000 r-xs 00005000 fd:00 2228392 /opt/tomcat/bin/commons-daemon.jar > 7f542001c000-7f542001e000 r-xs 00006000 fd:00 2228388 /opt/tomcat/bin/bootstrap.jar > 7f542001e000-7f5420047000 r-xp 00000000 fd:00 928233 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so > 7f5420047000-7f5420146000 ---p 00029000 fd:00 928233 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so > 7f5420146000-7f542014d000 rwxp 00028000 fd:00 928233 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libjava.so > 7f542014d000-7f542015a000 r-xp 00000000 fd:00 928253 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so > 7f542015a000-7f5420259000 ---p 0000d000 fd:00 928253 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so > 7f5420259000-7f542025c000 rwxp 0000c000 fd:00 928253 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/libverify.so > 7f542025c000-7f542025f000 ---p 00000000 00:00 0 > 7f542025f000-7f5420324000 rwxp 00000000 00:00 0 > 7f5420324000-7f5420c3f000 r-xp 00000000 fd:00 928262 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > 7f5420c3f000-7f5420d40000 ---p 0091b000 fd:00 928262 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > 7f5420d40000-7f5420ef5000 rwxp 0091c000 fd:00 928262 /usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server/libjvm.so > 7f5420ef5000-7f5420f33000 rwxp 00000000 00:00 0 > 7f5420f33000-7f5420f3b000 rwxs 00000000 fd:00 795098 /tmp/hsperfdata_ramire79/28861 > 7f5420f3b000-7f5420f3c000 rwxp 00000000 00:00 0 > 7f5420f3c000-7f5420f3d000 r-xp 00000000 00:00 0 > 7f5420f3d000-7f5420f3f000 rwxp 00000000 00:00 0 > 7fff4984d000-7fff49863000 rwxp 00000000 00:00 0 [stack] > 7fff499cf000-7fff499d0000 r-xp 00000000 00:00 0 [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] > > VM Arguments: > jvm_args: -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Xms12g -Xmx12g -Xss800k -XX:OldSize=8g -XX:NewSize=4g -XX:MaxNewSize=4g -XX:NewRatio=3 -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:InitialCodeCacheSize=256m -XX:ReservedCodeCacheSize=256m -XX:ParallelGCThreads=4 -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=15 -XX:StackShadowPages=10 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+UseTLAB -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelCMSThreads=12 -XX:+ParallelRefProcEnabled -XX:CMSMarkStackSize=16M -XX:CMSMarkStackSizeMax=16M -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:PrintCMSStatistics=2 -XX:+PrintVMOptions -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCTaskTimeStamps -XX:+PrintCommandLineFlags -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCDateStamps -Xloggc:/opt/tomcat/logs/gc.log -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dcom.sun.management.snmp.interface=0.0.0.0 -Dcom.sun.management.snmp.port=8161 -Dcom.sun.management.snmp.acl=false -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=qa1.kuali.utoronto.ca -Djava.endorsed.dirs=/opt/tomcat/endorsed -Dcatalina.base=/opt/tomcat -Dcatalina.home=/opt/tomcat -Djava.io.tmpdir=/opt/tomcat/temp > java_command: org.apache.catalina.startup.Bootstrap start > Launcher Type: SUN_STANDARD > > Environment Variables: > PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ramire79/bin > LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.33.x86_64/jre/../lib/amd64 > SHELL=/bin/bash > > Signal Handlers: > SIGSEGV: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGBUS: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGFPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGPIPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGXFSZ: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGILL: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGUSR2: [libjvm.so+0x711de0], sa_mask[0]=0x00000000, sa_flags=0x10000004 > SIGHUP: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGTERM: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGQUIT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > > > --------------- S Y S T E M --------------- > > OS:Red Hat Enterprise Linux Server release 6.3 (Santiago) > > uname:Linux 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 > libc:glibc 2.12 NPTL 2.12 > rlimit: STACK 10240k, CORE 0k, NPROC 1024, NOFILE 4096, AS infinity > load average:6.24 3.43 1.80 > > /proc/meminfo: > MemTotal: 16334044 kB > MemFree: 5305268 kB > Buffers: 136684 kB > Cached: 502616 kB > SwapCached: 0 kB > Active: 10435928 kB > Inactive: 205704 kB > Active(anon): 10002492 kB > Inactive(anon): 16 kB > Active(file): 433436 kB > Inactive(file): 205688 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 6160376 kB > SwapFree: 6160376 kB > Dirty: 208 kB > Writeback: 0 kB > AnonPages: 10002112 kB > Mapped: 30296 kB > Shmem: 184 kB > Slab: 162636 kB > SReclaimable: 126780 kB > SUnreclaim: 35856 kB > KernelStack: 2840 kB > PageTables: 25960 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 14327396 kB > Committed_AS: 14826588 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 304312 kB > VmallocChunk: 34359428600 kB > HardwareCorrupted: 0 kB > AnonHugePages: 9627648 kB > HugePages_Total: 0 > HugePages_Free: 0 > HugePages_Rsvd: 0 > HugePages_Surp: 0 > Hugepagesize: 2048 kB > DirectMap4k: 10240 kB > DirectMap2M: 16766976 kB > > > CPU:total 6 (1 cores per cpu, 1 threads per core) family 16 model 8 stepping 0, cmov, cx8, fxsr, mmx, sse, sse2, sse3, popcnt, mmxext, 3dnowpref, lzcnt, sse4a > > /proc/cpuinfo: > processor: 0 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 1 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 2 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 3 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 4 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > processor: 5 > vendor_id: AuthenticAMD > cpu family: 16 > model: 8 > model name: Six-Core AMD Opteron(tm) Processor 2439 SE > stepping: 0 > cpu MHz: 2800.113 > cache size: 512 KB > fpu: yes > fpu_exception: yes > cpuid level: 5 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good tsc_reliable nonstop_tsc unfair_spinlock pni cx16 popcnt hypervisor lahf_lm extapic abm sse4a misalignsse 3dnowprefetch > bogomips: 5600.22 > TLB size: 1024 4K pages > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > > > Memory: 4k page, physical 16334044k(5305268k free), swap 6160376k(6160376k free) > > vm_info: Java HotSpot(TM) 64-Bit Server VM (20.8-b03) for linux-amd64 JRE (1.6.0_33-b03), built on May 9 2012 09:57:57 by "java_re" with gcc 3.2.2 (SuSE Linux) > > time: Tue Oct 2 17:06:26 2012 > elapsed time: 1663 seconds > > [root at course-search-as-qa bin]# From john.cuthbertson at oracle.com Wed Oct 3 16:37:15 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 03 Oct 2012 09:37:15 -0700 Subject: RFR(S/M): 7127708: G1: change task num types from int to uint in concurrent mark In-Reply-To: References: <506B6230.4030002@oracle.com> Message-ID: <506C69BB.4050006@oracle.com> Hi Vitaly, Good catch - and you are correct. Changed. JohnC On 10/02/12 17:33, Vitaly Davidovich wrote: > > Hi John, > > concurrentMark.cpp: > > 4118 if (_cm->verbose_low()) { > 4119 gclog_or_tty->print_cr("[%d] starting termination > protocol", _worker_id); > 4120 } > > Should be %u format? Same in g1OopClosuresg1OopClosures.inline.hpp: > if (_cm->verbose_high()) { > 114 gclog_or_tty->print_cr("[%d] we're looking at location " > 115 "*"PTR_FORMAT" = "PTR_FORMAT, > 116 _task->worker_id(), p, (void*) obj); > 117 } > > Thanks > > Sent from my phone > > On Oct 2, 2012 5:54 PM, "John Cuthbertson" > > wrote: > > Hi Everyone, > > Can I have another couple of volunteers review the changes for > this CR - the webrev can be found at: > http://cr.openjdk.java.net/~johnc/7127708/webrev.0/ > > > Summary: > Exactly what it says the the CR's description: > > In G1's concurrent mark files we use an int for the task ID > and call it "task num". Recent work done by Jon Masamitsu: > > 7121618: Change type of number of GC workers to unsigned int > > has replaced int's with uint's for the worker IDs across our > GCs. We should also make the necessary changes in the G1 files > to further conform to that. While we're at it we should also > rename "task num" as "worker id" to be consistent with the > rest of the GCs. > > > > The changes were contributed by Kaushik Srenevasan from Twitter. > I've looked them over and they look OK to me. > > Testing: jtreg tests and specjvm (Kaushik); GC test suite with a > low IHOP and marking verification (JohnC); a jprt test run is in > the queue. > > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Oct 3 17:56:39 2012 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 03 Oct 2012 17:56:39 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7199349: NPG: PS: Crash seen in jprt Message-ID: <20121003175642.94DF24717D@hg.openjdk.java.net> Changeset: f81a7c0c618d Author: jmasa Date: 2012-10-03 08:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f81a7c0c618d 7199349: NPG: PS: Crash seen in jprt Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/runtime/globals.hpp From jesper.wilhelmsson at oracle.com Wed Oct 3 20:52:24 2012 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 03 Oct 2012 20:52:24 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000351: Tenuring threshold should be unsigned Message-ID: <20121003205230.CF56547181@hg.openjdk.java.net> Changeset: 22b8d3d181d9 Author: jwilhelm Date: 2012-10-03 20:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/22b8d3d181d9 8000351: Tenuring threshold should be unsigned Summary: Change the flags and variables related to tenuring threshold to be unsigned Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp From john.cuthbertson at oracle.com Thu Oct 4 00:14:24 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 03 Oct 2012 17:14:24 -0700 Subject: RFR(XXS): 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file Message-ID: <506CD4E0.5070602@oracle.com> Hi Everyone, A quickie - webrev can be found at: http://cr.openjdk.java.net/~johnc/8000358/webrev.0/ Summary: A missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on(). Many thanks to Mikael Gerdin for noticing and diagnosing the issue, and suggesting the fix. Testing: gcbasher with +PrintHeapAtGC for a few GCs and then issuing a kill -11. Thanks, JohnC From azeem.jiva at oracle.com Thu Oct 4 01:55:03 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Wed, 03 Oct 2012 20:55:03 -0500 Subject: RFR(XXS): 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file In-Reply-To: <506CD4E0.5070602@oracle.com> References: <506CD4E0.5070602@oracle.com> Message-ID: <506CEC77.3000603@oracle.com> Looks good On 10/03/2012 07:14 PM, John Cuthbertson wrote: > Hi Everyone, > > A quickie - webrev can be found at: > http://cr.openjdk.java.net/~johnc/8000358/webrev.0/ > > Summary: > A missing call to MetaspaceAux::print_on() in > G1CollectedHeap::print_on(). Many thanks to Mikael Gerdin for noticing > and diagnosing the issue, and suggesting the fix. > > Testing: > gcbasher with +PrintHeapAtGC for a few GCs and then issuing a kill -11. > > Thanks, > > JohnC From jon.masamitsu at oracle.com Thu Oct 4 02:43:50 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 03 Oct 2012 19:43:50 -0700 Subject: RFR(XXS): 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file In-Reply-To: <506CD4E0.5070602@oracle.com> References: <506CD4E0.5070602@oracle.com> Message-ID: <506CF7E6.7070700@oracle.com> Looks good. Thanks for fixing it. On 10/3/2012 5:14 PM, John Cuthbertson wrote: > Hi Everyone, > > A quickie - webrev can be found at: > http://cr.openjdk.java.net/~johnc/8000358/webrev.0/ > > Summary: > A missing call to MetaspaceAux::print_on() in > G1CollectedHeap::print_on(). Many thanks to Mikael Gerdin for noticing > and diagnosing the issue, and suggesting the fix. > > Testing: > gcbasher with +PrintHeapAtGC for a few GCs and then issuing a kill -11. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Thu Oct 4 20:56:46 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Thu, 04 Oct 2012 20:56:46 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000311: G1: ParallelGCThreads==0 broken Message-ID: <20121004205650.AED9F471AC@hg.openjdk.java.net> Changeset: 2e6857353b2c Author: johnc Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2e6857353b2c 8000311: G1: ParallelGCThreads==0 broken Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp From jon.masamitsu at oracle.com Thu Oct 4 23:30:06 2012 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 04 Oct 2012 23:30:06 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20121004233012.84AB2471B6@hg.openjdk.java.net> Changeset: 097d78aaf2b5 Author: jmasa Date: 2012-10-04 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/097d78aaf2b5 7198873: NPG: VM Does not unload classes with UseConcMarkSweepGC Reviewed-by: johnc, mgerdin, jwilhelm ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: ca70b919819f Author: jmasa Date: 2012-10-04 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ca70b919819f Merge From jon.masamitsu at oracle.com Fri Oct 5 22:12:56 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 05 Oct 2012 15:12:56 -0700 Subject: Request for review (1 line) - 7186847 Message-ID: <506F5B68.2020306@oracle.com> 7186847: NPG: Use large pages for metadata allocations http://cr.openjdk.java.net/~jmasa/7186847/webrev.00/ Thanks. Jon From alejandro.murillo at oracle.com Sat Oct 6 00:58:11 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 06 Oct 2012 00:58:11 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 11 new changesets Message-ID: <20121006005904.D8798471DD@hg.openjdk.java.net> Changeset: 2dd08e86a2bf Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2dd08e86a2bf Added tag jdk8-b58 for changeset 6bb378c50828 ! .hgtags Changeset: 8a1a6b9b4f20 Author: katleman Date: 2012-10-03 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8a1a6b9b4f20 Merge ! .hgtags - 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/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 - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java Changeset: a3fd4914ac81 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a3fd4914ac81 Added tag jdk8-b59 for changeset 8a1a6b9b4f20 ! .hgtags Changeset: f6b0eb4e44cf Author: twisti Date: 2012-10-01 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f6b0eb4e44cf 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path Reviewed-by: jrose, kvn ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciClassList.hpp + src/share/vm/ci/ciMethodType.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: 859c45fb8cea Author: kvn Date: 2012-10-02 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/859c45fb8cea 7201026: add vector for shift count Summary: Add generation of vectors for scalar shift count. Reviewed-by: roland, twisti, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! test/compiler/7200264/Test7200264.sh Changeset: f13867c41f73 Author: kvn Date: 2012-10-02 14:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f13867c41f73 7199742: A lot of C2 OSR compilations of the same method's bci Summary: Don't clone head of OSR loop. Reviewed-by: jrose, twisti ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp + test/compiler/7199742/Test7199742.java Changeset: bf2edd3c9b0f Author: neliasso Date: 2012-10-04 06:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf2edd3c9b0f 8000102: Resolve include conflicts Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files. Reviewed-by: kvn Contributed-by: nils.eliasson at oracle.com ! 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 ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: 685457683e86 Author: kvn Date: 2012-10-05 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/685457683e86 Merge Changeset: 1cc7a2a11d00 Author: amurillo Date: 2012-10-05 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cc7a2a11d00 Merge Changeset: 3cfd05b2219a Author: amurillo Date: 2012-10-05 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3cfd05b2219a Added tag hs25-b04 for changeset 1cc7a2a11d00 ! .hgtags Changeset: 81e878c53615 Author: amurillo Date: 2012-10-05 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/81e878c53615 8000498: new hotspot build - hs25-b05 Reviewed-by: jcoomes ! make/hotspot_version From john.cuthbertson at oracle.com Sat Oct 6 10:04:17 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 06 Oct 2012 10:04:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7127708: G1: change task num types from int to uint in concurrent mark Message-ID: <20121006100427.D36E3471E9@hg.openjdk.java.net> Changeset: 8a5ea0a9ccc4 Author: johnc Date: 2012-10-06 01:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8a5ea0a9ccc4 7127708: G1: change task num types from int to uint in concurrent mark Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich. Reviewed-by: johnc Contributed-by: Kaushik Srenevasan ! 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 ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp From rednaxelafx at gmail.com Sat Oct 6 13:52:01 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 6 Oct 2012 21:52:01 +0800 Subject: Getting the Heap virtual addresses? In-Reply-To: <50699663.8030900@oracle.com> References: <5065E7B5.5080904@oracle.com> <50699663.8030900@oracle.com> Message-ID: Hi Azeem, (Sorry for the late reply. Just in case someone interested who's not familiar with Serviceability Agent...) The "universe" command in CLHSDB would fit your need perfectly. For example, $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB hsdb> attach 1234 Attaching to process 1234, please wait... hsdb> universe ParallelScavengeHeap [ PSYoungGen [ eden = [0x00000000fd560000,0x00000000fedc00a0,0x00000000ff4c0000] , from = [0x00000000ff750000,0x00000000ff9da020,0x00000000ff9e0000] , to = [0x00000000ff4c0000,0x00000000ff4c0000,0x00000000ff750000] ] PSOldGen [ [0x00000000f8000000,0x00000000f82eb078,0x00000000fa9b0000] ] PSPermGen [ [0x00000000f2e00000,0x00000000f3970798,0x00000000f42c0000] ] ] hsdb> quit $ If you need to programmatically print this information, you could use sun.jvm.hotspot.gc_interface.CollectedHeap.print(). For example, import sun.jvm.hotspot.gc_interface.*; import sun.jvm.hotspot.runtime.*; import sun.jvm.hotspot.tools.*; public class ShowUniverse extends Tool { public void run() { CollectedHeap heap = VM.getVM().getUniverse().heap(); heap.print(); } public static void main(String[] args) { ShowUniverse tool = new ShowUniverse(); tool.start(args); tool.stop(); } } And used as: $ javac -classpath $JAVA_HOME/lib/sa-jdi.jar ShowUniverse.java $ java -cp .:$JAVA_HOME/lib/sa-jdi.jar ShowUniverse 1234 Attaching to process ID 1234, please wait... Debugger attached successfully. Server compiler detected. JVM version is 22.0-b10 ParallelScavengeHeap [ PSYoungGen [ eden = [0x00000000fd560000,0x00000000fedc00a0,0x00000000ff4c0000] , from = [0x00000000ff750000,0x00000000ff9da020,0x00000000ff9e0000] , to = [0x00000000ff4c0000,0x00000000ff4c0000,0x00000000ff750000] ] PSOldGen [ [0x00000000f8000000,0x00000000f82eb078,0x00000000fa9b0000] ] PSPermGen [ [0x00000000f2e00000,0x00000000f3970798,0x00000000f42c0000] ] ] $ If you need to access the individual virtual addresses programmatically, just look at the implementations of CollectedHeap.printOn(PrintStream tty) in GenCollectedHeap/ParallelScavengeHeap/G1CollectedHeap for example. Hope that helps, Kris On Mon, Oct 1, 2012 at 9:10 PM, Azeem Jiva wrote: > Krystal, > That would work as well, I just need some way of getting the data while > the JVM is running. > > > On 09/30/2012 08:58 PM, Krystal Mok wrote: > > Hi Azeem, > > It'd be easy to get with an SA agent instead of a JVMTI agent. Would > that do for you? > > - Kris > > On Sat, Sep 29, 2012 at 2:08 AM, Azeem Jiva wrote: > >> Is there a way to get at the virtual addresses for the heap from a JVMTI >> agent? The data is clearly available as PrintGCDetails dumps the >> information at the end of the run. >> >> -- >> Azeem Jiva >> @javawithjiva >> >> > > -- > Azeem Jiva > @javawithjiva > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.caspole at amd.com Mon Oct 8 14:08:14 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 8 Oct 2012 10:08:14 -0400 Subject: Getting the Heap virtual addresses? In-Reply-To: References: <5065E7B5.5080904@oracle.com> <50699663.8030900@oracle.com> Message-ID: Is there a wiki or anything for Serviceability Agent? That looks useful. Thanks, Eric On Oct 6, 2012, at 9:52 AM, Krystal Mok wrote: > Hi Azeem, > > (Sorry for the late reply. Just in case someone interested who's > not familiar with Serviceability Agent...) > > The "universe" command in CLHSDB would fit your need perfectly. > For example, > > $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB > hsdb> attach 1234 > Attaching to process 1234, please wait... > hsdb> universe > ParallelScavengeHeap [ PSYoungGen [ eden = > [0x00000000fd560000,0x00000000fedc00a0,0x00000000ff4c0000] , from > = [0x00000000ff750000,0x00000000ff9da020,0x00000000ff9e0000] , to > = [0x00000000ff4c0000,0x00000000ff4c0000,0x00000000ff750000] ] > PSOldGen > [ [0x00000000f8000000,0x00000000f82eb078,0x00000000fa9b0000] ] > PSPermGen > [ [0x00000000f2e00000,0x00000000f3970798,0x00000000f42c0000] ] ] > hsdb> quit > $ > > If you need to programmatically print this information, you could > use sun.jvm.hotspot.gc_interface.CollectedHeap.print(). > For example, > > import sun.jvm.hotspot.gc_interface.*; > import sun.jvm.hotspot.runtime.*; > import sun.jvm.hotspot.tools.*; > > public class ShowUniverse extends Tool { > public void run() { > CollectedHeap heap = VM.getVM().getUniverse().heap(); > heap.print(); > } > > public static void main(String[] args) { > ShowUniverse tool = new ShowUniverse(); > tool.start(args); > tool.stop(); > } > } > > And used as: > > $ javac -classpath $JAVA_HOME/lib/sa-jdi.jar ShowUniverse.java > $ java -cp .:$JAVA_HOME/lib/sa-jdi.jar ShowUniverse 1234 > Attaching to process ID 1234, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 22.0-b10 > ParallelScavengeHeap [ PSYoungGen [ eden = > [0x00000000fd560000,0x00000000fedc00a0,0x00000000ff4c0000] , from > = [0x00000000ff750000,0x00000000ff9da020,0x00000000ff9e0000] , to > = [0x00000000ff4c0000,0x00000000ff4c0000,0x00000000ff750000] ] > PSOldGen > [ [0x00000000f8000000,0x00000000f82eb078,0x00000000fa9b0000] ] > PSPermGen > [ [0x00000000f2e00000,0x00000000f3970798,0x00000000f42c0000] ] ] > > $ > > If you need to access the individual virtual addresses > programmatically, just look at the implementations of > CollectedHeap.printOn(PrintStream tty) in GenCollectedHeap/ > ParallelScavengeHeap/G1CollectedHeap for example. > > Hope that helps, > Kris > > On Mon, Oct 1, 2012 at 9:10 PM, Azeem Jiva > wrote: > Krystal, > That would work as well, I just need some way of getting the data > while the JVM is running. > > > On 09/30/2012 08:58 PM, Krystal Mok wrote: >> Hi Azeem, >> >> It'd be easy to get with an SA agent instead of a JVMTI agent. >> Would that do for you? >> >> - Kris >> >> On Sat, Sep 29, 2012 at 2:08 AM, Azeem Jiva >> wrote: >> Is there a way to get at the virtual addresses for the heap from a >> JVMTI agent? The data is clearly available as PrintGCDetails >> dumps the information at the end of the run. >> >> -- >> Azeem Jiva >> @javawithjiva >> >> > > -- Azeem Jiva @javawithjiva > From rednaxelafx at gmail.com Mon Oct 8 14:30:46 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 8 Oct 2012 22:30:46 +0800 Subject: Getting the Heap virtual addresses? In-Reply-To: References: <5065E7B5.5080904@oracle.com> <50699663.8030900@oracle.com> Message-ID: Not much useful reading material on SA other than the source code, which speaks for itself. A lot of classes in SA mirror their counterparts in HotSpot's C++ code, so they're not that hard to understand. The ones available are: 1. The HotSpot? Serviceability Agent: An out-of-process high level debugger for a Java? virtual machine http://static.usenix.org/event/jvm01/full_papers/russell/russell_html/ This is an old paper, an overview of the SA. 2. Simple documentation on HotSpot Serviceability http://openjdk.java.net/groups/hotspot/docs/Serviceability.html 3. The docs in HotSpot's source code, located in hotspot/agent/doc 4. Poonam Bajaj did a presentation on the SA Plugin for VisualVM last year at JavaOne https://blogs.oracle.com/poonam/entry/javaone_presentation_on_sa_plugin - Kris On Mon, Oct 8, 2012 at 10:08 PM, Eric Caspole wrote: > Is there a wiki or anything for Serviceability Agent? That looks useful. > Thanks, > Eric > > > > > On Oct 6, 2012, at 9:52 AM, Krystal Mok wrote: > > Hi Azeem, >> >> (Sorry for the late reply. Just in case someone interested who's not >> familiar with Serviceability Agent...) >> >> The "universe" command in CLHSDB would fit your need perfectly. >> For example, >> >> $ java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB >> hsdb> attach 1234 >> Attaching to process 1234, please wait... >> hsdb> universe >> ParallelScavengeHeap [ PSYoungGen [ eden = [0x00000000fd560000,** >> 0x00000000fedc00a0,**0x00000000ff4c0000] , from = [0x00000000ff750000,** >> 0x00000000ff9da020,**0x00000000ff9e0000] , to = [0x00000000ff4c0000,** >> 0x00000000ff4c0000,**0x00000000ff750000] ] PSOldGen [ >> [0x00000000f8000000,**0x00000000f82eb078,**0x00000000fa9b0000] ] >> PSPermGen [ [0x00000000f2e00000,**0x00000000f3970798,**0x00000000f42c0000] >> ] ] >> hsdb> quit >> $ >> >> If you need to programmatically print this information, you could use >> sun.jvm.hotspot.gc_interface.**CollectedHeap.print(). >> For example, >> >> import sun.jvm.hotspot.gc_interface.***; >> import sun.jvm.hotspot.runtime.*; >> import sun.jvm.hotspot.tools.*; >> >> public class ShowUniverse extends Tool { >> public void run() { >> CollectedHeap heap = VM.getVM().getUniverse().heap(**); >> heap.print(); >> } >> >> public static void main(String[] args) { >> ShowUniverse tool = new ShowUniverse(); >> tool.start(args); >> tool.stop(); >> } >> } >> >> And used as: >> >> $ javac -classpath $JAVA_HOME/lib/sa-jdi.jar ShowUniverse.java >> $ java -cp .:$JAVA_HOME/lib/sa-jdi.jar ShowUniverse 1234 >> Attaching to process ID 1234, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 22.0-b10 >> ParallelScavengeHeap [ PSYoungGen [ eden = [0x00000000fd560000,** >> 0x00000000fedc00a0,**0x00000000ff4c0000] , from = [0x00000000ff750000,** >> 0x00000000ff9da020,**0x00000000ff9e0000] , to = [0x00000000ff4c0000,** >> 0x00000000ff4c0000,**0x00000000ff750000] ] PSOldGen [ >> [0x00000000f8000000,**0x00000000f82eb078,**0x00000000fa9b0000] ] >> PSPermGen [ [0x00000000f2e00000,**0x00000000f3970798,**0x00000000f42c0000] >> ] ] >> >> $ >> >> If you need to access the individual virtual addresses programmatically, >> just look at the implementations of CollectedHeap.printOn(**PrintStream >> tty) in GenCollectedHeap/**ParallelScavengeHeap/**G1CollectedHeap for >> example. >> >> Hope that helps, >> Kris >> >> On Mon, Oct 1, 2012 at 9:10 PM, Azeem Jiva wrote: >> Krystal, >> That would work as well, I just need some way of getting the data while >> the JVM is running. >> >> >> On 09/30/2012 08:58 PM, Krystal Mok wrote: >> >>> Hi Azeem, >>> >>> It'd be easy to get with an SA agent instead of a JVMTI agent. Would >>> that do for you? >>> >>> - Kris >>> >>> On Sat, Sep 29, 2012 at 2:08 AM, Azeem Jiva >>> wrote: >>> Is there a way to get at the virtual addresses for the heap from a JVMTI >>> agent? The data is clearly available as PrintGCDetails dumps the >>> information at the end of the run. >>> >>> -- >>> Azeem Jiva >>> @javawithjiva >>> >>> >>> >> -- Azeem Jiva @javawithjiva >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon Oct 8 14:57:50 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Oct 2012 16:57:50 +0200 Subject: Request for review (1 line) - 7186847 In-Reply-To: <506F5B68.2020306@oracle.com> References: <506F5B68.2020306@oracle.com> Message-ID: <5072E9EE.8050203@oracle.com> Jon, On 2012-10-06 00:12, Jon Masamitsu wrote: > 7186847: NPG: Use large pages for metadata allocations > > http://cr.openjdk.java.net/~jmasa/7186847/webrev.00/ The fix makes sense, but I wonder how many of the allocations coming in through the VirtualSpaceNode constructor are large enough to make use of >4K pages? Since medium chunks are 8K words it looks like only humongous allocations will cause large pages to be allocated. Are humongous metaspace allocations even common enough to warrant the increased "complexity" of the code? I'm not saying that your fix is making the code itself more complex, but it may be misleading people reading it into thinking that large page size allocations are being used when actually they are not. /Mikael > > Thanks. > > Jon -- Mikael Gerdin Java SE VM SQE Stockholm From john.cuthbertson at oracle.com Mon Oct 8 18:08:43 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Mon, 08 Oct 2012 18:08:43 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file Message-ID: <20121008180847.6457B4721C@hg.openjdk.java.net> Changeset: 04155d9c8c76 Author: johnc Date: 2012-10-08 09:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on(). Reviewed-by: azeemj, jmasa Contributed-by: Mikael Gerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From jon.masamitsu at oracle.com Tue Oct 9 02:18:23 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 08 Oct 2012 19:18:23 -0700 Subject: Request for review (1 line) - 7186847 In-Reply-To: <5072E9EE.8050203@oracle.com> References: <506F5B68.2020306@oracle.com> <5072E9EE.8050203@oracle.com> Message-ID: <5073896F.3030308@oracle.com> Mikael, Thanks for the review. I expect VirtualSpaceNodes to grow by VirtualSpaceSize which is 256k and and that's where the use of large pages will have an affect. The Metachunks are allocated out of the space in a VirtualSpaceNode (the large VirtualSpaceNode are divided up into chunks). At least that's what I'm expecting. VirtualSpaceSize are actually smaller that I thought they were so maybe those should be large. At least for 64bit. Jon On 10/8/2012 7:57 AM, Mikael Gerdin wrote: > Jon, > > On 2012-10-06 00:12, Jon Masamitsu wrote: >> 7186847: NPG: Use large pages for metadata allocations >> >> http://cr.openjdk.java.net/~jmasa/7186847/webrev.00/ > > The fix makes sense, but I wonder how many of the allocations coming > in through the VirtualSpaceNode constructor are large enough to make > use of >4K pages? > Since medium chunks are 8K words it looks like only humongous > allocations will cause large pages to be allocated. Are humongous > metaspace allocations even common enough to warrant the increased > "complexity" of the code? > I'm not saying that your fix is making the code itself more complex, > but it may be misleading people reading it into thinking that large > page size allocations are being used when actually they are not. > > /Mikael > >> >> Thanks. >> >> Jon > From mikael.gerdin at oracle.com Tue Oct 9 08:30:51 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Oct 2012 10:30:51 +0200 Subject: Request for review (1 line) - 7186847 In-Reply-To: <5073896F.3030308@oracle.com> References: <506F5B68.2020306@oracle.com> <5072E9EE.8050203@oracle.com> <5073896F.3030308@oracle.com> Message-ID: <5073E0BB.9090100@oracle.com> Jon, On 2012-10-09 04:18, Jon Masamitsu wrote: > Mikael, > > Thanks for the review. > > I expect VirtualSpaceNodes to grow > by VirtualSpaceSize which is 256k and > and that's where the use of large pages > will have an affect. The Metachunks are > allocated out of the space in a > VirtualSpaceNode (the large VirtualSpaceNode > are divided up into chunks). At least that's > what I'm expecting. I guess the only "large" page size which we'll use is 64K pages on sparc then. On x86 there's only 4K and 2M. On sparc there's also 512K, 4M and even larger, but with 256K as the largest page allocation block we'll not use them I think. > > VirtualSpaceSize are actually smaller that > I thought they were so maybe those should > be large. At least for 64bit. Chunks and VirtualSpaceNodes are shared between Metaspaces right? So increasing the VirtualSpaceSize to something like 2M or 4M will not increase memory overhead if we have many small Metaspaces I think. /Mikael > > Jon > > On 10/8/2012 7:57 AM, Mikael Gerdin wrote: >> Jon, >> >> On 2012-10-06 00:12, Jon Masamitsu wrote: >>> 7186847: NPG: Use large pages for metadata allocations >>> >>> http://cr.openjdk.java.net/~jmasa/7186847/webrev.00/ >> >> The fix makes sense, but I wonder how many of the allocations coming >> in through the VirtualSpaceNode constructor are large enough to make >> use of >4K pages? >> Since medium chunks are 8K words it looks like only humongous >> allocations will cause large pages to be allocated. Are humongous >> metaspace allocations even common enough to warrant the increased >> "complexity" of the code? >> I'm not saying that your fix is making the code itself more complex, >> but it may be misleading people reading it into thinking that large >> page size allocations are being used when actually they are not. >> >> /Mikael >> >>> >>> Thanks. >>> >>> Jon >> -- Mikael Gerdin Java SE VM SQE Stockholm From jon.masamitsu at oracle.com Tue Oct 9 15:26:29 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 09 Oct 2012 08:26:29 -0700 Subject: Request for review (1 line) - 7186847 In-Reply-To: <5073E0BB.9090100@oracle.com> References: <506F5B68.2020306@oracle.com> <5072E9EE.8050203@oracle.com> <5073896F.3030308@oracle.com> <5073E0BB.9090100@oracle.com> Message-ID: <50744225.2030401@oracle.com> On 10/09/12 01:30, Mikael Gerdin wrote: > Jon, > > On 2012-10-09 04:18, Jon Masamitsu wrote: >> Mikael, >> >> Thanks for the review. >> >> I expect VirtualSpaceNodes to grow >> by VirtualSpaceSize which is 256k and >> and that's where the use of large pages >> will have an affect. The Metachunks are >> allocated out of the space in a >> VirtualSpaceNode (the large VirtualSpaceNode >> are divided up into chunks). At least that's >> what I'm expecting. > > I guess the only "large" page size which we'll use is 64K pages on > sparc then. On x86 there's only 4K and 2M. > On sparc there's also 512K, 4M and even larger, but with 256K as the > largest page allocation block we'll not use them I think. The size of the space reserved for a VirtualSpaceNode is page aligned so however large VirtualSpaceSize is, we'll get at least 1 page (however large they are). But getting 1 large page is not optimal so I think I need to increase VirtualSpaceSize. > > >> >> VirtualSpaceSize are actually smaller that >> I thought they were so maybe those should >> be large. At least for 64bit. > > Chunks and VirtualSpaceNodes are shared between Metaspaces right? > So increasing the VirtualSpaceSize to something like 2M or 4M will not > increase memory overhead if we have many small Metaspaces I think. Right, they are shared. Having VirtualSpaceSize 2M or 4M should work fine but also something like 16M should be OK. That reserved 16M for the VirtualSpaceNodes but the space is only committed when a Metachunk is allocated. We'll, we do reserve 16M of address space so maybe it isn't completely harmless. Jon > > /Mikael > >> >> Jon >> >> On 10/8/2012 7:57 AM, Mikael Gerdin wrote: >>> Jon, >>> >>> On 2012-10-06 00:12, Jon Masamitsu wrote: >>>> 7186847: NPG: Use large pages for metadata allocations >>>> >>>> http://cr.openjdk.java.net/~jmasa/7186847/webrev.00/ >>> >>> The fix makes sense, but I wonder how many of the allocations coming >>> in through the VirtualSpaceNode constructor are large enough to make >>> use of >4K pages? >>> Since medium chunks are 8K words it looks like only humongous >>> allocations will cause large pages to be allocated. Are humongous >>> metaspace allocations even common enough to warrant the increased >>> "complexity" of the code? >>> I'm not saying that your fix is making the code itself more complex, >>> but it may be misleading people reading it into thinking that large >>> page size allocations are being used when actually they are not. >>> >>> /Mikael >>> >>>> >>>> Thanks. >>>> >>>> Jon >>> > From John.Coomes at oracle.com Tue Oct 9 19:07:08 2012 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 9 Oct 2012 12:07:08 -0700 Subject: Request for review (1 line) - 7186847 In-Reply-To: <506F5B68.2020306@oracle.com> References: <506F5B68.2020306@oracle.com> Message-ID: <20596.30172.957354.959832@oracle.com> Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > 7186847: NPG: Use large pages for metadata allocations > > http://cr.openjdk.java.net/~jmasa/7186847/webrev.00/ The change shouldn't be necessary. On platforms where shared memory is used for large pages (Windows, old Linux), that will cause shared memory to be used, and these sizes are not big enough to justify it. On platforms which do not use shared memory, you should get large pages with the original code as long as your space is big enough to take advantage of them. Easiest to check this on sparc, where a number of different large page sizes are available. Stop in VirtualSpace::initialize() when _middle_alignment is set. -John From stefan.karlsson at oracle.com Wed Oct 10 21:31:50 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Wed, 10 Oct 2012 21:31:50 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn Message-ID: <20121010213154.ACECB47296@hg.openjdk.java.net> Changeset: dd2b66d09ccd Author: stefank Date: 2012-10-09 22:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dd2b66d09ccd 8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled. Reviewed-by: kamg, coleenp ! src/share/vm/classfile/systemDictionary.cpp From john.cuthbertson at oracle.com Thu Oct 11 17:37:06 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 11 Oct 2012 10:37:06 -0700 Subject: RFR(M): 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack In-Reply-To: <506B6E73.10406@oracle.com> References: <506B6E73.10406@oracle.com> Message-ID: <507703C2.8090107@oracle.com> Hi Everyone, I have a new webrev based upon comments and observations from Jon Masamitsu and Peter Kessler which can be found at: http://cr.openjdk.java.net/~johnc/8000244/webrev.1/ Thanks, JohnC On 10/02/12 15:45, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the change for this CR - the > webrev can be found at: > http://cr.openjdk.java.net/~johnc/8000244/webrev.0/ > > Summary: > In response code review comments from Bengt for CR 7188263, I decided > to deal with the marking stack in its own CR - these are those changes. > > The allocation of G1's global marking stack now matches that of CMS > and is allocated from virtual memory instead of C heap. Further the > size of the marking stack has been changed from a fixed > 128*TASKQUEUE_SIZE (16M entry capacity in a 64 bit JVM), which is the > equivalent of the task queues of 128 threads, to a value based upon > the actual number of parallel marking threads - with a suitable > default minimum (4M entry capacity in a 64 bit JVM). The 4M entry > capacity is the equivalent of the task queues for 32 threads. I have > also mimicked CMS and added code to expand the marking stack in the > event that concurrent marking is aborted and restarted due to > overflowing the stack. The default maximum was the previous fixed > value (128*TASKQUEUE_SIZE). Hence we go a maximum of 2 expansions > before we have a marking stack sized as it was previously. > Additionally I have rearranged (some of) the ConcurrentMark > initialization code to (hopefully) make it a bit more robust w.r.t. > allocation failures. > > This CR does not address the allocation of the liveness accounting > data structures - those will be handled as 7188263. > > Testing: > * command line testing with some instrumentation > * GC test suite with a low IHOP, heap and marking verification, and > forced marking overflows (and instrumentation) > * GC test suite (normal) > * jprt > * refworkload (I didn't see any overflows in my runs, with an 8Gb > heap, but it could happen). > > Thanks, > > JohnC From john.coomes at oracle.com Thu Oct 11 21:17:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 21:17:23 +0000 Subject: hg: hsx/hotspot-gc: 4 new changesets Message-ID: <20121011211724.0F7DD472E0@hg.openjdk.java.net> Changeset: dae9821589cc Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/dae9821589cc Added tag jdk8-b58 for changeset 936702480487 ! .hgtags Changeset: b9d574659206 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b9d574659206 Added tag jdk8-b59 for changeset dae9821589cc ! .hgtags Changeset: 4b54d77a6831 Author: dholmes Date: 2012-10-09 02:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/4b54d77a6831 8000461: Top level build doesn't pass OPENJDK=true through to the hotspot build Summary: Add OPENJDK to the COMMON_BUILD_ARGUMENTS Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: e07f499b9dcc Author: katleman Date: 2012-10-10 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/e07f499b9dcc Merge From john.coomes at oracle.com Thu Oct 11 21:17:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 21:17:27 +0000 Subject: hg: hsx/hotspot-gc/corba: 2 new changesets Message-ID: <20121011211729.F384B472E1@hg.openjdk.java.net> Changeset: d54dc53e223e Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/d54dc53e223e Added tag jdk8-b58 for changeset 18462a19f7bd ! .hgtags Changeset: 207ef43ba69e Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/207ef43ba69e Added tag jdk8-b59 for changeset d54dc53e223e ! .hgtags From john.coomes at oracle.com Thu Oct 11 21:17:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 21:17:35 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 2 new changesets Message-ID: <20121011211744.A9641472E2@hg.openjdk.java.net> Changeset: af9e8b0f1900 Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/af9e8b0f1900 Added tag jdk8-b58 for changeset 1cb19abb3f7b ! .hgtags Changeset: 2d1dff5310da Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/2d1dff5310da Added tag jdk8-b59 for changeset af9e8b0f1900 ! .hgtags From john.coomes at oracle.com Thu Oct 11 21:17:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 21:17:49 +0000 Subject: hg: hsx/hotspot-gc/jaxws: 2 new changesets Message-ID: <20121011211755.E4510472E3@hg.openjdk.java.net> Changeset: ae107401be11 Author: katleman Date: 2012-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/ae107401be11 Added tag jdk8-b58 for changeset cac4c3937063 ! .hgtags Changeset: 5c5a65ad5291 Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/5c5a65ad5291 Added tag jdk8-b59 for changeset ae107401be11 ! .hgtags From john.coomes at oracle.com Thu Oct 11 21:19:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 21:19:54 +0000 Subject: hg: hsx/hotspot-gc/jdk: 64 new changesets Message-ID: <20121011214047.C8861472E4@hg.openjdk.java.net> Changeset: 8a64eeca4450 Author: jgodinez Date: 2012-09-10 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8a64eeca4450 7183516: [macosx]Can't print-out the defined fonts for PrintFont_2D and AntialiasTableTest. Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: db828a233f20 Author: bae Date: 2012-09-11 13:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/db828a233f20 7181199: [macosx] Startup is much slower in headless mode for apps using Fonts Reviewed-by: jgodinez, prr ! src/macosx/classes/sun/font/CFontManager.java Changeset: bce9611f1e8f Author: lana Date: 2012-09-14 13:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bce9611f1e8f Merge ! src/macosx/native/sun/awt/CTextPipe.m Changeset: 0ecf1a700fca Author: bae Date: 2012-09-17 13:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0ecf1a700fca 7186799: Regression tests for ImageIO metadata fail on second run Reviewed-by: prr, bae Contributed-by: Vadim Pakhnushev ! test/javax/imageio/metadata/BooleanAttributes.java ! test/javax/imageio/metadata/DOML3Node.java + test/javax/imageio/metadata/GetChildNames.java + test/javax/imageio/metadata/GetObjectMinValue.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatTest.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatThreadTest.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataTest.java + test/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java + test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatTest.sh + test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatThreadTest.sh + test/javax/imageio/metadata/IIOMetadataFormatImplTest.java + test/javax/imageio/metadata/MetadataFormatPrinter.java + test/javax/imageio/metadata/ObjectArrayMaxLength.java + test/javax/imageio/metadata/RegisteredFormatsTest.java + test/javax/imageio/metadata/RemoveElement.java + test/javax/imageio/metadata/SetAttributeNode.java Changeset: 47442b1b01eb Author: kizune Date: 2012-09-06 14:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/47442b1b01eb 7175183: [macosx] Objective-C exception thrown when switching monitor configuration Reviewed-by: prr, serb ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java Changeset: d14dc0ae1c2c Author: bagiras Date: 2012-09-06 17:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d14dc0ae1c2c 7153339: InternalError when drawLine with Xor and Antialiasing Reviewed-by: prr, flar ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: b8a1ff892b33 Author: alexsch Date: 2012-09-07 13:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b8a1ff892b33 7194469: Pressing the Enter key results in an alert tone beep when focus is TextField Reviewed-by: bagiras, denis ! src/windows/native/sun/windows/awt_TextField.cpp Changeset: 04292c0c943b Author: malenkov Date: 2012-09-11 10:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/04292c0c943b 7193977: REGRESSION:Java 7's JavaBeans persistence ignoring the "transient" flag on properties Reviewed-by: rupashka ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7193977.java Changeset: 3a2f5544dd00 Author: serb Date: 2012-09-12 21:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3a2f5544dd00 7124534: [macosx] Submenu title overlaps with Submenu indicator in JPopupMenu Reviewed-by: art + test/javax/swing/JMenuItem/6438430/bug6438430.java Changeset: aa35dc4d3f70 Author: bagiras Date: 2012-09-13 19:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/aa35dc4d3f70 7186109: Simplify lock machinery for PostEventQueue & EventQueue Reviewed-by: art, anthony, dholmes ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java Changeset: 5b7ad5bedbd7 Author: bagiras Date: 2012-09-13 21:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5b7ad5bedbd7 7198318: SunToolkitSubclass.java should be removed Reviewed-by: serb - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 5444be588d18 Author: alexsch Date: 2012-09-14 15:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5444be588d18 7197320: [macosx] Full Screen option missing when Window.documentModified Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 77fdcd3df205 Author: alexsch Date: 2012-09-14 15:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77fdcd3df205 7196547: [macosx] Implement dead key detection for KeyEvent Reviewed-by: skovatch, kizune ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java Changeset: 1785f8335f4d Author: VKARNAUK Date: 2012-09-14 19:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1785f8335f4d 6994562: Swing classes (both JTextArea and JTextField) don't support caret width tuning Reviewed-by: rupashka, art ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.h Changeset: b6ad3339f3f4 Author: lana Date: 2012-09-14 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b6ad3339f3f4 Merge Changeset: 1ed7fec79bee Author: leonidr Date: 2012-09-17 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ed7fec79bee 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb Contributed-by: Marco Dinacci ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/DnDUtilities.h ! src/macosx/native/sun/awt/DnDUtilities.m Changeset: 1d1254af05dd Author: kshefov Date: 2012-09-18 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1d1254af05dd 7190587: Open source and jtreg'ify JAWT regression test Reviewed-by: anthony, omajid + test/java/awt/JAWT/JAWT.sh + test/java/awt/JAWT/Makefile.cygwin + test/java/awt/JAWT/Makefile.unix + test/java/awt/JAWT/Makefile.win + test/java/awt/JAWT/MyCanvas.java + test/java/awt/JAWT/myfile.c + test/java/awt/JAWT/myfile.cpp Changeset: a96f5b1d03f9 Author: lana Date: 2012-09-19 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a96f5b1d03f9 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 076d0dafea5f Author: mgerdin Date: 2012-09-06 14:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/076d0dafea5f 7195557: NPG: Unexpected number of memory pools Summary: Update management tests to work with a VM without a permanent generation memory pool Reviewed-by: rbackman, brutisso, sla, dholmes ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java Changeset: 8c6895afe204 Author: lancea Date: 2012-09-06 13:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8c6895afe204 7192302: Remove JDBCRowSetImpl dependency on java.beans Reviewed-by: alanb, mchung ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java Changeset: 833f4630f3a1 Author: weijun Date: 2012-09-07 10:24 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/833f4630f3a1 7196677: diff compares same file to itself in PaddingTest regression test. Reviewed-by: xuelei ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java Changeset: d5d24c08f0dc Author: chegar Date: 2012-09-07 14:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d5d24c08f0dc 7032247: java/net/InetAddress/GetLocalHostWithSM.java fails if hostname resolves to loopback address Summary: TESTBUG Reviewed-by: chegar, alanb Contributed-by: Eric Wang ! test/java/net/InetAddress/GetLocalHostWithSM.java Changeset: 3857114d8255 Author: chegar Date: 2012-09-07 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3857114d8255 6354758: rename old test HttpServer classes Reviewed-by: chegar, michaelm, khazra Contributed-by: John Zavgren ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URLConnection/B5052093.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/KeepAliveCache/B5045306.java - test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/httptest/HttpTransaction.java + test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java + test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 7f081e14364e Author: mullan Date: 2012-09-07 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7f081e14364e 4647343: IDENT variable in sun.security.x509 classes not used Reviewed-by: mullan Contributed-by: jason.uh at oracle.com - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java Changeset: fffbb33df102 Author: coffeys Date: 2012-09-07 21:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fffbb33df102 7180362: RFE: Implement date cutover functionality for currency.properties file Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Currency/currency.properties Changeset: a51f86e2dce9 Author: mullan Date: 2012-09-10 08:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a51f86e2dce9 7195301: XML Signature DOM implementation should not use instanceof to determine type of Node Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java Changeset: a14d41fd6f51 Author: mullan Date: 2012-09-10 09:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a14d41fd6f51 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 657f7cb0da7e Author: mullan Date: 2012-09-10 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/657f7cb0da7e Merge Changeset: 2598dad44449 Author: dsamersoff Date: 2012-09-11 19:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2598dad44449 7194597: Typeo in com.sun.management.VMOption.toString() Summary: VMOption.toString() returns "...(read-only)" if writable "...(read-write)" otherwise. Reviewed-by: alanb, mchung Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/management/VMOption.java Changeset: 1f7c783e4f13 Author: dxu Date: 2012-08-31 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1f7c783e4f13 7193406: Clean-up JDK Build Warnings in java.util, java.io Summary: Clean-up JDK Build Warnings in java.util, java.io Packages Reviewed-by: smarks, darcy, khazra, dholmes, forax, dl, andrew, aph, omajid, ulfzibis, christos, mduigou ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/sun/util/PreHashedMap.java Changeset: 7a16cd3bd2d9 Author: mullan Date: 2012-09-12 15:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7a16cd3bd2d9 7196593: java.security.debug=help doesn't list certpath option Reviewed-by: mullan, wetmore, valeriep Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/util/Debug.java Changeset: f8c1cf072ba6 Author: mullan Date: 2012-09-12 15:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f8c1cf072ba6 Merge Changeset: e095be3820ee Author: chegar Date: 2012-09-13 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e095be3820ee 7197203: sun/misc/URLClassPath/ClassnameCharTest.sh failed, compile error Reviewed-by: alanb ! test/sun/misc/URLClassPath/ClassnameCharTest.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: e8a3807de977 Author: alanb Date: 2012-09-13 15:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e8a3807de977 7197637: (ch) sun.nio.ch.Default* cause providers for other platforms to be included in rt.jar Reviewed-by: mchung ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java Changeset: eae1384cff39 Author: mullan Date: 2012-09-14 10:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eae1384cff39 7176627: CertPath/jep124/PreferCRL_SoftFail test fails (Could not determine revocation status) Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java Changeset: 34bcbb110bb0 Author: mullan Date: 2012-09-14 10:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/34bcbb110bb0 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: c11cec5a9306 Author: mullan Date: 2012-09-14 10:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c11cec5a9306 Merge - test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: 22d7a9f73a59 Author: mchung Date: 2012-09-14 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/22d7a9f73a59 7193302: Remove ConstructorProperties annotation from java.lang.management.LockInfo Reviewed-by: alanb, sla, egahlin ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ThreadInfo.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java + src/share/classes/sun/management/LockInfoCompositeData.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Changeset: 356ff53c9b6d Author: lana Date: 2012-09-14 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/356ff53c9b6d Merge - test/java/lang/invoke/MaxTest.java Changeset: 92f3cda88d8e Author: mduigou Date: 2012-09-11 07:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/92f3cda88d8e 7189926: Reduce test size for default run. Add additional run enabling alternative hashing. Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: 17881ebf811c Author: mullan Date: 2012-09-16 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/17881ebf811c 7195409: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest fails with NullPointerException Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 0c3b0a82c4fc Author: weijun Date: 2012-09-17 17:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0c3b0a82c4fc 7198205: CloseTest fails on mac Reviewed-by: alanb, chegar, michaelm ! test/ProblemList.txt ! test/java/net/URLClassLoader/closetest/CloseTest.java Changeset: 39e97f68fa8c Author: sla Date: 2012-09-17 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/39e97f68fa8c 7198846: Add javax/management/remote/mandatory/notif/DiffHBTest.java to ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt Changeset: f56f85040c58 Author: weijun Date: 2012-09-17 18:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f56f85040c58 7196855: autotest.sh fails on ubuntu because libsoftokn.so not found Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 8a454e92aaf1 Author: sla Date: 2012-09-17 12:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8a454e92aaf1 7198849: Make javax/management/remote/mandatory/notif/ListenerScaleTest.java less timing sensitive Reviewed-by: alanb ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java Changeset: e20a2e6a92f7 Author: mduigou Date: 2012-09-17 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e20a2e6a92f7 7198988: re-order paramaters for Collision.java @run Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: 53ca38f76eaa Author: weijun Date: 2012-09-18 17:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/53ca38f76eaa 7198871: cleanup security tests in problem lists with no CR attached Reviewed-by: alanb ! test/ProblemList.txt Changeset: 95a93f039e5c Author: vinnie Date: 2012-09-18 11:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/95a93f039e5c 7198901: correct the field size check when decoding a point on ECC curve Reviewed-by: xuelei ! src/share/classes/sun/security/ec/ECParameters.java Changeset: bc5e7ec12717 Author: dxu Date: 2012-09-18 13:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc5e7ec12717 7142919: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing intermittently [sol11] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 88a4f699d233 Author: xuelei Date: 2012-09-18 06:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/88a4f699d233 7199066: Typo in method name Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 0136fca60652 Author: naoto Date: 2012-09-18 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0136fca60652 7198984: Add java/text/Bidi/Bug6665028.java to ProblemList.txt Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/ProblemList.txt Changeset: e7add6d98729 Author: mduigou Date: 2012-09-18 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e7add6d98729 7199249: TEST_BUG : Add /othervm to Collisions.java @run main with -D definitions Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: db381a2c0083 Author: alanb Date: 2012-09-18 21:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/db381a2c0083 7190273: Deprecate com.sun.security.auth.callback.DialogCallbackHandler Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java Changeset: e143d8f8e477 Author: dxu Date: 2012-09-18 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e143d8f8e477 7195933: There is incorrect link to "Info-ZIP Application Note 970311" in doc page of Package java.util.zip Summary: Correct a java doc link in java.util.zip package page Reviewed-by: chegar, lancea, sherman Contributed-by: dan.xu at oracle.com ! src/share/classes/java/util/zip/package.html Changeset: 045a0962b430 Author: mchung Date: 2012-09-18 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/045a0962b430 7198070: Eliminate static dependency from JMX to java.beans.ConstructorProperties Reviewed-by: alanb ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java Changeset: 5d064862376d Author: jgish Date: 2012-09-19 08:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5d064862376d 4722265: (spec str) StringBuffer.ensureCapacity() should mention that capacity is mutable Summary: add usage note to AbstractStringBuilder ensureCapacity() Reviewed-by: mduigou, dholmes, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 27182d84a244 Author: chegar Date: 2012-09-19 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/27182d84a244 7199500: Minor typo in AbstractStringBuilder.java header Reviewed-by: coffeys ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 002717a1418f Author: lana Date: 2012-09-19 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/002717a1418f Merge - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 3f876919cd58 Author: lana Date: 2012-09-24 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3f876919cd58 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 4015dec20965 Author: amurillo Date: 2012-09-26 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4015dec20965 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! test/ProblemList.txt - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: c9568c94c4e7 Author: ohair Date: 2012-09-21 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c9568c94c4e7 7191703: jprt cannot build jdk on MacOSX. Reviewed-by: anthony ! make/common/shared/Defs.gmk ! make/java/jobjc/Makefile Changeset: d94613ac03d8 Author: katleman Date: 2012-09-26 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d94613ac03d8 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: abad1f417bd3 Author: katleman Date: 2012-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/abad1f417bd3 Added tag jdk8-b58 for changeset d94613ac03d8 ! .hgtags Changeset: cec8fa02f156 Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cec8fa02f156 Added tag jdk8-b59 for changeset abad1f417bd3 ! .hgtags From john.coomes at oracle.com Thu Oct 11 21:51:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 21:51:16 +0000 Subject: hg: hsx/hotspot-gc/langtools: 12 new changesets Message-ID: <20121011215236.0CF9C472E5@hg.openjdk.java.net> Changeset: 489905e5018e Author: jjg Date: 2012-09-07 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/489905e5018e 7186925: JavapTask passes null to java.io.Writer Reviewed-by: jjh ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T7186925.java Changeset: 324b98626f58 Author: jjg Date: 2012-09-07 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/324b98626f58 7196774: javac cannot be built with JDK 6 after 7151010 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java Changeset: 1a7c11b22192 Author: jjg Date: 2012-09-07 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1a7c11b22192 7196760: tree end positions incorrect after anno processing Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/api/EndPositions.java Changeset: fa85af323d97 Author: bpatel Date: 2012-09-08 22:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fa85af323d97 7180906: Javadoc tool does not apply parameter -nosince Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + test/com/sun/javadoc/testSinceTag/TestSinceTag.java + test/com/sun/javadoc/testSinceTag/pkg1/C1.java Changeset: b2064a216117 Author: bpatel Date: 2012-09-08 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b2064a216117 Merge Changeset: 30c36e23f154 Author: jjg Date: 2012-09-13 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/30c36e23f154 7177970: fix issues in langtools doc comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/javadoc/Doc.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Tag.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/util/TreeScanner.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/Name.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/tools/JavaCompiler.java Changeset: fabfd2710057 Author: ksrini Date: 2012-09-14 09:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fabfd2710057 7192073: (javac) minor refactoring of tree maker to help IDEs Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java Changeset: 8c3c714eb7de Author: lana Date: 2012-09-14 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8c3c714eb7de Merge Changeset: a433bd8f3ba9 Author: lana Date: 2012-09-14 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a433bd8f3ba9 Merge Changeset: 804a3fbc86e2 Author: lana Date: 2012-09-24 21:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/804a3fbc86e2 Merge Changeset: f299927fc316 Author: katleman Date: 2012-09-27 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f299927fc316 Added tag jdk8-b58 for changeset 804a3fbc86e2 ! .hgtags Changeset: 3d2b98ffcb53 Author: katleman Date: 2012-10-04 14:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3d2b98ffcb53 Added tag jdk8-b59 for changeset f299927fc316 ! .hgtags From john.coomes at oracle.com Fri Oct 12 04:14:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 04:14:54 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b60 for changeset e07f499b9dcc Message-ID: <20121012041454.526A447314@hg.openjdk.java.net> Changeset: 20ff117b5090 Author: katleman Date: 2012-10-11 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/20ff117b5090 Added tag jdk8-b60 for changeset e07f499b9dcc ! .hgtags From john.coomes at oracle.com Fri Oct 12 04:14:59 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 04:14:59 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b60 for changeset 207ef43ba69e Message-ID: <20121012041502.03DB047315@hg.openjdk.java.net> Changeset: 41bb9e606efd Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/41bb9e606efd Added tag jdk8-b60 for changeset 207ef43ba69e ! .hgtags From john.coomes at oracle.com Fri Oct 12 04:15:05 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 04:15:05 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b60 for changeset 2d1dff5310da Message-ID: <20121012041513.8008447316@hg.openjdk.java.net> Changeset: 6b1db0b41d2f Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/6b1db0b41d2f Added tag jdk8-b60 for changeset 2d1dff5310da ! .hgtags From john.coomes at oracle.com Fri Oct 12 04:15:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 04:15:17 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b60 for changeset 5c5a65ad5291 Message-ID: <20121012041523.690A147317@hg.openjdk.java.net> Changeset: 97e5e74e2a34 Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/97e5e74e2a34 Added tag jdk8-b60 for changeset 5c5a65ad5291 ! .hgtags From john.coomes at oracle.com Fri Oct 12 04:15:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 04:15:30 +0000 Subject: hg: hsx/hotspot-gc/jdk: Added tag jdk8-b60 for changeset cec8fa02f156 Message-ID: <20121012041605.AAB3F47318@hg.openjdk.java.net> Changeset: 869519bc17ce Author: katleman Date: 2012-10-11 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/869519bc17ce Added tag jdk8-b60 for changeset cec8fa02f156 ! .hgtags From john.coomes at oracle.com Fri Oct 12 04:22:24 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 04:22:24 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b60 for changeset 3d2b98ffcb53 Message-ID: <20121012042230.A26F647319@hg.openjdk.java.net> Changeset: 67f7408d935e Author: katleman Date: 2012-10-11 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/67f7408d935e Added tag jdk8-b60 for changeset 3d2b98ffcb53 ! .hgtags From bernd.eckenfels at googlemail.com Fri Oct 12 05:46:48 2012 From: bernd.eckenfels at googlemail.com (Bernd Eckenfels) Date: Fri, 12 Oct 2012 07:46:48 +0200 Subject: Add linebreak for CMS abort? Message-ID: Hello, what do you think, does it make sense to add a linebreak at the following aborted message for verboseGC? (timestamps truncated, system times removed). The " CMS: abort preclean due to time " has no timestamp and especially no linebreak at the end. 09:57:38.278: [GC [ParNew: 268442K->6031K(2516544K), 0.0096560 secs] 268442K->6031K(8108992K), 0.0097540 secs] 09:57:38.288: [GC [1 CMS-initial-mark: 0K(5592448K)] 50770K(8108992K), 0.0186090 secs] 09:57:38.349: [CMS-concurrent-mark: 0.011/0.041 secs] 09:57:38.380: [CMS-concurrent-preclean: 0.031/0.031 secs] CMS: abort preclean due to time 09:57:48.451: [CMS-concurrent-abortable-preclean: 9.189/10.071 secs] 09:57:48.452: [GC[YG occupancy: 789050 K (2516544 K)]2012-10-11T09:57:48.452-0800: [GC [ParNew: 789050K->48388K(2516544K), 0.0730430 secs] 789050K->54825K(8108992K), 0.0731570 secs] [Rescan (parallel) , 0.0166130 secs][weak refs processing, 0.0000180 secs][class unloading, 0.0147850 secs][scrub symbol & string tables, 0.0083180 secs] [1 CMS-remark: 6437K(5592448K)] 54825K(8108992K), 0.1143460 secs] 09:57:48.582: [CMS-concurrent-sweep: 0.009/0.015 secs] 09:57:48.643: [CMS-concurrent-reset: 0.060/0.062 secs] 09:58:08.776: [GC [ParNew: 2285316K->132294K(2516544K), 0.1732660 secs] 2291753K->188592K(8108992K), 0.1734070 secs] A second option to making this additional line fit into the line schema would be to actually add some statistics inside the record: old: CMS: abort preclean due to time 09:57:48.451: [CMS-concurrent-abortable-preclean: 9.189/10.071 secs] new1: 09:57:38.380: [CMS-concurrent-preclean: 0.031/0.031 secs] (09:57:48.451:) CMS: abort preclean due to time 09:57:48.451: [CMS-concurrent-abortable-preclean: 9.189/10.071 secs] new2: 09:57:38.380: [CMS-concurrent-preclean: 0.031/0.031 secs] 09:57:48.451: [CMS-concurrent-abortable-preclean-aborted: 9.189/10.071 secs] Greetings Bernd -- https://plus.google.com/u/1/108084227682171831683/about From bernd.eckenfels at googlemail.com Fri Oct 12 05:46:50 2012 From: bernd.eckenfels at googlemail.com (Bernd Eckenfels) Date: Fri, 12 Oct 2012 07:46:50 +0200 Subject: Add linebreak for CMS abort? Message-ID: Hello, what do you think, does it make sense to add a linebreak at the following aborted message for verboseGC? (timestamps truncated, system times removed). The " CMS: abort preclean due to time " has no timestamp and especially no linebreak at the end. 09:57:38.278: [GC [ParNew: 268442K->6031K(2516544K), 0.0096560 secs] 268442K->6031K(8108992K), 0.0097540 secs] 09:57:38.288: [GC [1 CMS-initial-mark: 0K(5592448K)] 50770K(8108992K), 0.0186090 secs] 09:57:38.349: [CMS-concurrent-mark: 0.011/0.041 secs] 09:57:38.380: [CMS-concurrent-preclean: 0.031/0.031 secs] CMS: abort preclean due to time 09:57:48.451: [CMS-concurrent-abortable-preclean: 9.189/10.071 secs] 09:57:48.452: [GC[YG occupancy: 789050 K (2516544 K)]2012-10-11T09:57:48.452-0800: [GC [ParNew: 789050K->48388K(2516544K), 0.0730430 secs] 789050K->54825K(8108992K), 0.0731570 secs] [Rescan (parallel) , 0.0166130 secs][weak refs processing, 0.0000180 secs][class unloading, 0.0147850 secs][scrub symbol & string tables, 0.0083180 secs] [1 CMS-remark: 6437K(5592448K)] 54825K(8108992K), 0.1143460 secs] 09:57:48.582: [CMS-concurrent-sweep: 0.009/0.015 secs] 09:57:48.643: [CMS-concurrent-reset: 0.060/0.062 secs] 09:58:08.776: [GC [ParNew: 2285316K->132294K(2516544K), 0.1732660 secs] 2291753K->188592K(8108992K), 0.1734070 secs] A second option to making this additional line fit into the line schema would be to actually add some statistics inside the record: old: CMS: abort preclean due to time 09:57:48.451: [CMS-concurrent-abortable-preclean: 9.189/10.071 secs] new1: 09:57:38.380: [CMS-concurrent-preclean: 0.031/0.031 secs] (09:57:48.451:) CMS: abort preclean due to time 09:57:48.451: [CMS-concurrent-abortable-preclean: 9.189/10.071 secs] new2: 09:57:38.380: [CMS-concurrent-preclean: 0.031/0.031 secs] 09:57:48.451: [CMS-concurrent-abortable-preclean-aborted: 9.189/10.071 secs] Greetings Bernd -- https://plus.google.com/u/1/108084227682171831683/about From john.cuthbertson at oracle.com Fri Oct 12 23:22:08 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 12 Oct 2012 16:22:08 -0700 Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete Message-ID: <5078A620.3070306@oracle.com> Sending to the correct alias.... Hi Everyone, Can I have a couple of volunteers review the fix for this CR - the webrev can be found at: http://cr.openjdk.java.net/~johnc/8000831/webrev.0/ Summary: An earlier change inadvertently turned off part of the output of heap verification: [Verifying threads syms strs zone dict hand C-heap code cache ] VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)] 16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)] 17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)] 17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, real=0.06 secs] VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)] 17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)] 34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, real=0.09 secs] VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)] 35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00, real=0.03 secs] VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)] 69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11, real=0.20 secs] Previously it was: [Verifying threads syms strs zone dict hand C-heap code cache ] VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone dict hand C-heap code cache ] 4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K), 0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone dict hand C-heap code cache ] 5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K), 0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs] VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone dict hand C-heap code cache ] 5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K), 0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs zone dict hand C-heap code cache ] 5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K), 0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] The changes restore the previous output for the affected collectors. Testing: GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with serial, parallel, concurrent, and G1 collectors. Thanks, JohnC From bengt.rutisson at oracle.com Mon Oct 15 13:30:17 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Oct 2012 15:30:17 +0200 Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete In-Reply-To: <5078A620.3070306@oracle.com> References: <5078A620.3070306@oracle.com> Message-ID: <507C0FE9.2000803@oracle.com> Hi John, The changes look good to me. One kind of high level question. Why do we have a parameter and let every caller decide whether or not to print verbose output instead of having a flag to allow the user to turn it on and off on the command line? Seems more consistent with other log output to have a flag like PrintGCVerification or TraceGCVerification. A bit like the flag TraceProtectionDomainVerification does now. Bengt On 2012-10-13 01:22, John Cuthbertson wrote: > Sending to the correct alias.... > > Hi Everyone, > > Can I have a couple of volunteers review the fix for this CR - the > webrev can be found at: > http://cr.openjdk.java.net/~johnc/8000831/webrev.0/ > > Summary: > An earlier change inadvertently turned off part of the output of heap > verification: > > [Verifying threads syms strs zone dict hand C-heap code cache ] > VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)] > 16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, > real=0.02 secs] > VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)] > 17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, > real=0.01 secs] > VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)] > 17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, > real=0.06 secs] > VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)] > 17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, > real=0.02 secs] > VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)] > 34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, > real=0.09 secs] > VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)] > 35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00, > real=0.03 secs] > VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)] > 69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11, > real=0.20 secs] > > Previously it was: > > [Verifying threads syms strs zone dict hand C-heap code cache ] > VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs > zone dict hand C-heap code cache ] > 4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K), > 0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] > VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs > zone dict hand C-heap code cache ] > 5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K), > 0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs] > VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs > zone dict hand C-heap code cache ] > 5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K), > 0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] > VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs > zone dict hand C-heap code cache ] > 5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K), > 0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] > > The changes restore the previous output for the affected collectors. > > Testing: > GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with > serial, parallel, concurrent, and G1 collectors. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Mon Oct 15 16:26:14 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 15 Oct 2012 09:26:14 -0700 Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete In-Reply-To: <507C0FE9.2000803@oracle.com> References: <5078A620.3070306@oracle.com> <507C0FE9.2000803@oracle.com> Message-ID: <507C3926.5080208@oracle.com> Hi Bengt, Thanks for looking at the code. I honestly don't know the answer to your question. As I said in my earlier response to Ramki - I was surprised that all of the call sites were passing false for the silent parameter. I can't remember if that has always been the case. I'm also not sure if it always will be either. My guess is that no one thought of using a global flag, or if they did they reasoned that others may still want a finer grained control. Regards, JohnC On 10/15/12 06:30, Bengt Rutisson wrote: > Hi John, > > The changes look good to me. > > One kind of high level question. Why do we have a parameter and let > every caller decide whether or not to print verbose output instead of > having a flag to allow the user to turn it on and off on the command > line? Seems more consistent with other log output to have a flag like > PrintGCVerification or TraceGCVerification. A bit like the flag > TraceProtectionDomainVerification does now. > > Bengt > > On 2012-10-13 01:22, John Cuthbertson wrote: >> Sending to the correct alias.... >> >> Hi Everyone, >> >> Can I have a couple of volunteers review the fix for this CR - the >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8000831/webrev.0/ >> >> Summary: >> An earlier change inadvertently turned off part of the output of heap >> verification: >> >> [Verifying threads syms strs zone dict hand C-heap code cache ] >> VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)] >> 16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, >> real=0.02 secs] >> VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)] >> 17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, >> real=0.01 secs] >> VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)] >> 17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, >> real=0.06 secs] >> VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)] >> 17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, >> real=0.02 secs] >> VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)] >> 34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, >> real=0.09 secs] >> VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)] >> 35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00, >> real=0.03 secs] >> VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)] >> 69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11, >> real=0.20 secs] >> >> Previously it was: >> >> [Verifying threads syms strs zone dict hand C-heap code cache ] >> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >> zone dict hand C-heap code cache ] >> 4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K), >> 0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] >> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >> zone dict hand C-heap code cache ] >> 5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K), >> 0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs] >> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >> zone dict hand C-heap code cache ] >> 5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K), >> 0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] >> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >> zone dict hand C-heap code cache ] >> 5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K), >> 0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] >> >> The changes restore the previous output for the affected collectors. >> >> Testing: >> GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with >> serial, parallel, concurrent, and G1 collectors. >> >> Thanks, >> >> JohnC > From john.cuthbertson at oracle.com Mon Oct 15 20:06:29 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Mon, 15 Oct 2012 20:06:29 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000831: Heap verification output incorrect/incomplete Message-ID: <20121015200634.BA25A47385@hg.openjdk.java.net> Changeset: 4202510ee0fe Author: johnc Date: 2012-10-15 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4202510ee0fe 8000831: Heap verification output incorrect/incomplete Summary: Restore non-silent output of heap verification. Reviewed-by: ysr, brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/debug.cpp From bengt.rutisson at oracle.com Tue Oct 16 06:01:24 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Oct 2012 08:01:24 +0200 Subject: RFR(S): 8000831: Heap verification output incorrect/incomplete In-Reply-To: <507C3926.5080208@oracle.com> References: <5078A620.3070306@oracle.com> <507C0FE9.2000803@oracle.com> <507C3926.5080208@oracle.com> Message-ID: <507CF834.6040300@oracle.com> Hi John, On 2012-10-15 18:26, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking at the code. > > I honestly don't know the answer to your question. As I said in my > earlier response to Ramki - I was surprised that all of the call sites > were passing false for the silent parameter. I can't remember if that > has always been the case. I'm also not sure if it always will be > either. My guess is that no one thought of using a global flag, or if > they did they reasoned that others may still want a finer grained > control. OK. I was just wondering. I think your fix is fine for now. Bengt > > Regards, > > JohnC > > On 10/15/12 06:30, Bengt Rutisson wrote: > >> Hi John, >> >> The changes look good to me. >> >> One kind of high level question. Why do we have a parameter and let >> every caller decide whether or not to print verbose output instead of >> having a flag to allow the user to turn it on and off on the command >> line? Seems more consistent with other log output to have a flag like >> PrintGCVerification or TraceGCVerification. A bit like the flag >> TraceProtectionDomainVerification does now. >> >> Bengt >> >> On 2012-10-13 01:22, John Cuthbertson wrote: >>> Sending to the correct alias.... >>> >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review the fix for this CR - the >>> webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/8000831/webrev.0/ >>> >>> Summary: >>> An earlier change inadvertently turned off part of the output of >>> heap verification: >>> >>> [Verifying threads syms strs zone dict hand C-heap code cache ] >>> VerifyBeforeGC:4.619: [GC [PSYoungGen: 16896K->416K(19712K)] >>> 16896K->420K(62720K), 0.0170685 secs] [Times: user=0.02 sys=0.00, >>> real=0.02 secs] >>> VerifyBeforeGC:5.013: [GC [PSYoungGen: 17312K->416K(19712K)] >>> 17316K->424K(62720K), 0.0125283 secs] [Times: user=0.02 sys=0.00, >>> real=0.01 secs] >>> VerifyBeforeGC:5.239: [GC [PSYoungGen: 17312K->400K(19712K)] >>> 17320K->412K(62720K), 0.0586610 secs] [Times: user=0.04 sys=0.03, >>> real=0.06 secs] >>> VerifyBeforeGC:5.439: [GC [PSYoungGen: 17296K->432K(36608K)] >>> 17308K->448K(79616K), 0.0167533 secs] [Times: user=0.02 sys=0.00, >>> real=0.02 secs] >>> VerifyBeforeGC:5.721: [GC [PSYoungGen: 34224K->392K(38144K)] >>> 34240K->412K(81152K), 0.0909802 secs] [Times: user=0.05 sys=0.04, >>> real=0.09 secs] >>> VerifyBeforeGC:6.034: [GC [PSYoungGen: 35720K->400K(69184K)] >>> 35740K->424K(112192K), 0.0344226 secs] [Times: user=0.04 sys=0.00, >>> real=0.03 secs] >>> VerifyBeforeGC:6.709: [GC [PSYoungGen: 69136K->64K(69184K)] >>> 69160K->440K(112192K), 0.1976060 secs] [Times: user=0.10 sys=0.11, >>> real=0.20 secs] >>> >>> Previously it was: >>> >>> [Verifying threads syms strs zone dict hand C-heap code cache ] >>> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >>> zone dict hand C-heap code cache ] >>> 4.818: [GC [PSYoungGen: 16896K->392K(19712K)] 16896K->396K(62720K), >>> 0.0244147 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] >>> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >>> zone dict hand C-heap code cache ] >>> 5.087: [GC [PSYoungGen: 17288K->392K(19712K)] 17292K->400K(62720K), >>> 0.0597174 secs] [Times: user=0.04 sys=0.03, real=0.06 secs] >>> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >>> zone dict hand C-heap code cache ] >>> 5.410: [GC [PSYoungGen: 17288K->400K(19712K)] 17296K->412K(62720K), >>> 0.0173056 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] >>> VerifyBeforeGC:[Verifying threads permanent tenured eden syms strs >>> zone dict hand C-heap code cache ] >>> 5.595: [GC [PSYoungGen: 17296K->400K(36608K)] 17308K->416K(79616K), >>> 0.0134239 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] >>> >>> The changes restore the previous output for the affected collectors. >>> >>> Testing: >>> GCBasher with VerifyBeforeGC, VerifyAfterGC, VerifyDuringGC with >>> serial, parallel, concurrent, and G1 collectors. >>> >>> Thanks, >>> >>> JohnC >> > From jon.masamitsu at oracle.com Wed Oct 17 20:36:43 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 17 Oct 2012 13:36:43 -0700 Subject: Request for review (m) - 7054397 In-Reply-To: <505A902B.60103@oracle.com> References: <505A902B.60103@oracle.com> Message-ID: <507F16DB.1000708@oracle.com> I've updated the change based on some review comments. Specifically, moved code specific to CMS into files in gc_implementation/concurrentMarkSweep http://cr.openjdk.java.net/~jmasa/7045397/webrev.01/ On 9/19/2012 8:40 PM, Jon Masamitsu wrote: > This change continues the templatization of the CMS freelist for > more general use and uses the freelists for Metaspace chunks > and block (part of the perm removal implementation). > > http://cr.openjdk.java.net/~jmasa/7045397/webrev.00/ > > 7045397: Add freelists to class loader arenas. > > Continue the templatization of the CMS freelist for use with the > Metaspaces. > > Split functionality of FreeList between a simplified > FreeList and AdaptiveFreeList. AdaptiveFreeList is > specialized for use with CMS. > > Replace an interim freelist of humongous chunks with a > freelist dictionary. A linked list of humongous chunks had > been in use. > > Fix some spellings (e.g., totalSize to total_size). > > Delete the "splay" option that was never implemented. > > Move classes Metablock and Metachunk to metaspace.hpp so they > are available for explicit instantiations of some template classes. > From jon.masamitsu at oracle.com Thu Oct 18 04:20:50 2012 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 18 Oct 2012 04:20:50 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 32 new changesets Message-ID: <20121018042203.8224B47408@hg.openjdk.java.net> Changeset: d8ce2825b193 Author: coleenp Date: 2012-09-29 06:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d8ce2825b193 8000213: NPG: Should have renamed arrayKlass and typeArrayKlass Summary: Capitalize these metadata types (and objArrayKlass) Reviewed-by: stefank, twisti, kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciTypeArrayKlass.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/shark/sharkRuntime.cpp Changeset: fab6fbf427d2 Author: kevinw Date: 2012-09-30 23:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fab6fbf427d2 7200145: runtime/7196045/Test7196045.java fails with No class provided for `main' Reviewed-by: dholmes, dsamersoff ! test/runtime/7196045/Test7196045.java Changeset: ba8fd2fe198b Author: coleenp Date: 2012-10-04 08:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ba8fd2fe198b 7198519: Broken build, hotspot-rt win USE_PRECOMPILED_HEADER=0 Summary: Uncommented out include for sys/stat.h and deleted include statements that were commented out. Reviewed-by: coleenp, acorn, dholmes Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/jvm_windows.h Changeset: bacdc1d5c21c Author: coleenp Date: 2012-10-04 08:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bacdc1d5c21c 6884973: java -XX:Atomics=2 crashes Summary: Remove buggy experimental option Reviewed-by: acorn, coleenp Contributed-by: harold.seigel at oracle.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 48087f745a86 Author: dholmes Date: 2012-10-04 19:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/48087f745a86 7199186: runtime/7194254/Test7194254.java fails - wrong test name on @run Reviewed-by: kvn, twisti ! test/runtime/7194254/Test7194254.java Changeset: f2eb2d4488db Author: dholmes Date: 2012-10-04 20:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f2eb2d4488db Merge Changeset: 75982791ddb6 Author: coleenp Date: 2012-10-08 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/75982791ddb6 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field. Summary: Don't use HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N directly. Reviewed-by: coleenp, kamg, dholmes, sspitsyn Contributed-by: Mark Wielaard ! make/bsd/makefiles/buildtree.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/dtrace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/dtrace.hpp Changeset: 7a40901e0d5c Author: minqi Date: 2012-10-08 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7a40901e0d5c 8000332: SA ClassDump throws exception after permgen removal Summary: In ClassWrite.writeFields(), fields count was mistakenly set to fields length which overflow the array index. Also removed a file which is leftover from 6879063 changeset. Reviewed-by: coleenp, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/native/sadis.c Changeset: 0e8ca886e4e1 Author: minqi Date: 2012-10-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e8ca886e4e1 Merge Changeset: 6e5a59a8e4a7 Author: rbackman Date: 2012-10-09 07:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6e5a59a8e4a7 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26351ce8c4b0 Author: coleenp Date: 2012-10-09 02:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/26351ce8c4b0 8000622: Forgot to hg add and check in test for JDK-7170638 Summary: add the test Reviewed-by: coleenp, kamg Contributed-by: Mark Wielaard + test/serviceability/7170638/SDTProbesGNULinuxTest.sh Changeset: b9a9ed0f8eeb Author: mikael Date: 2012-10-09 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b9a9ed0f8eeb 7197424: update copyright year to match last edit in jdk8 hotspot repository Summary: Update copyright year to 2012 for relevant files Reviewed-by: dholmes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/bsd/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/ppc.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/windows/build.bat ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/hs_private.d ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/space.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/prims/jniExport.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder_elf.cpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/preserveException.cpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! test/compiler/6859338/Test6859338.java ! test/compiler/7116216/StackOverflow.java Changeset: c3e799c37717 Author: vlivanov Date: 2012-10-05 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3e799c37717 7177003: C1: LogCompilation support Summary: add LogCompilation support in C1 - both client and tiered mode. Reviewed-by: twisti, kvn ! src/os/linux/vm/vmError_linux.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 9a9b6e05ffb4 Author: vlivanov Date: 2012-10-05 19:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9a9b6e05ffb4 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. Reviewed-by: twisti, kvn ! src/share/vm/code/dependencies.cpp Changeset: 9024b6b53ec2 Author: vlivanov Date: 2012-10-05 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9024b6b53ec2 8000485: Hotspot build fails in Solaris Studio IDE when building dtrace Summary: Prepend '.' to the existing native library path Reviewed-by: kvn, sspitsyn ! make/bsd/makefiles/dtrace.make ! make/solaris/makefiles/dtrace.make Changeset: 377508648226 Author: vlivanov Date: 2012-10-08 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/377508648226 8000313: C2 should use jlong for 64bit values Summary: Replace all occurrences of long with jlong in C2 code. Reviewed-by: kvn, twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/phaseX.hpp Changeset: 65d07d9ee446 Author: twisti Date: 2012-10-08 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/65d07d9ee446 8000263: JSR 292: signature types may appear to be unloaded Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp Changeset: 8e47bac5643a Author: roland Date: 2012-10-09 10:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8e47bac5643a 7054512: Compress class pointers after perm gen removal Summary: support of compress class pointers in the compilers. Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java + agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/jhelper.d ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: f6badecb7ea7 Author: vlivanov Date: 2012-10-09 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f6badecb7ea7 7199654: Remove LoadUI2LNode Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead. Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp Changeset: d336b3173277 Author: kvn Date: 2012-10-09 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d336b3173277 8000592: Improve adlc usability Summary: several changes to adlc to improve its usability Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp Changeset: 94e9408dbf50 Author: roland Date: 2012-10-11 18:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/94e9408dbf50 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off. Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 19eb999cb72c Author: twisti Date: 2012-10-11 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/19eb999cb72c 8000740: remove LinkWellKnownClasses Reviewed-by: kvn, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: d804e148cff8 Author: kvn Date: 2012-10-12 09:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d804e148cff8 Merge ! make/bsd/makefiles/dtrace.make ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fb19af007ffc Author: jprovino Date: 2012-10-10 14:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fb19af007ffc 7189254: Change makefiles for more flexibility to override defaults Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles. Reviewed-by: dholmes, coleenp ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/ia64.make + make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/vm.make ! make/defs.make + make/excludeSrc.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/ia64.make + make/linux/makefiles/minimal1.make ! make/linux/makefiles/vm.make ! make/windows/makefiles/defs.make ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/runtimeService.hpp ! src/share/vm/utilities/macros.hpp Changeset: bbeecede56dd Author: jiangli Date: 2012-10-11 14:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bbeecede56dd 8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests. Summary: Remove unneeded assert. Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 9855b7e559ae Author: collins Date: 2012-10-12 10:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9855b7e559ae Merge ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/vm.make ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/management.cpp Changeset: 5876f980ea19 Author: collins Date: 2012-10-12 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5876f980ea19 Merge ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0cc77f9b31ad Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0cc77f9b31ad Added tag jdk8-b60 for changeset 3cfd05b2219a ! .hgtags Changeset: b261523fe66c Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b261523fe66c Merge Changeset: 4547dc71db76 Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4547dc71db76 Added tag hs25-b05 for changeset b261523fe66c ! .hgtags Changeset: 58fbf2da3c16 Author: amurillo Date: 2012-10-12 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/58fbf2da3c16 8000834: new hotspot build - hs25-b06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 633ba56cb013 Author: jmasa Date: 2012-10-17 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/633ba56cb013 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/memory/universe.hpp From mikael.gerdin at oracle.com Thu Oct 18 11:33:32 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 18 Oct 2012 13:33:32 +0200 Subject: RFR: 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java Message-ID: <507FE90C.2020508@oracle.com> Hi, In the Metaspace implementation that replaced perm gen for class meta data all allocations are made from "chunks". A ChunkManager is responsible for keeping track of all free chunks and currently there is a lot of verification of the free chunks by walking the linked lists that the free chunks are kept in. In a situation where we create a lot of class loaders we will force the ChunkManager to allocate a lot of small chunks, this increases the verification overhead in debug builds. This can cause tests to time out because the verification calls become very expensive with a lot of free chunks. We've never seen any of the free chunk verification asserts trigger so I propose that we disable the over-zealous verification and just add a verification call to Universe::verify to make it possible to turn on verification if needed. Webrev: http://cr.openjdk.java.net/~mgerdin/7200229 Buglink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200229 Thanks /Mikael -- Mikael Gerdin Java SE VM SQE Stockholm From john.coomes at oracle.com Fri Oct 19 04:33:22 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:33:22 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b61 for changeset 20ff117b5090 Message-ID: <20121019043322.CE49647442@hg.openjdk.java.net> Changeset: 8343ccdd63f1 Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8343ccdd63f1 Added tag jdk8-b61 for changeset 20ff117b5090 ! .hgtags From john.coomes at oracle.com Fri Oct 19 04:33:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:33:26 +0000 Subject: hg: hsx/hotspot-gc/corba: 4 new changesets Message-ID: <20121019043331.4358C47443@hg.openjdk.java.net> Changeset: 27d87f0031bf Author: alanb Date: 2012-10-05 15:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/27d87f0031bf 7195779: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently, NPE in tie class Reviewed-by: alanb, coffeys Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: d9c1dab1515b Author: lana Date: 2012-10-08 15:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/d9c1dab1515b Merge Changeset: 0e08ba7648fb Author: lana Date: 2012-10-11 16:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0e08ba7648fb Merge Changeset: 2394155f9f9e Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/2394155f9f9e Added tag jdk8-b61 for changeset 0e08ba7648fb ! .hgtags From john.coomes at oracle.com Fri Oct 19 04:33:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:33:35 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b61 for changeset 6b1db0b41d2f Message-ID: <20121019043343.DC88947444@hg.openjdk.java.net> Changeset: 5d0fa0108d02 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/5d0fa0108d02 Added tag jdk8-b61 for changeset 6b1db0b41d2f ! .hgtags From john.coomes at oracle.com Fri Oct 19 04:33:48 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:33:48 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b61 for changeset 97e5e74e2a34 Message-ID: <20121019043354.3CDF247445@hg.openjdk.java.net> Changeset: d265b9b4c0f5 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/d265b9b4c0f5 Added tag jdk8-b61 for changeset 97e5e74e2a34 ! .hgtags From john.coomes at oracle.com Fri Oct 19 04:35:01 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:35:01 +0000 Subject: hg: hsx/hotspot-gc/jdk: 51 new changesets Message-ID: <20121019044517.5807147446@hg.openjdk.java.net> Changeset: 4d8b411a2bc1 Author: jgodinez Date: 2012-09-25 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4d8b411a2bc1 7158350: [macosx] Strange results of SwingUIText printing Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: 5aff878baaf6 Author: lana Date: 2012-09-28 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5aff878baaf6 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 8dd4cae72975 Author: ceisserer Date: 2012-10-01 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8dd4cae72975 7188093: closed/sun/java2d/pipe/ScaleQualityTest.java fails Reviewed-by: prr, flar ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java Changeset: 89a1094e384f Author: bae Date: 2012-10-05 16:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/89a1094e384f 8000176: Need automated test for checking scale quality Reviewed-by: prr, bae Contributed-by: Vadim Pakhnushev + test/sun/java2d/pipe/InterpolationQualityTest.java Changeset: 2bc7669294cc Author: lana Date: 2012-10-08 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2bc7669294cc Merge Changeset: 9aa37a39cf39 Author: zhouyx Date: 2012-09-20 17:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9aa37a39cf39 7194184: JColorChooser swatch cannot accessed from keyboard Reviewed-by: rupashka, alexsch ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test7194184.java Changeset: 4f519691520c Author: vkarnauk Date: 2012-09-20 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4f519691520c 7123767: Wrong tooltip location in Multi-Monitor configurations Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java + test/javax/swing/ToolTipManager/7123767/bug7123767.java Changeset: adddc599e551 Author: alexsch Date: 2012-09-21 13:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/adddc599e551 7199180: [macosx] Dead keys handling for input methods Reviewed-by: kizune, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java Changeset: 88048b34405e Author: leonidr Date: 2012-09-24 15:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/88048b34405e 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper Reviewed-by: anthony ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m Changeset: d6cba7bfbb3d Author: leonidr Date: 2012-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d6cba7bfbb3d 7179349: [macosx] Java processes on Mac should not use default Apple icon Reviewed-by: anthony ! make/sun/osxapp/Makefile + make/sun/osxapp/ToBin.java ! src/macosx/native/sun/osxapp/NSApplicationAWT.m + src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns Changeset: 39227bb92978 Author: serb Date: 2012-09-24 21:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/39227bb92978 7160627: [macosx] TextArea has wrong initial size 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java + test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java + test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java Changeset: c8da47a4d441 Author: alexsch Date: 2012-09-26 18:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c8da47a4d441 7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Reviewed-by: serb, anthony + test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java Changeset: ad467dee852a Author: alexsch Date: 2012-09-28 14:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ad467dee852a 7197619: Using modifiers for the dead key detection on Windows Reviewed-by: bagiras, leonidr ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h Changeset: 4b8bb77fdda9 Author: lana Date: 2012-09-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4b8bb77fdda9 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 3ac112755bb5 Author: bagiras Date: 2012-10-03 21:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3ac112755bb5 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call Reviewed-by: art, denis ! src/macosx/native/sun/awt/InitIDs.m ! src/share/classes/java/awt/Choice.java ! src/solaris/native/sun/awt/initIDs.c ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h + test/java/awt/Choice/ItemStateChangeTest/ItemStateChangeTest.java Changeset: 27ee94051373 Author: lana Date: 2012-10-08 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/27ee94051373 Merge Changeset: f5229879ea40 Author: chegar Date: 2012-09-20 09:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f5229879ea40 7193520: Removed references to Linux kernel version 2.2 Summary: Linux kernel version 2.2 isn't supported anymore. Reviewed-by: chegar, dsamersoff, alanb Contributed-by: John Zavgren ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h Changeset: 3ad5464e7a21 Author: ksrini Date: 2012-09-20 13:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3ad5464e7a21 7199614: (pack200) remove unused file Reviewed-by: alanb - src/share/test/pack200/pack.conf Changeset: 3cfb621d5e7e Author: alanb Date: 2012-09-21 15:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3cfb621d5e7e 7199551: (bf) CharBuffer.append(CharSequence) throws BufferOverflowException for read-only buffer Reviewed-by: iris, dxu, chegar ! src/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java Changeset: f0aa997ad78b Author: valeriep Date: 2012-09-25 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f0aa997ad78b 7199941: test about AES/ECB mode fails Summary: Fixed the problem of field "blockMode" not having correct value for AES algorithms. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 4fcbddfd97f0 Author: valeriep Date: 2012-09-25 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4fcbddfd97f0 7199939: DSA 576 and 640 bit keys fail when initializing for No precomputed parameters Summary: Fixed initialize(int, SecureRandom) call to not error out when no precomputed params available. Reviewed-by: vinnie ! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java ! src/share/classes/sun/security/provider/DSAParameterGenerator.java ! src/share/classes/sun/security/provider/ParameterCache.java Changeset: a58585051c4b Author: xuelei Date: 2012-09-26 21:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a58585051c4b 7200295: CertificateRequest message is wrapping when using large numbers of Certs Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Record.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java Changeset: 790b81b631ba Author: alanb Date: 2012-09-27 10:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/790b81b631ba 7200742: (se) Selector.select does not block when starting Coherence (sol) Reviewed-by: chegar ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java + test/java/nio/channels/Selector/ChangingInterests.java Changeset: 9e879c0288c2 Author: andrew Date: 2012-09-27 17:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9e879c0288c2 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK. Summary: Allow OpenJDK to use the unlimited crypto policy. Reviewed-by: wetmore, ohair ! make/javax/crypto/Makefile Changeset: 11a5da68673c Author: robm Date: 2012-09-27 22:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/11a5da68673c 7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: b3c7a3138c5d Author: robm Date: 2012-09-28 04:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b3c7a3138c5d 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 7529cc41e637 Author: peytoia Date: 2012-09-28 14:14 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7529cc41e637 7069824: Support for BCP47 locale matching Reviewed-by: naoto, okutsu ! src/share/classes/java/util/Locale.java + src/share/classes/sun/util/locale/LocaleEquivalentMaps.java + src/share/classes/sun/util/locale/LocaleMatcher.java + test/java/util/Locale/Bug7069824.java + test/java/util/Locale/tools/EquivMapsGenerator.java + test/java/util/Locale/tools/language-subtag-registry.txt Changeset: 7e3ef09bb348 Author: weijun Date: 2012-09-28 17:15 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7e3ef09bb348 7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so Reviewed-by: alanb, smarks ! test/sun/security/tools/keytool/autotest.sh Changeset: b8e08f5d255a Author: dxu Date: 2012-09-28 11:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b8e08f5d255a 6950237: Test java/nio/file/Path/CopyAndMove.java does not work correctly when test dir in on VFAT Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! test/java/nio/file/Files/CopyAndMove.java Changeset: 77bf5cde2192 Author: lana Date: 2012-09-28 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77bf5cde2192 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 0c1c4b185451 Author: dsamersoff Date: 2012-09-29 15:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0c1c4b185451 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh Summary: Make test self-terminating and independent to cygwin/mks kill behaviour Reviewed-by: sspitsyn, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/management/jmxremote/startstop/REMOTE_TESTING.txt Changeset: 39cbe256c3d1 Author: alanb Date: 2012-10-01 15:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/39cbe256c3d1 8000269: Cleanup javadoc warnings Reviewed-by: lancea, darcy, ulfzibis, iris, naoto, dholmes ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/SimpleDateFormat.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/JapaneseImperialCalendar.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java Changeset: 75080f572f84 Author: olagneau Date: 2012-10-02 10:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/75080f572f84 7050528: Improve performance of java.text.DecimalFormat.format() call stack Reviewed-by: darcy ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/NumberFormat.java + test/java/text/Format/DecimalFormat/FormatMicroBenchmark.java + test/java/text/Format/DecimalFormat/GoldenDoubleValues.java + test/java/text/Format/DecimalFormat/GoldenFormattedValues.java + test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java Changeset: 041c687c4f40 Author: psandoz Date: 2012-10-02 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/041c687c4f40 7197642: (sl) ServiceLoader.load(null) doesn't throw NPE Reviewed-by: alanb ! src/share/classes/java/util/ServiceLoader.java + test/java/util/ServiceLoader/NPE.java Changeset: 6750ab947255 Author: alanb Date: 2012-10-02 12:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6750ab947255 8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit Reviewed-by: mullan ! test/sun/security/provider/X509Factory/BigCRL.java Changeset: 4744dc70e5d1 Author: peytoia Date: 2012-10-03 15:11 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4744dc70e5d1 7104012: AIOOBE from RuleBasedBreakIterator.lookupState for some suppl. chars Reviewed-by: okutsu ! src/share/classes/sun/text/SupplementaryCharacterData.java + test/java/text/BreakIterator/Bug7104012.java Changeset: 7fe88d457d85 Author: dxu Date: 2012-10-03 09:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7fe88d457d85 6910472: Typo in : java.io.ObjectOutputStream.reset() "refered" Reviewed-by: dholmes, alanb ! src/share/classes/java/io/ObjectOutputStream.java Changeset: 123db1c28d92 Author: peytoia Date: 2012-10-04 11:36 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/123db1c28d92 7196316: Wrong rounding mode in DecimalFormat after deserialization Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormat.java + test/java/text/Format/DecimalFormat/Bug7196316.java Changeset: 8692e14b8ea8 Author: peytoia Date: 2012-10-04 18:05 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8692e14b8ea8 7201151: Fix Contribution : Java cannot get Windows's IME name correctly Reviewed-by: okutsu ! src/windows/native/sun/windows/awt_InputMethod.cpp Changeset: 344f0acff085 Author: vinnie Date: 2012-02-14 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/344f0acff085 7133495: [macosx] KeyChain KeyStore implementation retrieves only one private key entry Reviewed-by: weijun ! src/macosx/native/apple/security/KeystoreImpl.m + test/sun/security/tools/keytool/ListKeychainStore.sh Changeset: 77af5b4ae4f0 Author: vinnie Date: 2012-10-04 11:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77af5b4ae4f0 Merge Changeset: c6a0b13e6efa Author: naoto Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c6a0b13e6efa 7196799: CLDR adapter can not be invoked when region code is specified in Locale 7197573: java/util/Locale/LocaleProviders.sh failed. Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: bba370caafad Author: robm Date: 2012-10-04 19:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bba370caafad 7184932: Remove the temporary Selector usage in the NIO socket adapters Reviewed-by: alanb ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/Net.c + test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java Changeset: cd4f181eb666 Author: naoto Date: 2012-10-04 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cd4f181eb666 7200119: Collator.getAvailableLocales() doesn't return Locale.US Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + test/java/text/Collator/Bug7200119.java Changeset: 647424d6cf65 Author: naoto Date: 2012-10-04 21:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/647424d6cf65 Merge Changeset: 88a726a5b2dc Author: naoto Date: 2012-10-05 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/88a726a5b2dc 7198834: HOST Adapter: one extra empty space in the end of the pattern string Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: f65871e75fde Author: alanb Date: 2012-10-06 13:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f65871e75fde 8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations Reviewed-by: mchung, forax ! make/java/java/FILES_java.gmk ! make/sun/util/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/sun/util/spi/XmlPropertiesProvider.java + src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider + src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java - src/share/classes/sun/util/xml/XMLUtils.java + test/java/util/Properties/CustomProvider.java + test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/MyXmlPropertiesProvider.java Changeset: 92f3a96f3c78 Author: weijun Date: 2012-10-08 10:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/92f3a96f3c78 7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java + test/sun/security/krb5/auto/UseCacheAndStoreKey.java Changeset: d8581143e11d Author: lana Date: 2012-10-08 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d8581143e11d Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: 61ddb3fd000a Author: lana Date: 2012-10-11 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/61ddb3fd000a Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: 1ae6420126af Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ae6420126af Added tag jdk8-b61 for changeset 61ddb3fd000a ! .hgtags From john.coomes at oracle.com Fri Oct 19 04:48:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:48:11 +0000 Subject: hg: hsx/hotspot-gc/langtools: 22 new changesets Message-ID: <20121019044901.97B1A47447@hg.openjdk.java.net> Changeset: 8987971bcb45 Author: jjg Date: 2012-09-24 14:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8987971bcb45 7196462: JavacProcessingEnvironment should tolerate BasicJavacTask Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/T7196462.java Changeset: 99983a4a593b Author: mcimadamore Date: 2012-09-25 11:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/99983a4a593b 7193913: Cleanup Resolve.findMethod Summary: Refactor method lookup logic in Resolve.findMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 26d93df3905a Author: mcimadamore Date: 2012-09-25 11:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/26d93df3905a 7194586: Add back-end support for invokedynamic Summary: Add support for invokedynamic bytecode instruction; includes suppot for generation of all related classfile attributes Reviewed-by: jjg ! 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/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/lambda/TestInvokeDynamic.java Changeset: 2eca84194807 Author: mcimadamore Date: 2012-09-25 11:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2eca84194807 7175433: Inference cleanup: add helper class to handle inference variables Summary: Add class to handle inference variables instantiation and associated info Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/inference/6638712/T6638712c.out + test/tools/javac/varargs/6313164/T7175433.java Changeset: ad2ca2a4ab5e Author: mcimadamore Date: 2012-09-25 11:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ad2ca2a4ab5e 7177306: Regression: unchecked method call does not erase return type Summary: Spurious extra call to Attr.checkMethod when method call is unchecked Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out + test/tools/javac/generics/inference/7177306/T7177306a.java + test/tools/javac/generics/inference/7177306/T7177306a.out + test/tools/javac/generics/inference/7177306/T7177306b.java + test/tools/javac/generics/inference/7177306/T7177306b.out + test/tools/javac/generics/inference/7177306/T7177306c.java + test/tools/javac/generics/inference/7177306/T7177306d.java + test/tools/javac/generics/inference/7177306/T7177306e.java + test/tools/javac/generics/inference/7177306/T7177306e.out Changeset: 0e5899f09dab Author: jjg Date: 2012-09-25 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0e5899f09dab 7193657: provide internal ArrayUtils class to simplify common usage of arrays in javac Reviewed-by: mcimadamore, jjg Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/javac/api/MultiTaskListener.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + src/share/classes/com/sun/tools/javac/util/ArrayUtils.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java Changeset: 99d23c0ef8ee Author: jjg Date: 2012-09-25 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/99d23c0ef8ee 7196464: upgrade JavaCompiler.shouldStopPolicy to accomodate policies in face of error and no error Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: db36841709e4 Author: mcimadamore Date: 2012-09-26 14:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/db36841709e4 7188968: New instance creation expression using diamond is checked twice Summary: Unify method and constructor check logic Reviewed-by: jjg ! 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/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/generics/diamond/7002837/T7002837.java + test/tools/javac/generics/diamond/7002837/T7002837.out + test/tools/javac/generics/diamond/7188968/T7188968.java + test/tools/javac/generics/diamond/7188968/T7188968.out ! test/tools/javac/positions/T6264029.out Changeset: 1a65d6565b45 Author: mcimadamore Date: 2012-09-28 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1a65d6565b45 8000233: Fix issues in recent push Summary: Forgot to incorporate review comments in pushed changesets Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: f1e6b361a329 Author: mcimadamore Date: 2012-09-28 18:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f1e6b361a329 8000241: langtools doesn't build Summary: bad merge with langtools tip caused build glitch Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: 73312ec2cf7c Author: jfranck Date: 2012-09-28 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/73312ec2cf7c 7199925: Separate compilation breaks check that elements have a default for the containing annotation Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: e77841f2c74b Author: lana Date: 2012-09-28 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e77841f2c74b Merge Changeset: 20e4a54b1629 Author: ksrini Date: 2012-09-29 09:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/20e4a54b1629 7198582: (java) Minor refactor of JavacParser Reviewed-by: jjg, ksrini Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java Changeset: 1408af4cd8b0 Author: mcimadamore Date: 2012-10-04 13:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1408af4cd8b0 7177387: Add target-typing support in method context Summary: Add support for deferred types and speculative attribution Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! 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/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/IncompatibleTypesInConditional.java + test/tools/javac/diags/examples/TypeConditional.java Changeset: 573ceb23beeb Author: mcimadamore Date: 2012-10-05 14:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/573ceb23beeb 7177385: Add attribution support for lambda expressions Summary: Add support for function descriptor lookup, functional interface inference and lambda expression type-checking Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! 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/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/6402516/TestLocalElements.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java + test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java + test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/CyclicInference.java + test/tools/javac/diags/examples/IncompatibleAbstracts.java + test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java + test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java + test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java + test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java + test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/MissingReturnValueFragment.java + test/tools/javac/diags/examples/NoAbstracts.java + test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java + test/tools/javac/diags/examples/NotAFunctionalIntf.java + test/tools/javac/diags/examples/PotentialLambdaFound.java - test/tools/javac/diags/examples/TypeConditional.java + test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: d604fd09480b Author: bpatel Date: 2012-10-05 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d604fd09480b 7132631: The help-doc.html generates an invalid link to constant-values.html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/testHelpFile/TestHelpFile.java Changeset: ef88ae455c88 Author: bpatel Date: 2012-10-05 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ef88ae455c88 7068595: html files in class-use dir do not get loaded correctly when Frames link is clicked Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: f4e45397722a Author: bpatel Date: 2012-10-05 14:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f4e45397722a 4696488: javadoc doesn't handle UNC paths for destination directory Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/tools/javadoc/T4696488.java Changeset: d4b3cb1ece84 Author: mcimadamore Date: 2012-10-06 10:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d4b3cb1ece84 7177386: Add attribution support for method references Summary: Add type-checking/lookup routines for method references Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! 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/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/T6326754.out ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAccessInnerClsConstr.java + test/tools/javac/diags/examples/CantApplySymbolFragment.java + test/tools/javac/diags/examples/CantApplySymbolsFragment.java + test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java + test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java ! test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java ! test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java + test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java + test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/InferArgsLengthMismatch.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToEq.java ! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/MethodReferencesNotSupported.java ! test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java + test/tools/javac/diags/examples/RefAmbiguousFragment.java + test/tools/javac/diags/examples/UnexpectedMref.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/7034511/T7034511a.out ! test/tools/javac/generics/7034511/T7034511b.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7177306/T7177306b.out ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out ! test/tools/javac/varargs/6313164/T6313164.out Changeset: aa3ef5c09b1b Author: lana Date: 2012-10-08 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/aa3ef5c09b1b Merge Changeset: 26020b247ad3 Author: lana Date: 2012-10-11 17:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/26020b247ad3 Merge Changeset: b47bb81ba962 Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b47bb81ba962 Added tag jdk8-b61 for changeset 26020b247ad3 ! .hgtags From csewhiz at zoho.com Fri Oct 19 05:13:04 2012 From: csewhiz at zoho.com (csewhiz) Date: Fri, 19 Oct 2012 10:43:04 +0530 Subject: Question regarding G1 option to run parallel Old generation garbage collection? Message-ID: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> Hello All, Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. Is there any parameter to force the old gc happening regularly. I am trying following setting, -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 If anyone can give insight on how full GC is triggred internals will be of great help. PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. Regards, Soumit -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 19 05:49:20 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 07:49:20 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> Message-ID: <54BC6D75-FB4F-48FE-A118-B530FC5A576E@kodewerk.com> Not sure what the G1 would do with an initiating occupancy value of 0. size_t marking_initiating_used_threshold = (_g1->capacity() / 100) * InitiatingHeapOccupancyPercent; I didn't dig much deeper into the code to see how 0 was handled. Regards, Kirk On 2012-10-19, at 7:13 AM, csewhiz wrote: > Hello All, > Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. > But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. > > Is there any parameter to force the old gc happening regularly. > > I am trying following setting, > > -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 > > If anyone can give insight on how full GC is triggred internals will be of great help. > > PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. > > > Regards, > Soumit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chunt at salesforce.com Fri Oct 19 12:25:11 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Fri, 19 Oct 2012 05:25:11 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> Message-ID: <10AFDC58-BC30-4CA2-B477-B437D6CB2FF4@salesforce.com> Quite honestly I would not recommend running G1 with a Java 6 JVM. It's not supported in Java 6. I'd move to a Java 7u4 or later JVM where it is supported, ideally Java 7u9. When you do move to 7u4 or later, suggest you start with these command line options: -Xmx1280M -Xms1280m -XX:+UseG1GC -XX:MaxGCPauseMillis=500 -XX:ParallelGCThreads=7 Using these command line options have implications: Sizing young gen (i.e. -XX:NewRatio) tells G1 to ignore the pause time goal. G1 will adaptively size young gen based on MaxGCPauseMillis. When you set NewRatio, you are telling G1 that you think you can do better. G1 also adaptively sizes survivor spaces based on MaxGCPauseMillis. So, don't set SurvivorRatio either. MaxTenuringThreshold defaults to 15. Also realize that InitiatingHeapOccupancyPercent is the entire heap occupancy, not old gen heap occupancy. At 0, you're suggesting to initiate a concurrent cycle immediately, and continuously run there afterwards. At a MaxGCPauseMillis=500 and a 1280M Java heap, I doubt you would need such an aggressive configuration. And, iirc, ConcGCThreads is not used by G1 GC, (could be wrong though). I'd start with the above suggested tuning on 7u4 or later, and then tune InitatingHeapOccupancyPercent as needed. hths, charlie ... On Oct 19, 2012, at 12:13 AM, csewhiz wrote: Hello All, Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. Is there any parameter to force the old gc happening regularly. I am trying following setting, -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 If anyone can give insight on how full GC is triggred internals will be of great help. PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. Regards, Soumit -------------- next part -------------- An HTML attachment was scrubbed... URL: From monica.beckwith at oracle.com Fri Oct 19 12:55:29 2012 From: monica.beckwith at oracle.com (Monica Beckwith) Date: Fri, 19 Oct 2012 07:55:29 -0500 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> Message-ID: <50814DC1.6010602@oracle.com> Couple of quick observations and questions - 1. G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) 2. What do you mean by old gen collection? Are you talking about MixedGCs? 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? 1. I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? -Monica On 10/19/2012 12:13 AM, csewhiz wrote: > Hello All, > Sorry for posting this question in this mailing list. I am unable to > find any answer for this. I am trying to tune our application for G1GC > as we need very small pauses Below 500msec. > But the problem is when we are runing with G1GC (under jdk 6_u37) > Old generation of garbage collection only happening when it is > reaching the Max GC size I noticed on jdk 6U 37 if max heap size is > 1GB then it is close to 1sec 2GB close to 2 sec pauses. > Is there any parameter to force the old gc happening regularly. > I am trying following setting, > -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 > -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 > -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 > -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 > If anyone can give insight on how full GC is triggred internals will > be of great help. > PS: I have tried without any option for G1 but not of much help hence > .. this one trying to be agressive ? but of not much help. > Regards, > Soumit > -- Oracle Monica Beckwith | Java Performance Engineer VOIP: +1 512 401 1274 Texas Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From kirk at kodewerk.com Fri Oct 19 17:58:10 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 19:58:10 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <50814DC1.6010602@oracle.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> Message-ID: <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> Hi Monica, Can you comment on what a value of 0 means? Regards, Kirk On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: > Couple of quick observations and questions - > G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) > What do you mean by old gen collection? Are you talking about MixedGCs? > Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? > I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? > -Monica > > > On 10/19/2012 12:13 AM, csewhiz wrote: >> >> Hello All, >> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >> >> Is there any parameter to force the old gc happening regularly. >> >> I am trying following setting, >> >> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >> >> If anyone can give insight on how full GC is triggred internals will be of great help. >> >> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >> >> >> Regards, >> Soumit >> > > -- > > Monica Beckwith | Java Performance Engineer > VOIP: +1 512 401 1274 > Texas > Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From monica.beckwith at oracle.com Fri Oct 19 18:29:38 2012 From: monica.beckwith at oracle.com (Monica Beckwith) Date: Fri, 19 Oct 2012 13:29:38 -0500 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> Message-ID: <50819C12.1060807@oracle.com> Hi Kirk - I see that Charlie has already answered that one. I'll just expand on that... Basically *any* value of InitiatingHeapOccupancyPercent is checked against the already allocated and current bytes. If the total bytes are greater than heap*IHOP/100 (since IHOP is expressed as a percent) and if young GC, then we start the concurrent cycle. If not then we are doing mixed GC. -Monica On 10/19/2012 12:58 PM, Kirk Pepperdine wrote: > Hi Monica, > > Can you comment on what a value of 0 means? > > Regards, > Kirk > > On 2012-10-19, at 2:55 PM, Monica Beckwith > wrote: > >> Couple of quick observations and questions - >> >> 1. G1 is officially supported in 7u4. (There are numerous >> performance improvements that I recommend updating to the latest >> jdk7 update, if possible) >> 2. What do you mean by old gen collection? Are you talking about >> MixedGCs? >> 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have >> you tried resizing your young generation? >> 1. I see the NewRatio, but that fixes the nursery to 640, >> instead have you tried with a lower (than the min default) of >> nursery using the NewSize option? >> >> -Monica >> >> >> >> On 10/19/2012 12:13 AM, csewhiz wrote: >>> Hello All, >>> Sorry for posting this question in this mailing list. I am unable >>> to find any answer for this. I am trying to tune our application for >>> G1GC as we need very small pauses Below 500msec. >>> But the problem is when we are runing with G1GC (under jdk 6_u37) >>> Old generation of garbage collection only happening when it is >>> reaching the Max GC size I noticed on jdk 6U 37 if max heap size is >>> 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>> Is there any parameter to force the old gc happening regularly. >>> I am trying following setting, >>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 >>> -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 >>> -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 >>> -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>> If anyone can give insight on how full GC is triggred internals will >>> be of great help. >>> PS: I have tried without any option for G1 but not of much help >>> hence .. this one trying to be agressive ? but of not much help. >>> Regards, >>> Soumit >>> >> >> -- >> >> Monica Beckwith | Java Performance Engineer >> VOIP: +1 512 401 1274 >> Texas >> Oracle >> is committed to developing practices and products that help protect >> the environment > -- Oracle Monica Beckwith | Java Performance Engineer VOIP: +1 512 401 1274 Texas Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From kirk at kodewerk.com Fri Oct 19 18:39:46 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 20:39:46 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <50819C12.1060807@oracle.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <50819C12.1060807@oracle.com> Message-ID: <72AA4C14-B7B2-4FC5-B01D-EB667CA7CBE8@kodewerk.com> On 2012-10-19, at 8:29 PM, Monica Beckwith wrote: > Hi Kirk - > > I see that Charlie has already answered that one. I'll just expand on that... Basically *any* value of InitiatingHeapOccupancyPercent is checked against the already allocated and current bytes. If the total bytes are greater than heap*IHOP/100 (since IHOP is expressed as a percent) and if young GC, then we start the concurrent cycle. If not then we are doing mixed GC. RIght, missed that last sentence in Charlie's explanation. Sorry Charlie.. my bad for skimming... I was thinking that 0 would be a sentinel or guarded against as it seems using a setting of 0 would seem to make no sense or have no supporting use case. -- Kirk From chunt at salesforce.com Fri Oct 19 18:56:16 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Fri, 19 Oct 2012 11:56:16 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> Message-ID: <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. charlie ... On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: Hi Monica, Can you comment on what a value of 0 means? Regards, Kirk On 2012-10-19, at 2:55 PM, Monica Beckwith > wrote: Couple of quick observations and questions - 1. G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) 2. What do you mean by old gen collection? Are you talking about MixedGCs? 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? * I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? -Monica On 10/19/2012 12:13 AM, csewhiz wrote: Hello All, Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. Is there any parameter to force the old gc happening regularly. I am trying following setting, -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 If anyone can give insight on how full GC is triggred internals will be of great help. PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. Regards, Soumit -- Monica Beckwith | Java Performance Engineer VOIP: +1 512 401 1274 Texas Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 19 19:16:50 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 21:16:50 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Message-ID: Thanks Charlie, I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. Again, I'm struggling to think of a use case for this behaviour. Regards, Kirk On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: > Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) > > A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: > - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails > - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle > * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. > - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. > > charlie ... > > On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: > >> Hi Monica, >> >> Can you comment on what a value of 0 means? >> >> Regards, >> Kirk >> >> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >> >>> Couple of quick observations and questions - >>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>> What do you mean by old gen collection? Are you talking about MixedGCs? >>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>> -Monica >>> >>> >>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>> >>>> Hello All, >>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>> >>>> Is there any parameter to force the old gc happening regularly. >>>> >>>> I am trying following setting, >>>> >>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>> >>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>> >>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>> >>>> >>>> Regards, >>>> Soumit >>>> >>> >>> -- >>> >>> Monica Beckwith | Java Performance Engineer >>> VOIP: +1 512 401 1274 >>> Texas >>> Oracle is committed to developing practices and products that help protect the environment >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Fri Oct 19 19:16:52 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 19 Oct 2012 12:16:52 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> Message-ID: <5081A724.80900@oracle.com> Hi Kirk, Apologies that I'm a bit late to this conversation. An IHOP value of 0 pretty much means you'll be doing almost continuous concurrent marking cycles - interspaced with an an occasional young GC and some mixed GCs. There are two places where we check whether we should initiate a marking cycle. One in when we allocate a humongous object (an object that is larger than 1/2 of a region and may span multiple regions): if the occupany of the heap plus the size of the object being allocated will go over the IHOP, we schedule a young collection with an initial mark piggy backed on top of it to start a marking cycle. The other place is at the end of a young GC, if the heap occupancy is more than the IHOP we indicate that the next young collection will have an initial mark piggy-backed, starting the marking cycle. I use an IHOP of 0, 1, 5, and 10 to stress concurrent marking while testing. :) I'm almost certain that this is not what Soumit intended. Regards, JohnC On 10/19/12 10:58, Kirk Pepperdine wrote: > Hi Monica, > > Can you comment on what a value of 0 means? > > Regards, > Kirk > > On 2012-10-19, at 2:55 PM, Monica Beckwith > wrote: > >> Couple of quick observations and questions - >> >> 1. G1 is officially supported in 7u4. (There are numerous >> performance improvements that I recommend updating to the >> latest jdk7 update, if possible) >> 2. What do you mean by old gen collection? Are you talking about >> MixedGCs? >> 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have >> you tried resizing your young generation? >> 1. I see the NewRatio, but that fixes the nursery to 640, >> instead have you tried with a lower (than the min >> default) of nursery using the NewSize option? >> >> -Monica >> >> >> >> On 10/19/2012 12:13 AM, csewhiz wrote: >>> Hello All, >>> Sorry for posting this question in this mailing list. I am unable >>> to find any answer for this. I am trying to tune our application for >>> G1GC as we need very small pauses Below 500msec. >>> But the problem is when we are runing with G1GC (under jdk 6_u37) >>> Old generation of garbage collection only happening when it is >>> reaching the Max GC size I noticed on jdk 6U 37 if max heap size is >>> 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>> >>> Is there any parameter to force the old gc happening regularly. >>> >>> I am trying following setting, >>> >>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 >>> -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 >>> -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 >>> -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>> >>> If anyone can give insight on how full GC is triggred internals will >>> be of great help. >>> >>> PS: I have tried without any option for G1 but not of much help >>> hence .. this one trying to be agressive ? but of not much help. >>> >>> >>> Regards, >>> Soumit >>> >> >> -- >> >> Monica Beckwith | Java Performance Engineer >> VOIP: +1 512 401 1274 >> Texas >> Oracle >> is committed to developing practices and products that help protect >> the environment > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chunt at salesforce.com Fri Oct 19 19:28:38 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Fri, 19 Oct 2012 12:28:38 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Message-ID: Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. Thanks again for the question! charlie ... On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: Thanks Charlie, I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. Again, I'm struggling to think of a use case for this behaviour. Regards, Kirk On 2012-10-19, at 8:56 PM, Charlie Hunt > wrote: Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. charlie ... On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: Hi Monica, Can you comment on what a value of 0 means? Regards, Kirk On 2012-10-19, at 2:55 PM, Monica Beckwith > wrote: Couple of quick observations and questions - 1. G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) 2. What do you mean by old gen collection? Are you talking about MixedGCs? 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? * I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? -Monica On 10/19/2012 12:13 AM, csewhiz wrote: Hello All, Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. Is there any parameter to force the old gc happening regularly. I am trying following setting, -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 If anyone can give insight on how full GC is triggred internals will be of great help. PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. Regards, Soumit -- Monica Beckwith | Java Performance Engineer VOIP: +1 512 401 1274 Texas Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 19 19:38:18 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 21:38:18 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Message-ID: <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> Hi Charlie, Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) Regards, Kirk On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: > Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? > > Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. > > By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. > > Thanks again for the question! > > charlie ... > > On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: > >> Thanks Charlie, >> >> I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. >> >> Again, I'm struggling to think of a use case for this behaviour. >> >> Regards, >> Kirk >> >> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >> >>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>> >>> A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: >>> - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>> - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle >>> * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. >>> - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. >>> >>> charlie ... >>> >>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>> >>>> Hi Monica, >>>> >>>> Can you comment on what a value of 0 means? >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >>>> >>>>> Couple of quick observations and questions - >>>>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>>>> What do you mean by old gen collection? Are you talking about MixedGCs? >>>>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>>>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>>>> -Monica >>>>> >>>>> >>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>>> >>>>>> Hello All, >>>>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>>>> >>>>>> Is there any parameter to force the old gc happening regularly. >>>>>> >>>>>> I am trying following setting, >>>>>> >>>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>>> >>>>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>>>> >>>>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Soumit >>>>>> >>>>> >>>>> -- >>>>> >>>>> Monica Beckwith | Java Performance Engineer >>>>> VOIP: +1 512 401 1274 >>>>> Texas >>>>> Oracle is committed to developing practices and products that help protect the environment >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 19 21:07:45 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 23:07:45 +0200 Subject: CMS CMF In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Message-ID: Hi all, I've got this GC log fragment that I'm puzzling over. 2833.756: [GC[YG occupancy: 1600484 K (1887488 K)]2833.756: [GC 2833.757: [ParNew (promotion failed): 1600484K->1600484K(1887488K), 2.2601630 secs] 19739658K->20165811K(20761856K), 2.2605170 secs] [Times: user=10.47 sys=0.11, real=2.26 secs] 2836.017: [Rescan (parallel) , 2.2167670 secs]2838.234: [weak refs processing, 0.5441620 secs]2838.778: [class unloading, 0.0623720 secs]2838.841: [scrub symbol & string tables, 0.0079860 secs] [1 CMS-remark: 18565327K(18874368K)] 20165811K(20761856K), 5.1880910 secs] [Times: user=42.02 sys=0.25, real=5.19 secs] 2838.945: [CMS-concurrent-sweep-start] 2849.966: [Full GC 2849.966: [CMS2862.696: [CMS-concurrent-sweep: 19.533/23.751 secs] [Times: user=42.67 sys=4.29, real=23.75 secs] (concurrent mode failure): 17074814K->4842456K(18874368K), 41.9426500 secs] 18962302K->4842456K(20761856K), [CMS Perm : 65645K->65265K(109292K)], 41.9429740 secs] So, a ParNew is signaled @ 2833.757 which leads to a promotion failed. I would expect that @ 2833.757 + 2.26 or 2836.017 we'd see the concurrent mode failure being reported. However @ that time we instead see a Rescan/remark. The CMS finally comes @ 2849.966, more than 15 seconds after the allocation failure has been reported. Is there a change here in that the final phases of CMS were allowed to run rather than reverting to a Full GC or is there something else going on here that I've missed on. Regards, Kirk From ysr1729 at gmail.com Fri Oct 19 21:20:47 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 19 Oct 2012 14:20:47 -0700 Subject: CMS CMF In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Message-ID: You probably have CMSScavengeBeforeRemark Enabled. The scavenge fails when initiated from the remark, but i am guessing that the failure is ignored and the remark ploughs on (slowly!). Then a full gc is attempted, but by then a sweep has started and for historical reasons it completes before the full gc can proceed. This points out several malinteractions in the case of CMSScavengeBeforeRemark that had not been fully considered by me when i designed it. In general, having more finely interruptible phases would have been better for CMS (as comments in the code state).... I think a simple fix is to not attempt the remark if the scavenge failed and just bail to a stop-world GC at that point. I think the change would not be too difficult. Please file a bug. -- ramki On Fri, Oct 19, 2012 at 2:07 PM, Kirk Pepperdine wrote: > Hi all, > > I've got this GC log fragment that I'm puzzling over. > > 2833.756: [GC[YG occupancy: 1600484 K (1887488 K)]2833.756: [GC 2833.757: > [ParNew (promotion failed): 1600484K->1600484K(1887488K), 2.2601630 secs] > 19739658K->20165811K(20761856K), 2.2605170 secs] [Times: user=10.47 > sys=0.11, real=2.26 secs] > 2836.017: [Rescan (parallel) , 2.2167670 secs]2838.234: [weak refs > processing, 0.5441620 secs]2838.778: [class unloading, 0.0623720 > secs]2838.841: [scrub symbol & string tables, 0.0079860 secs] [1 > CMS-remark: 18565327K(18874368K)] 20165811K(20761856K), 5.1880910 secs] > [Times: user=42.02 sys=0.25, real=5.19 secs] > 2838.945: [CMS-concurrent-sweep-start] > 2849.966: [Full GC 2849.966: [CMS2862.696: [CMS-concurrent-sweep: > 19.533/23.751 secs] [Times: user=42.67 sys=4.29, real=23.75 secs] > (concurrent mode failure): 17074814K->4842456K(18874368K), 41.9426500 > secs] 18962302K->4842456K(20761856K), [CMS Perm : 65645K->65265K(109292K)], > 41.9429740 secs] > > So, a ParNew is signaled @ 2833.757 which leads to a promotion failed. I > would expect that @ 2833.757 + 2.26 or 2836.017 we'd see the concurrent > mode failure being reported. However @ that time we instead see a > Rescan/remark. The CMS finally comes @ 2849.966, more than 15 seconds after > the allocation failure has been reported. Is there a change here in that > the final phases of CMS were allowed to run rather than reverting to a Full > GC or is there something else going on here that I've missed on. > > Regards, > Kirk > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 19 21:32:17 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 19 Oct 2012 23:32:17 +0200 Subject: CMS CMF In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> Message-ID: Hi Ramki, Thanks for the response... I don't know (for certain) which flags have been set as all I've been handed is this anonymous GC log but everything you mention makes sense in the context of how things have been reported in the log. I wouldn't be so harsh as to call this a bug but it's a point where some improvements maybe found.. so I'll go file a bug ;-) Regards, Kirk On 2012-10-19, at 11:20 PM, Srinivas Ramakrishna wrote: > You probably have CMSScavengeBeforeRemark Enabled. The scavenge fails when initiated from the remark, but i am guessing that the failure is ignored and the remark ploughs on (slowly!). Then a full gc is attempted, but by then a sweep has started and for historical reasons it completes before the full gc can proceed. This points out several malinteractions in the case of CMSScavengeBeforeRemark that had not been fully considered by me when i designed it. In general, having more finely interruptible phases would have been better for CMS (as comments in the code state).... I think a simple fix is to not attempt the remark if the scavenge failed and just bail to a stop-world GC at that point. I think the change would not be too difficult. Please file a bug. > > -- ramki > > On Fri, Oct 19, 2012 at 2:07 PM, Kirk Pepperdine wrote: > Hi all, > > I've got this GC log fragment that I'm puzzling over. > > 2833.756: [GC[YG occupancy: 1600484 K (1887488 K)]2833.756: [GC 2833.757: [ParNew (promotion failed): 1600484K->1600484K(1887488K), 2.2601630 secs] 19739658K->20165811K(20761856K), 2.2605170 secs] [Times: user=10.47 sys=0.11, real=2.26 secs] > 2836.017: [Rescan (parallel) , 2.2167670 secs]2838.234: [weak refs processing, 0.5441620 secs]2838.778: [class unloading, 0.0623720 secs]2838.841: [scrub symbol & string tables, 0.0079860 secs] [1 CMS-remark: 18565327K(18874368K)] 20165811K(20761856K), 5.1880910 secs] [Times: user=42.02 sys=0.25, real=5.19 secs] > 2838.945: [CMS-concurrent-sweep-start] > 2849.966: [Full GC 2849.966: [CMS2862.696: [CMS-concurrent-sweep: 19.533/23.751 secs] [Times: user=42.67 sys=4.29, real=23.75 secs] > (concurrent mode failure): 17074814K->4842456K(18874368K), 41.9426500 secs] 18962302K->4842456K(20761856K), [CMS Perm : 65645K->65265K(109292K)], 41.9429740 secs] > > So, a ParNew is signaled @ 2833.757 which leads to a promotion failed. I would expect that @ 2833.757 + 2.26 or 2836.017 we'd see the concurrent mode failure being reported. However @ that time we instead see a Rescan/remark. The CMS finally comes @ 2849.966, more than 15 seconds after the allocation failure has been reported. Is there a change here in that the final phases of CMS were allowed to run rather than reverting to a Full GC or is there something else going on here that I've missed on. > > Regards, > Kirk > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.murillo at oracle.com Fri Oct 19 22:16:53 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 19 Oct 2012 22:16:53 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 11 new changesets Message-ID: <20121019221719.8047747462@hg.openjdk.java.net> Changeset: fcbdaeb69946 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fcbdaeb69946 Added tag jdk8-b61 for changeset 4547dc71db76 ! .hgtags Changeset: bdb5f8c9978b Author: coleenp Date: 2012-10-10 17:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bdb5f8c9978b 7199068: NPG: SharedSkipVerify is meaningless Summary: Remove the SharedSkipVerify flag Reviewed-by: kamg, sspitsyn, coleenp Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp Changeset: 48a75d2640a5 Author: kamg Date: 2012-10-11 14:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/48a75d2640a5 7054345: Support version 52.0 class file in HotSpot Summary: Accept classfiles with major version 52 Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: e0ea0e94c23c Author: kevinw Date: 2012-10-15 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e0ea0e94c23c 7195151: Multiplatform tescase for 6929067 Reviewed-by: kamg, kvn ! test/runtime/6929067/Test6929067.sh Changeset: e52361627b65 Author: coleenp Date: 2012-10-15 22:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e52361627b65 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/globals.hpp Changeset: 045cb62046a7 Author: rbackman Date: 2012-08-28 15:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/045cb62046a7 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 7b5885dadbdc Author: nloodin Date: 2012-10-17 17:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7b5885dadbdc 8000617: It should be possible to allocate memory without the VM dying. Reviewed-by: coleenp, kamg ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: e8c79c2ba3f3 Author: coleenp Date: 2012-10-18 12:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e8c79c2ba3f3 Merge Changeset: d0337c31c8be Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d0337c31c8be Merge Changeset: dccd40de8db1 Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dccd40de8db1 Added tag hs25-b06 for changeset d0337c31c8be ! .hgtags Changeset: d0e7716b179e Author: amurillo Date: 2012-10-19 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d0e7716b179e 8001176: new hotspot build - hs25-b07 Reviewed-by: jcoomes ! make/hotspot_version From jon.masamitsu at oracle.com Mon Oct 22 21:59:52 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 22 Oct 2012 14:59:52 -0700 Subject: Request for review (m) - 7054397 In-Reply-To: <507F16DB.1000708@oracle.com> References: <505A902B.60103@oracle.com> <507F16DB.1000708@oracle.com> Message-ID: <5085C1D8.5030308@oracle.com> Update for a makefile change. See change to excludeSrc.make which is the only changes from 01 http://cr.openjdk.java.net/~jmasa/7045397/webrev.02/ Thanks. On 10/17/2012 1:36 PM, Jon Masamitsu wrote: > I've updated the change based on some review comments. > Specifically, moved code specific to CMS into files in > gc_implementation/concurrentMarkSweep > > http://cr.openjdk.java.net/~jmasa/7045397/webrev.01/ > > > On 9/19/2012 8:40 PM, Jon Masamitsu wrote: >> This change continues the templatization of the CMS freelist for >> more general use and uses the freelists for Metaspace chunks >> and block (part of the perm removal implementation). >> >> http://cr.openjdk.java.net/~jmasa/7045397/webrev.00/ >> >> 7045397: Add freelists to class loader arenas. >> >> Continue the templatization of the CMS freelist for use with the >> Metaspaces. >> >> Split functionality of FreeList between a simplified >> FreeList and AdaptiveFreeList. AdaptiveFreeList is >> specialized for use with CMS. >> >> Replace an interim freelist of humongous chunks with a >> freelist dictionary. A linked list of humongous chunks had >> been in use. >> >> Fix some spellings (e.g., totalSize to total_size). >> >> Delete the "splay" option that was never implemented. >> >> Move classes Metablock and Metachunk to metaspace.hpp so they >> are available for explicit instantiations of some template classes. >> From jon.masamitsu at oracle.com Wed Oct 24 08:39:51 2012 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 24 Oct 2012 08:39:51 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7045397: NPG: Add freelists to class loader arenas. Message-ID: <20121024083959.94CC5474EF@hg.openjdk.java.net> Changeset: 685df3c6f84b Author: jmasa Date: 2012-09-18 23:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/685df3c6f84b 7045397: NPG: Add freelists to class loader arenas. Reviewed-by: coleenp, stefank, jprovino, ohair ! make/excludeSrc.make + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp + src/share/vm/memory/metablock.hpp + src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/vmStructs.cpp From bengt.rutisson at oracle.com Wed Oct 24 16:29:39 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 24 Oct 2012 18:29:39 +0200 Subject: RFR(M): 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack In-Reply-To: <507703C2.8090107@oracle.com> References: <506B6E73.10406@oracle.com> <507703C2.8090107@oracle.com> Message-ID: <50881773.7080204@oracle.com> Hi John, Sorry for being late with the feedback on this. I think it looks good. A question regarding warnings: When we are setting up the ConcurrentMark instance we use a lot of "warning" in concurrentMark.cpp and return false. This will cause the ConcurrentMark instance to not have completed its initiation. This is detected in G1CollectedHeap::initialize() and it will call Snippet vm_shutdown_during_initialization(). To me it is kind of confusing to have a warning when we can not recover from it. I kind of think it would be better to print an error message and exit the VM on the spot. I'm not sure what the most common pattern is, but I thought warnings were used for things that will allow the VM to proceed but in a less than optimal state. But in this case we can not proceed at all. On the other hand I'm kind of surprised that CMMarkStack::expand() does: fatal("Not enough swap for expanded marking stack capacity") when it can not expand. Wouldn't it make sense to just print a warning in this case and go on using the previously reserved and committed virtual space? We are just using a smaller mark stack size than we would like, but we should still be able execute, right? Very minor things: I don't think we need "reasonable" default values for MarkStackSizeMax in globals.hpp anymore when we always override it in Arguments::set_ergonomics_flags(). I would suggest having something like "product(uintx, MarkStackSizeMax, 0," instead of "product(uintx, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M),". Line 279 in the new code for concurrentMark.cpp. You added an extra space that I think should not be there. Thanks, Bengt On 2012-10-11 19:37, John Cuthbertson wrote: > Hi Everyone, > > I have a new webrev based upon comments and observations from Jon > Masamitsu and Peter Kessler which can be found at: > http://cr.openjdk.java.net/~johnc/8000244/webrev.1/ > > Thanks, > > JohnC > > On 10/02/12 15:45, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review the change for this CR - the >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8000244/webrev.0/ >> >> Summary: >> In response code review comments from Bengt for CR 7188263, I decided >> to deal with the marking stack in its own CR - these are those changes. >> >> The allocation of G1's global marking stack now matches that of CMS >> and is allocated from virtual memory instead of C heap. Further the >> size of the marking stack has been changed from a fixed >> 128*TASKQUEUE_SIZE (16M entry capacity in a 64 bit JVM), which is the >> equivalent of the task queues of 128 threads, to a value based upon >> the actual number of parallel marking threads - with a suitable >> default minimum (4M entry capacity in a 64 bit JVM). The 4M entry >> capacity is the equivalent of the task queues for 32 threads. I have >> also mimicked CMS and added code to expand the marking stack in the >> event that concurrent marking is aborted and restarted due to >> overflowing the stack. The default maximum was the previous fixed >> value (128*TASKQUEUE_SIZE). Hence we go a maximum of 2 expansions >> before we have a marking stack sized as it was previously. >> Additionally I have rearranged (some of) the ConcurrentMark >> initialization code to (hopefully) make it a bit more robust w.r.t. >> allocation failures. >> >> This CR does not address the allocation of the liveness accounting >> data structures - those will be handled as 7188263. >> >> Testing: >> * command line testing with some instrumentation >> * GC test suite with a low IHOP, heap and marking verification, and >> forced marking overflows (and instrumentation) >> * GC test suite (normal) >> * jprt >> * refworkload (I didn't see any overflows in my runs, with an 8Gb >> heap, but it could happen). >> >> Thanks, >> >> JohnC > From john.cuthbertson at oracle.com Thu Oct 25 00:17:37 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 24 Oct 2012 17:17:37 -0700 Subject: RFR(M): 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack In-Reply-To: <50881773.7080204@oracle.com> References: <506B6E73.10406@oracle.com> <507703C2.8090107@oracle.com> <50881773.7080204@oracle.com> Message-ID: <50888521.7000305@oracle.com> Hi Bengt, Thanks for the review. Response inline.... On 10/24/12 09:29, Bengt Rutisson wrote: > > Hi John, > > Sorry for being late with the feedback on this. > > I think it looks good. > > A question regarding warnings: > > When we are setting up the ConcurrentMark instance we use a lot of > "warning" in concurrentMark.cpp and return false. This will cause the > ConcurrentMark instance to not have completed its initiation. This is > detected in G1CollectedHeap::initialize() and it will call Snippet > vm_shutdown_during_initialization(). > > To me it is kind of confusing to have a warning when we can not > recover from it. I kind of think it would be better to print an error > message and exit the VM on the spot. I'm not sure what the most common > pattern is, but I thought warnings were used for things that will > allow the VM to proceed but in a less than optimal state. But in this > case we can not proceed at all. Yeah. I originally had it the way you suggest but changed it as a result of feedback from Jon. I'm not sure there is a common pattern in hotspot for this. I think CMS uses warnings and checks a flag and I just extended the idea to G1's concurrent marking. I'm not sure what's the better approach here. > On the other hand I'm kind of surprised that CMMarkStack::expand() does: > fatal("Not enough swap for expanded marking stack capacity") > when it can not expand. Wouldn't it make sense to just print a warning > in this case and go on using the previously reserved and committed > virtual space? We are just using a smaller mark stack size than we > would like, but we should still be able execute, right? When looking at the original CMS code I thought the same thing. I think, however, the problem is that we have already released the space: // Double capacity if possible size_t new_capacity = MIN2(_capacity*2, MarkStackSizeMax); // Do not give up existing stack until we have managed to // get the double capacity that we desired. ReservedSpace rs(ReservedSpace::allocation_align_size_up( new_capacity * sizeof(oop))); if (rs.is_reserved()) { // Release the backing store associated with old stack _virtual_space.release(); // Reinitialize virtual space for new stack if (!_virtual_space.initialize(rs, rs.size())) { fatal("Not enough swap for expanded marking stack"); } but it looks like VirtualSpace::release() doesn't actually release the memory. I wonder if that was always the case. Anyway I think your suggestion is a good one. I'll see if it will work - we should be able to get the boundaries of the previous committed space before we call release(). > Very minor things: > > I don't think we need "reasonable" default values for MarkStackSizeMax > in globals.hpp anymore when we always override it in > Arguments::set_ergonomics_flags(). I would suggest having something > like "product(uintx, MarkStackSizeMax, 0," instead of "product(uintx, > MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M),". If this is true then I agree. I'll check it out. > > Line 279 in the new code for concurrentMark.cpp. You added an extra > space that I think should not be there. Thanks for catching that. I should have a new webrev with the changed expansion code and no default for MarkStackSizeMax in the next day or so. Thanks, JohnC From csewhiz at zoho.com Thu Oct 25 10:55:03 2012 From: csewhiz at zoho.com (csewhiz) Date: Thu, 25 Oct 2012 16:25:03 +0530 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> Message-ID: <13a978f9f78.-7639900542416892602.-3853164544703833272@zoho.com> Thank you all for great insight. I am actually moving to Java 7 update 9. As of now we were using CMS stratergy on java 6 but for one application which is holding the memory for long time and as G1 promises more real time like behavior wanted to try the G1. Regards, Soumit ---- On Sat, 20 Oct 2012 01:08:18 +0530 Kirk Pepperdine <kirk at kodewerk.com> wrote ---- Hi Charlie, Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) Regards, Kirk On 2012-10-19, at 9:28 PM, Charlie Hunt <chunt at salesforce.com> wrote: Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. Thanks again for the question! charlie ... On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: Thanks Charlie, I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. Again, I'm struggling to think of a use case for this behaviour. Regards, Kirk On 2012-10-19, at 8:56 PM, Charlie Hunt <chunt at salesforce.com> wrote: Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. charlie ... On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: Hi Monica, Can you comment on what a value of 0 means? Regards, Kirk On 2012-10-19, at 2:55 PM, Monica Beckwith <monica.beckwith at oracle.com> wrote: Couple of quick observations and questions - G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) What do you mean by old gen collection? Are you talking about MixedGCs? Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? -Monica On 10/19/2012 12:13 AM, csewhiz wrote: Hello All, Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. Is there any parameter to force the old gc happening regularly. I am trying following setting, -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 If anyone can give insight on how full GC is triggred internals will be of great help. PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. Regards, Soumit -- <oracle_sig_logo.gif> Monica Beckwith | Java Performance Engineer VOIP: +1 512 401 1274 Texas <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Oct 25 13:07:44 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 25 Oct 2012 15:07:44 +0200 Subject: RFR: 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java In-Reply-To: <507FE90C.2020508@oracle.com> References: <507FE90C.2020508@oracle.com> Message-ID: <508939A0.3060008@oracle.com> Hi all, Here's an updated webrev which breaks out the check for verification enabling to separate wrapper functions and replaces the use of #ifdef to use a "const bool" instead. http://cr.openjdk.java.net/~mgerdin/7200229.1/ Thanks /Mikael On 2012-10-18 13:33, Mikael Gerdin wrote: > Hi, > In the Metaspace implementation that replaced perm gen for class meta > data all allocations are made from "chunks". A ChunkManager is > responsible for keeping track of all free chunks and currently there is > a lot of verification of the free chunks by walking the linked lists > that the free chunks are kept in. > In a situation where we create a lot of class loaders we will force the > ChunkManager to allocate a lot of small chunks, this increases the > verification overhead in debug builds. This can cause tests to time out > because the verification calls become very expensive with a lot of free > chunks. > We've never seen any of the free chunk verification asserts trigger so I > propose that we disable the over-zealous verification and just add a > verification call to Universe::verify to make it possible to turn on > verification if needed. > > Webrev: http://cr.openjdk.java.net/~mgerdin/7200229 > Buglink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200229 > > Thanks > /Mikael > -- Mikael Gerdin Java SE VM SQE Stockholm From jon.masamitsu at oracle.com Thu Oct 25 15:18:27 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 25 Oct 2012 08:18:27 -0700 Subject: Request for review (xs) - 8001584 Message-ID: <50895843.8020701@oracle.com> 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() The assertion assert(dither != FreeBlockDictionary::exactly || res->size() == size, "Not correct size"); does not take into account that res may be NULL (as the assertion above it does). http://cr.openjdk.java.net/~jmasa/8001584/webrev.00/ or the diff --- a/src/share/vm/memory/binaryTreeDictionary.hpp +++ b/src/share/vm/memory/binaryTreeDictionary.hpp @@ -259,7 +259,7 @@ assert(res == NULL || res->is_free(), "Should be returning a free chunk"); assert(dither != FreeBlockDictionary::exactly || - res->size() == size, "Not correct size"); + res == NULL || res->size() == size, "Not correct size"); return res; } Thanks. Jon From ysr1729 at gmail.com Thu Oct 25 17:53:51 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 25 Oct 2012 10:53:51 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> Message-ID: Kirk, Think of Eden as the minimum space available for allocation before a young GC becomes necessary. Think of a survivor space as the minimum space set aside to hold objects surviving in the young generation and not being tenured. G1 does take advantage of the fact that you do not necessarily need to keep the "To" survivor space in reserve separately, but draw from a common pool of free regions. In practice, it might be sensible to reuse recently collected Eden regions (can't recall how hard G1 tries to do that) because it's possible that some caches are warm, but with today's huge young generation sizes, may be it doesn't make sense to talk about cache reuse. In the presence of paging, reusing Eden and survivor pages becomes more important to reduce the cost of inadvertently picking a region whose physical pages may need to be faulted in because they had been paged out or are being touched for the first time. (This may be more important on Windows because of its proclivity to evict pages that haven't been touched in a while even when there is no virtual memory pressure.) John might be able to tell us whether or how hard G1 tries to reuse Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code did not make any such attempts, but G1 has seen many recent improvements since I last looked). -- ramki On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: > Hi Charlie, > > Was thinking that as long as you're evacuating regions was there a need to > make a distinction between Eden and survivor... they are all just regions > in young gen. The distinction seems some what artificial. > > As for your use case.. make sense on one hand but on the other I'm > wondering if it's akin to calling System.gc()... time will tell me thinks. > ;-) > > Regards, > Kirk > > On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: > > Perhaps if you're really, really ... really squeeze on available heap > space and wanted stuff cleaned from old asap, then > InitiatiingHeapOccupancyPercent=0 could be justified? > > Btw, I thought about your question you asked at J1 on "why use survivor > spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with > Monica are free to offer their thoughts as well. > > By using survivor spaces, you should, (and I'd expect that to be the case) > reduce the amount of concurrent cycles you'll do. And, you will likely > more frequently visit more long live objects if you didn't have survivor > spaces as a result of doing more concurrent cycles. In addition, the total > number of different regions you evacuate may be more without survivor > spaces, and you may evacuate the same (live) objects more times than > without survivor spaces. In short, I would expect in most cases you end > evacuating fewer times per object and you end doing fewer concurrent > cycles, all of which saves you CPU cycles for application threads. Of > course, I'm sure we can write an application where it would be advantageous > to not have a survivor spaces in G1. But, we could also write would that > could never have the need for a concurrent cycle in a G1 heap that has > survivor spaces. > > Thanks again for the question! > > charlie ... > > On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: > > Thanks Charlie, > > I only had a cursor look at the source and found the initial calculation > but stopped there figuring someone here would know off the top of their > heads. Didn't expect someone to splunk through the code so a big thanks for > that. > > Again, I'm struggling to think of a use case for this behaviour. > > Regards, > Kirk > > On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: > > Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) > > A quick look at the G1 source code suggests that if > InitiatingHeapOccupancyPercent=0, the following will happen: > - the first minor GC will initiate a concurrent cycle implying that you'll > see a young GC with an initial-mark in the GC log w/ +PrintGCDetails > - every minor GC there after, as long as there is not an active concurrent > cycle, will initiate the start of a concurrent cycle > * So, in other words, concurrent cycles will run back to back. Remember > that there needs to be a minor GC to initiate the concurrent cycle, i.e. > the initial-mark. There is at least one caveat to that which I'll explain > next. So, once a concurrent cycle complete, the next concurrent cycle will > not start, until the next minor GC, or a humongous allocation occurs as > described next. > - If there is a humongous object allocation, a concurrent cycle will be > initiated (if InitiattingHeapOccupancyPercent=0). This is done before the > humongous allocation is done. > > charlie ... > > On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: > > Hi Monica, > > Can you comment on what a value of 0 means? > > Regards, > Kirk > > On 2012-10-19, at 2:55 PM, Monica Beckwith > wrote: > > Couple of quick observations and questions - > > 1. G1 is officially supported in 7u4. (There are numerous performance > improvements that I recommend updating to the latest jdk7 update, if > possible) > 2. What do you mean by old gen collection? Are you talking about > MixedGCs? > 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have you > tried resizing your young generation? > 1. I see the NewRatio, but that fixes the nursery to 640, instead > have you tried with a lower (than the min default) of nursery using the > NewSize option? > > -Monica > > > On 10/19/2012 12:13 AM, csewhiz wrote: > > Hello All, > Sorry for posting this question in this mailing list. I am unable to > find any answer for this. I am trying to tune our application for G1GC as > we need very small pauses Below 500msec. > But the problem is when we are runing with G1GC (under jdk 6_u37) Old > generation of garbage collection only happening when it is reaching the Max > GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to > 1sec 2GB close to 2 sec pauses. > > Is there any parameter to force the old gc happening regularly. > > I am trying following setting, > > -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 > -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 > -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 > -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 > > If anyone can give insight on how full GC is triggred internals will be of > great help. > > PS: I have tried without any option for G1 but not of much help hence .. > this one trying to be agressive ? but of not much help. > > > Regards, > Soumit > > > -- > > Monica Beckwith | Java Performance Engineer > VOIP: +1 512 401 1274 <+1%20512%20401%201274> > Texas > Oracle is > committed to developing practices and products that help protect the > environment > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Thu Oct 25 18:28:47 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 25 Oct 2012 11:28:47 -0700 Subject: Request for review (xs) - 8001584 In-Reply-To: <50895843.8020701@oracle.com> References: <50895843.8020701@oracle.com> Message-ID: <508984DF.4040605@oracle.com> Hi Jon, Looks good. JohnC On 10/25/2012 8:18 AM, Jon Masamitsu wrote: > 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() > > The assertion > > assert(dither != FreeBlockDictionary::exactly || > res->size() == size, "Not correct size"); > > does not take into account that res may be NULL (as the assertion > above it does). > > http://cr.openjdk.java.net/~jmasa/8001584/webrev.00/ > > or the diff > > --- a/src/share/vm/memory/binaryTreeDictionary.hpp > > +++ b/src/share/vm/memory/binaryTreeDictionary.hpp > > @@ -259,7 +259,7 @@ > > assert(res == NULL || res->is_free(), > > "Should be returning a free chunk"); > > assert(dither != FreeBlockDictionary::exactly || > > - res->size() == size, "Not correct size"); > > + res == NULL || res->size() == size, "Not correct size"); > > return res; > > } > > Thanks. > > Jon From tao.mao at oracle.com Thu Oct 25 19:40:50 2012 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 25 Oct 2012 12:40:50 -0700 Subject: Request for review (xs) - 8001584 In-Reply-To: <50895843.8020701@oracle.com> References: <50895843.8020701@oracle.com> Message-ID: <508995C2.3060504@oracle.com> looks good. Tao On 10/25/2012 8:18 AM, Jon Masamitsu wrote: > 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() > > The assertion > > assert(dither != FreeBlockDictionary::exactly || > res->size() == size, "Not correct size"); > > does not take into account that res may be NULL (as the assertion > above it does). > > http://cr.openjdk.java.net/~jmasa/8001584/webrev.00/ > > or the diff > > --- a/src/share/vm/memory/binaryTreeDictionary.hpp > > +++ b/src/share/vm/memory/binaryTreeDictionary.hpp > > @@ -259,7 +259,7 @@ > > assert(res == NULL || res->is_free(), > > "Should be returning a free chunk"); > > assert(dither != FreeBlockDictionary::exactly || > > - res->size() == size, "Not correct size"); > > + res == NULL || res->size() == size, "Not correct size"); > > return res; > > } > > Thanks. > > Jon From jon.masamitsu at oracle.com Thu Oct 25 19:52:21 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 25 Oct 2012 12:52:21 -0700 Subject: Request for review (xs) - 8001584 In-Reply-To: <508984DF.4040605@oracle.com> References: <50895843.8020701@oracle.com> <508984DF.4040605@oracle.com> Message-ID: <50899875.6040601@oracle.com> Thanks, John. You saved yourself and others from hearing my whining about this. Jon On 10/25/12 11:28, John Cuthbertson wrote: > Hi Jon, > > Looks good. > > JohnC > > On 10/25/2012 8:18 AM, Jon Masamitsu wrote: >> 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() >> >> The assertion >> >> assert(dither != FreeBlockDictionary::exactly || >> res->size() == size, "Not correct size"); >> >> does not take into account that res may be NULL (as the assertion >> above it does). >> >> http://cr.openjdk.java.net/~jmasa/8001584/webrev.00/ >> >> or the diff >> >> --- a/src/share/vm/memory/binaryTreeDictionary.hpp >> >> +++ b/src/share/vm/memory/binaryTreeDictionary.hpp >> >> @@ -259,7 +259,7 @@ >> >> assert(res == NULL || res->is_free(), >> >> "Should be returning a free chunk"); >> >> assert(dither != FreeBlockDictionary::exactly || >> >> - res->size() == size, "Not correct size"); >> >> + res == NULL || res->size() == size, "Not correct size"); >> >> return res; >> >> } >> >> Thanks. >> >> Jon From ysr1729 at gmail.com Thu Oct 25 19:57:41 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 25 Oct 2012 12:57:41 -0700 Subject: Request for review (xs) - 8001584 In-Reply-To: <50895843.8020701@oracle.com> References: <50895843.8020701@oracle.com> Message-ID: Looks good to me. -- ramki On Thu, Oct 25, 2012 at 8:18 AM, Jon Masamitsu wrote: > 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_**chunk() > > The assertion > > assert(dither != FreeBlockDictionary::**exactly || > res->size() == size, "Not correct size"); > > does not take into account that res may be NULL (as the assertion > above it does). > > http://cr.openjdk.java.net/~**jmasa/8001584/webrev.00/ > > or the diff > > --- a/src/share/vm/memory/**binaryTreeDictionary.hpp > > +++ b/src/share/vm/memory/**binaryTreeDictionary.hpp > > @@ -259,7 +259,7 @@ > > assert(res == NULL || res->is_free(), > > "Should be returning a free chunk"); > > assert(dither != FreeBlockDictionary::**exactly || > > - res->size() == size, "Not correct size"); > > + res == NULL || res->size() == size, "Not correct size"); > > return res; > > } > > Thanks. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Thu Oct 25 19:18:14 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 25 Oct 2012 21:18:14 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> Message-ID: <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> This is a nice explanation... I would think that not necessarly having a to/from survivor space would cut back on some copy costs? On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna wrote: > Kirk, Think of Eden as the minimum space available for allocation before a young GC becomes necessary. Think of a survivor space as the minimum space set aside to hold objects surviving in the young generation and not being tenured. G1 does take advantage of the fact that you do not necessarily need to keep the "To" survivor space in reserve separately, but draw from a common pool of free regions. In practice, it might be sensible to reuse recently collected Eden regions (can't recall how hard G1 tries to do that) because it's possible that some caches are warm, but with today's huge young generation sizes, may be it doesn't make sense to talk about cache reuse. In the presence of paging, reusing Eden and survivor pages becomes more important to reduce the cost of inadvertently picking a region whose physical pages may need to be faulted in because they had been paged out or are being touched for the first time. (This may be more important on Windows because of its proclivity to evict pages that haven't been touched in a while even when there is no virtual memory pressure.) > > John might be able to tell us whether or how hard G1 tries to reuse Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code did not make any such attempts, but G1 has seen many recent improvements since I last looked). > > -- ramki > > On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: > Hi Charlie, > > Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. > > As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) > > Regards, > Kirk > > On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: > >> Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? >> >> Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. >> >> By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. >> >> Thanks again for the question! >> >> charlie ... >> >> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >> >>> Thanks Charlie, >>> >>> I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. >>> >>> Again, I'm struggling to think of a use case for this behaviour. >>> >>> Regards, >>> Kirk >>> >>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>> >>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>> >>>> A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: >>>> - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>> - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle >>>> * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. >>>> - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. >>>> >>>> charlie ... >>>> >>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>> >>>>> Hi Monica, >>>>> >>>>> Can you comment on what a value of 0 means? >>>>> >>>>> Regards, >>>>> Kirk >>>>> >>>>> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >>>>> >>>>>> Couple of quick observations and questions - >>>>>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>>>>> What do you mean by old gen collection? Are you talking about MixedGCs? >>>>>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>>>>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>>>>> -Monica >>>>>> >>>>>> >>>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>>>> >>>>>>> Hello All, >>>>>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>>>>> >>>>>>> Is there any parameter to force the old gc happening regularly. >>>>>>> >>>>>>> I am trying following setting, >>>>>>> >>>>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>>>> >>>>>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>>>>> >>>>>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Soumit >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Monica Beckwith | Java Performance Engineer >>>>>> VOIP: +1 512 401 1274 >>>>>> Texas >>>>>> Oracle is committed to developing practices and products that help protect the environment >>>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Thu Oct 25 20:58:38 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 25 Oct 2012 16:58:38 -0400 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> Message-ID: Kirk, Unless I misunderstood your question, not having survivor spaces means you need to promote to tenured which may be undesired for non long-lived objects. The 2 survivor spaces allow for an object to survive a few young GCs and then die before promotion (provided its tenuring threshold is not breached). Sent from my phone On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: > This is a nice explanation... I would think that not necessarly having a > to/from survivor space would cut back on some copy costs? > > On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna wrote: > > Kirk, Think of Eden as the minimum space available for allocation before a > young GC becomes necessary. Think of a survivor space as the minimum space > set aside to hold objects surviving in the young generation and not being > tenured. G1 does take advantage of the fact that you do not necessarily > need to keep the "To" survivor space in reserve separately, but draw from a > common pool of free regions. In practice, it might be sensible to reuse > recently collected Eden regions (can't recall how hard G1 tries to do that) > because it's possible that some caches are warm, but with today's huge > young generation sizes, may be it doesn't make sense to talk about cache > reuse. In the presence of paging, reusing Eden and survivor pages becomes > more important to reduce the cost of inadvertently picking a region whose > physical pages may need to be faulted in because they had been paged out or > are being touched for the first time. (This may be more important on > Windows because of its proclivity to evict pages that haven't been touched > in a while even when there is no virtual memory pressure.) > > John might be able to tell us whether or how hard G1 tries to reuse > Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code > did not make any such attempts, but G1 has seen many recent improvements > since I last looked). > > -- ramki > > On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: > >> Hi Charlie, >> >> Was thinking that as long as you're evacuating regions was there a need >> to make a distinction between Eden and survivor... they are all just >> regions in young gen. The distinction seems some what artificial. >> >> As for your use case.. make sense on one hand but on the other I'm >> wondering if it's akin to calling System.gc()... time will tell me thinks. >> ;-) >> >> Regards, >> Kirk >> >> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >> >> Perhaps if you're really, really ... really squeeze on available heap >> space and wanted stuff cleaned from old asap, then >> InitiatiingHeapOccupancyPercent=0 could be justified? >> >> Btw, I thought about your question you asked at J1 on "why use survivor >> spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with >> Monica are free to offer their thoughts as well. >> >> By using survivor spaces, you should, (and I'd expect that to be the >> case) reduce the amount of concurrent cycles you'll do. And, you will >> likely more frequently visit more long live objects if you didn't have >> survivor spaces as a result of doing more concurrent cycles. In addition, >> the total number of different regions you evacuate may be more without >> survivor spaces, and you may evacuate the same (live) objects more times >> than without survivor spaces. In short, I would expect in most cases you >> end evacuating fewer times per object and you end doing fewer concurrent >> cycles, all of which saves you CPU cycles for application threads. Of >> course, I'm sure we can write an application where it would be advantageous >> to not have a survivor spaces in G1. But, we could also write would that >> could never have the need for a concurrent cycle in a G1 heap that has >> survivor spaces. >> >> Thanks again for the question! >> >> charlie ... >> >> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >> >> Thanks Charlie, >> >> I only had a cursor look at the source and found the initial calculation >> but stopped there figuring someone here would know off the top of their >> heads. Didn't expect someone to splunk through the code so a big thanks for >> that. >> >> Again, I'm struggling to think of a use case for this behaviour. >> >> Regards, >> Kirk >> >> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >> >> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >> >> A quick look at the G1 source code suggests that if >> InitiatingHeapOccupancyPercent=0, the following will happen: >> - the first minor GC will initiate a concurrent cycle implying that >> you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >> - every minor GC there after, as long as there is not an active >> concurrent cycle, will initiate the start of a concurrent cycle >> * So, in other words, concurrent cycles will run back to back. Remember >> that there needs to be a minor GC to initiate the concurrent cycle, i.e. >> the initial-mark. There is at least one caveat to that which I'll explain >> next. So, once a concurrent cycle complete, the next concurrent cycle will >> not start, until the next minor GC, or a humongous allocation occurs as >> described next. >> - If there is a humongous object allocation, a concurrent cycle will be >> initiated (if InitiattingHeapOccupancyPercent=0). This is done before the >> humongous allocation is done. >> >> charlie ... >> >> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >> >> Hi Monica, >> >> Can you comment on what a value of 0 means? >> >> Regards, >> Kirk >> >> On 2012-10-19, at 2:55 PM, Monica Beckwith >> wrote: >> >> Couple of quick observations and questions - >> >> 1. G1 is officially supported in 7u4. (There are numerous performance >> improvements that I recommend updating to the latest jdk7 update, if >> possible) >> 2. What do you mean by old gen collection? Are you talking about >> MixedGCs? >> 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have >> you tried resizing your young generation? >> 1. I see the NewRatio, but that fixes the nursery to 640, instead >> have you tried with a lower (than the min default) of nursery using the >> NewSize option? >> >> -Monica >> >> >> On 10/19/2012 12:13 AM, csewhiz wrote: >> >> Hello All, >> Sorry for posting this question in this mailing list. I am unable to >> find any answer for this. I am trying to tune our application for G1GC as >> we need very small pauses Below 500msec. >> But the problem is when we are runing with G1GC (under jdk 6_u37) Old >> generation of garbage collection only happening when it is reaching the Max >> GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to >> 1sec 2GB close to 2 sec pauses. >> >> Is there any parameter to force the old gc happening regularly. >> >> I am trying following setting, >> >> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 >> -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 >> -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 >> -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >> >> If anyone can give insight on how full GC is triggred internals will be >> of great help. >> >> PS: I have tried without any option for G1 but not of much help hence .. >> this one trying to be agressive ? but of not much help. >> >> >> Regards, >> Soumit >> >> >> -- >> >> Monica Beckwith | Java Performance Engineer >> VOIP: +1 512 401 1274 <+1%20512%20401%201274> >> Texas >> Oracle is >> committed to developing practices and products that help protect the >> environment >> >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Thu Oct 25 21:04:36 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 25 Oct 2012 23:04:36 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> Message-ID: <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Not necessarily, IBM doesn't have survivor spaces and they don't promote until they hit a tenuring threshold. They use a hemispheric scheme in young which I'm wondering would even be necessary in G1. For example, objects would get evacuated from a young gen region when they hit a tenuring threshold. Until then young gen regions would get collected based on occupancy just as old gen regions are. Given weak gen hypothesis I'm not sure if there would be a lot of savings here 'cept when you ran into blocks of long lived objects. -- Kirk On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: > Kirk, > > Unless I misunderstood your question, not having survivor spaces means you need to promote to tenured which may be undesired for non long-lived objects. The 2 survivor spaces allow for an object to survive a few young GCs and then die before promotion (provided its tenuring threshold is not breached). > > Sent from my phone > > On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: > This is a nice explanation... I would think that not necessarly having a to/from survivor space would cut back on some copy costs? > > On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna wrote: > >> Kirk, Think of Eden as the minimum space available for allocation before a young GC becomes necessary. Think of a survivor space as the minimum space set aside to hold objects surviving in the young generation and not being tenured. G1 does take advantage of the fact that you do not necessarily need to keep the "To" survivor space in reserve separately, but draw from a common pool of free regions. In practice, it might be sensible to reuse recently collected Eden regions (can't recall how hard G1 tries to do that) because it's possible that some caches are warm, but with today's huge young generation sizes, may be it doesn't make sense to talk about cache reuse. In the presence of paging, reusing Eden and survivor pages becomes more important to reduce the cost of inadvertently picking a region whose physical pages may need to be faulted in because they had been paged out or are being touched for the first time. (This may be more important on Windows because of its proclivity to evict pages that haven't been touched in a while even when there is no virtual memory pressure.) >> >> John might be able to tell us whether or how hard G1 tries to reuse Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code did not make any such attempts, but G1 has seen many recent improvements since I last looked). >> >> -- ramki >> >> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >> Hi Charlie, >> >> Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. >> >> As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) >> >> Regards, >> Kirk >> >> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >> >>> Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? >>> >>> Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. >>> >>> By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. >>> >>> Thanks again for the question! >>> >>> charlie ... >>> >>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>> >>>> Thanks Charlie, >>>> >>>> I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. >>>> >>>> Again, I'm struggling to think of a use case for this behaviour. >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>>> >>>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>>> >>>>> A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: >>>>> - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>>> - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle >>>>> * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. >>>>> - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. >>>>> >>>>> charlie ... >>>>> >>>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>>> >>>>>> Hi Monica, >>>>>> >>>>>> Can you comment on what a value of 0 means? >>>>>> >>>>>> Regards, >>>>>> Kirk >>>>>> >>>>>> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >>>>>> >>>>>>> Couple of quick observations and questions - >>>>>>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>>>>>> What do you mean by old gen collection? Are you talking about MixedGCs? >>>>>>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>>>>>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>>>>>> -Monica >>>>>>> >>>>>>> >>>>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>>>>> >>>>>>>> Hello All, >>>>>>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>>>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>>>>>> >>>>>>>> Is there any parameter to force the old gc happening regularly. >>>>>>>> >>>>>>>> I am trying following setting, >>>>>>>> >>>>>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>>>>> >>>>>>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>>>>>> >>>>>>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Soumit >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Monica Beckwith | Java Performance Engineer >>>>>>> VOIP: +1 512 401 1274 >>>>>>> Texas >>>>>>> Oracle is committed to developing practices and products that help protect the environment >>>>>> >>>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Thu Oct 25 21:07:14 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 25 Oct 2012 23:07:14 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> Message-ID: in fact, I might add that if all objects in a young gen regions are to be tenured, why copy at all, just promote the entire region by reassigning it. Regards, Kirk On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: > Kirk, > > Unless I misunderstood your question, not having survivor spaces means you need to promote to tenured which may be undesired for non long-lived objects. The 2 survivor spaces allow for an object to survive a few young GCs and then die before promotion (provided its tenuring threshold is not breached). > > Sent from my phone > > On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: > This is a nice explanation... I would think that not necessarly having a to/from survivor space would cut back on some copy costs? > > On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna wrote: > >> Kirk, Think of Eden as the minimum space available for allocation before a young GC becomes necessary. Think of a survivor space as the minimum space set aside to hold objects surviving in the young generation and not being tenured. G1 does take advantage of the fact that you do not necessarily need to keep the "To" survivor space in reserve separately, but draw from a common pool of free regions. In practice, it might be sensible to reuse recently collected Eden regions (can't recall how hard G1 tries to do that) because it's possible that some caches are warm, but with today's huge young generation sizes, may be it doesn't make sense to talk about cache reuse. In the presence of paging, reusing Eden and survivor pages becomes more important to reduce the cost of inadvertently picking a region whose physical pages may need to be faulted in because they had been paged out or are being touched for the first time. (This may be more important on Windows because of its proclivity to evict pages that haven't been touched in a while even when there is no virtual memory pressure.) >> >> John might be able to tell us whether or how hard G1 tries to reuse Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code did not make any such attempts, but G1 has seen many recent improvements since I last looked). >> >> -- ramki >> >> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >> Hi Charlie, >> >> Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. >> >> As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) >> >> Regards, >> Kirk >> >> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >> >>> Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? >>> >>> Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. >>> >>> By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. >>> >>> Thanks again for the question! >>> >>> charlie ... >>> >>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>> >>>> Thanks Charlie, >>>> >>>> I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. >>>> >>>> Again, I'm struggling to think of a use case for this behaviour. >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>>> >>>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>>> >>>>> A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: >>>>> - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>>> - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle >>>>> * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. >>>>> - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. >>>>> >>>>> charlie ... >>>>> >>>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>>> >>>>>> Hi Monica, >>>>>> >>>>>> Can you comment on what a value of 0 means? >>>>>> >>>>>> Regards, >>>>>> Kirk >>>>>> >>>>>> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >>>>>> >>>>>>> Couple of quick observations and questions - >>>>>>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>>>>>> What do you mean by old gen collection? Are you talking about MixedGCs? >>>>>>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>>>>>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>>>>>> -Monica >>>>>>> >>>>>>> >>>>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>>>>> >>>>>>>> Hello All, >>>>>>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>>>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>>>>>> >>>>>>>> Is there any parameter to force the old gc happening regularly. >>>>>>>> >>>>>>>> I am trying following setting, >>>>>>>> >>>>>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>>>>> >>>>>>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>>>>>> >>>>>>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Soumit >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Monica Beckwith | Java Performance Engineer >>>>>>> VOIP: +1 512 401 1274 >>>>>>> Texas >>>>>>> Oracle is committed to developing practices and products that help protect the environment >>>>>> >>>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Thu Oct 25 21:11:15 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 25 Oct 2012 17:11:15 -0400 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: So if some objects survive young GC and need to be copied so that new allocations are bump the pointer and fragmentation is avoided, where would they be copied to if there's no concept of survivor space (or something akin to it)? You don't want to tenure them prematurely if they ultimately would die fairly soon but you can't keep them in place if you're employing a copying collector. Sent from my phone On Oct 25, 2012 5:04 PM, "Kirk Pepperdine" wrote: > Not necessarily, IBM doesn't have survivor spaces and they don't promote > until they hit a tenuring threshold. They use a hemispheric scheme in young > which I'm wondering would even be necessary in G1. For example, objects > would get evacuated from a young gen region when they hit a tenuring > threshold. Until then young gen regions would get collected based on > occupancy just as old gen regions are. Given weak gen hypothesis I'm not > sure if there would be a lot of savings here 'cept when you ran into blocks > of long lived objects. > > -- Kirk > > On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: > > Kirk, > > Unless I misunderstood your question, not having survivor spaces means you > need to promote to tenured which may be undesired for non long-lived > objects. The 2 survivor spaces allow for an object to survive a few young > GCs and then die before promotion (provided its tenuring threshold is not > breached). > > Sent from my phone > On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: > >> This is a nice explanation... I would think that not necessarly having a >> to/from survivor space would cut back on some copy costs? >> >> On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna >> wrote: >> >> Kirk, Think of Eden as the minimum space available for allocation before >> a young GC becomes necessary. Think of a survivor space as the minimum >> space set aside to hold objects surviving in the young generation and not >> being tenured. G1 does take advantage of the fact that you do not >> necessarily need to keep the "To" survivor space in reserve separately, but >> draw from a common pool of free regions. In practice, it might be sensible >> to reuse recently collected Eden regions (can't recall how hard G1 tries to >> do that) because it's possible that some caches are warm, but with today's >> huge young generation sizes, may be it doesn't make sense to talk about >> cache reuse. In the presence of paging, reusing Eden and survivor pages >> becomes more important to reduce the cost of inadvertently picking a region >> whose physical pages may need to be faulted in because they had been paged >> out or are being touched for the first time. (This may be more important on >> Windows because of its proclivity to evict pages that haven't been touched >> in a while even when there is no virtual memory pressure.) >> >> John might be able to tell us whether or how hard G1 tries to reuse >> Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code >> did not make any such attempts, but G1 has seen many recent improvements >> since I last looked). >> >> -- ramki >> >> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >> >>> Hi Charlie, >>> >>> Was thinking that as long as you're evacuating regions was there a need >>> to make a distinction between Eden and survivor... they are all just >>> regions in young gen. The distinction seems some what artificial. >>> >>> As for your use case.. make sense on one hand but on the other I'm >>> wondering if it's akin to calling System.gc()... time will tell me thinks. >>> ;-) >>> >>> Regards, >>> Kirk >>> >>> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >>> >>> Perhaps if you're really, really ... really squeeze on available heap >>> space and wanted stuff cleaned from old asap, then >>> InitiatiingHeapOccupancyPercent=0 could be justified? >>> >>> Btw, I thought about your question you asked at J1 on "why use survivor >>> spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with >>> Monica are free to offer their thoughts as well. >>> >>> By using survivor spaces, you should, (and I'd expect that to be the >>> case) reduce the amount of concurrent cycles you'll do. And, you will >>> likely more frequently visit more long live objects if you didn't have >>> survivor spaces as a result of doing more concurrent cycles. In addition, >>> the total number of different regions you evacuate may be more without >>> survivor spaces, and you may evacuate the same (live) objects more times >>> than without survivor spaces. In short, I would expect in most cases you >>> end evacuating fewer times per object and you end doing fewer concurrent >>> cycles, all of which saves you CPU cycles for application threads. Of >>> course, I'm sure we can write an application where it would be advantageous >>> to not have a survivor spaces in G1. But, we could also write would that >>> could never have the need for a concurrent cycle in a G1 heap that has >>> survivor spaces. >>> >>> Thanks again for the question! >>> >>> charlie ... >>> >>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>> >>> Thanks Charlie, >>> >>> I only had a cursor look at the source and found the initial calculation >>> but stopped there figuring someone here would know off the top of their >>> heads. Didn't expect someone to splunk through the code so a big thanks for >>> that. >>> >>> Again, I'm struggling to think of a use case for this behaviour. >>> >>> Regards, >>> Kirk >>> >>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>> >>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>> >>> A quick look at the G1 source code suggests that if >>> InitiatingHeapOccupancyPercent=0, the following will happen: >>> - the first minor GC will initiate a concurrent cycle implying that >>> you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>> - every minor GC there after, as long as there is not an active >>> concurrent cycle, will initiate the start of a concurrent cycle >>> * So, in other words, concurrent cycles will run back to back. Remember >>> that there needs to be a minor GC to initiate the concurrent cycle, i.e. >>> the initial-mark. There is at least one caveat to that which I'll explain >>> next. So, once a concurrent cycle complete, the next concurrent cycle will >>> not start, until the next minor GC, or a humongous allocation occurs as >>> described next. >>> - If there is a humongous object allocation, a concurrent cycle will be >>> initiated (if InitiattingHeapOccupancyPercent=0). This is done before the >>> humongous allocation is done. >>> >>> charlie ... >>> >>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>> >>> Hi Monica, >>> >>> Can you comment on what a value of 0 means? >>> >>> Regards, >>> Kirk >>> >>> On 2012-10-19, at 2:55 PM, Monica Beckwith >>> wrote: >>> >>> Couple of quick observations and questions - >>> >>> 1. G1 is officially supported in 7u4. (There are numerous >>> performance improvements that I recommend updating to the latest jdk7 >>> update, if possible) >>> 2. What do you mean by old gen collection? Are you talking about >>> MixedGCs? >>> 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have >>> you tried resizing your young generation? >>> 1. I see the NewRatio, but that fixes the nursery to 640, instead >>> have you tried with a lower (than the min default) of nursery using the >>> NewSize option? >>> >>> -Monica >>> >>> >>> On 10/19/2012 12:13 AM, csewhiz wrote: >>> >>> Hello All, >>> Sorry for posting this question in this mailing list. I am unable to >>> find any answer for this. I am trying to tune our application for G1GC as >>> we need very small pauses Below 500msec. >>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old >>> generation of garbage collection only happening when it is reaching the Max >>> GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to >>> 1sec 2GB close to 2 sec pauses. >>> >>> Is there any parameter to force the old gc happening regularly. >>> >>> I am trying following setting, >>> >>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 >>> -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 >>> -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 >>> -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>> >>> If anyone can give insight on how full GC is triggred internals will be >>> of great help. >>> >>> PS: I have tried without any option for G1 but not of much help hence .. >>> this one trying to be agressive ? but of not much help. >>> >>> >>> Regards, >>> Soumit >>> >>> >>> -- >>> >>> Monica Beckwith | Java Performance Engineer >>> VOIP: +1 512 401 1274 <+1%20512%20401%201274> >>> Texas >>> Oracle >>> is committed to developing practices and products that help protect the >>> environment >>> >>> >>> >>> >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd-2012 at eckenfels.net Thu Oct 25 21:26:57 2012 From: bernd-2012 at eckenfels.net (Bernd Eckenfels) Date: Thu, 25 Oct 2012 23:26:57 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Am 25.10.2012, 23:11 Uhr, schrieb Vitaly Davidovich : > You don't want to tenure them prematurely if they ultimately > would die fairly soon but you can't keep them in place if you're > employing a copying collector. Actually you might want to tenure them "early": if your oldgen is collected concurrently _and_ the young collection frequency is larger than a typical transaction (which is a fairly common situation). Therefore there is an argument for using MaxTenuring=0 (or only 1). But thats not really G1 related, I just wanted to mention it. Bernd From vitalyd at gmail.com Thu Oct 25 21:36:40 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 25 Oct 2012 17:36:40 -0400 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Hmm, collecting old gen usually involves more work than doing young GC since it may do additional things (e.g. ref processing) as well as being larger than eden. I think even with concurrent old you probably don't want to trigger them due to premature promotion (if it's a non-compacting concurrent GC, like CMS, you may start accumulating fragmentation where you otherwise wouldn't). Generally, it makes sense to me to have some buffering in eden to avoid midlife crisis objects wreaking havoc in old gen. Sent from my phone On Oct 25, 2012 5:28 PM, "Bernd Eckenfels" wrote: > Am 25.10.2012, 23:11 Uhr, schrieb Vitaly Davidovich : > > You don't want to tenure them prematurely if they ultimately >> would die fairly soon but you can't keep them in place if you're >> employing a copying collector. >> > > Actually you might want to tenure them "early": if your oldgen is > collected concurrently _and_ the young collection frequency is larger than > a typical transaction (which is a fairly common situation). > > Therefore there is an argument for using MaxTenuring=0 (or only 1). But > thats not really G1 related, I just wanted to mention it. > > Bernd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Oct 25 21:39:20 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 25 Oct 2012 17:39:20 -0400 Subject: Request for review (xs) - 8001584 In-Reply-To: <50895843.8020701@oracle.com> References: <50895843.8020701@oracle.com> Message-ID: <5089B188.8050209@oracle.com> Looks good! Coleen On 10/25/2012 11:18 AM, Jon Masamitsu wrote: > 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() > > The assertion > > assert(dither != FreeBlockDictionary::exactly || > res->size() == size, "Not correct size"); > > does not take into account that res may be NULL (as the assertion > above it does). > > http://cr.openjdk.java.net/~jmasa/8001584/webrev.00/ > > or the diff > > --- a/src/share/vm/memory/binaryTreeDictionary.hpp > > +++ b/src/share/vm/memory/binaryTreeDictionary.hpp > > @@ -259,7 +259,7 @@ > > assert(res == NULL || res->is_free(), > > "Should be returning a free chunk"); > > assert(dither != FreeBlockDictionary::exactly || > > - res->size() == size, "Not correct size"); > > + res == NULL || res->size() == size, "Not correct size"); > > return res; > > } > > Thanks. > > Jon From thomas.schatzl at jku.at Thu Oct 25 22:11:21 2012 From: thomas.schatzl at jku.at (Thomas Schatzl) Date: Fri, 26 Oct 2012 00:11:21 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> Message-ID: <1351203081.3424.80.camel@tiantang.ssw.uni-linz.ac.at> Hi, On Thu, 2012-10-25 at 10:53 -0700, Srinivas Ramakrishna wrote: > John might be able to tell us whether or how hard G1 tries to reuse > Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 > code did not make any such attempts, but G1 has seen many recent > improvements since I last looked). afaik all recently emptied regions (evacuated ones) are first put into a list in the order they've been put into the collection set (i.e. the regions that were targets for evacuation) and then bulk-added at the head of the free region list. I.e. to where the next region allocations will occur from. So you will automatically get the desired effect to some extent. I do not remember that this has changed recently. John may know better about this though. > need to keep the "To" survivor space in reserve separately, but draw > from a common pool of free regions. In practice, it might be sensible > to reuse recently collected Eden regions (can't recall how hard G1 > tries to do that) because it's possible that some caches are warm, but > with today's huge young generation sizes, may be it doesn't make sense > to talk about cache reuse. Not sure what caching of these regions helps here: I'd naively assume that you actually don't really want the contents of these regions in the cache because they were just made obsolete by evacuation. Maybe memory metadata, e.g. TLB entries? Note that young gen is often very large too (10+GB?) and the regions too in that case (16M in such heaps), so I'm not sure there is much to gain by more clever management or e.g. if you prefetched/pretouched them. So I'd tend to agree to your analysis without measurements. Hth, Thomas From jon.masamitsu at oracle.com Thu Oct 25 22:42:37 2012 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 25 Oct 2012 22:42:37 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() Message-ID: <20121025224242.9F4C747554@hg.openjdk.java.net> Changeset: 476718ea6759 Author: jmasa Date: 2012-10-25 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/476718ea6759 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() Reviewed-by: johnc, tamao ! src/share/vm/memory/binaryTreeDictionary.hpp From thomas.schatzl at jku.at Thu Oct 25 22:48:47 2012 From: thomas.schatzl at jku.at (Thomas Schatzl) Date: Fri, 26 Oct 2012 00:48:47 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <1351203081.3424.80.camel@tiantang.ssw.uni-linz.ac.at> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <1351203081.3424.80.camel@tiantang.ssw.uni-linz.ac.at> Message-ID: <1351205327.3424.104.camel@tiantang.ssw.uni-linz.ac.at> Hi, some more info about the implementation which might clear up other questions. Did not know where to jump in this discussion because of all that top-posting. On Fri, 2012-10-26 at 00:11 +0200, Thomas Schatzl wrote: > Hi, > > On Thu, 2012-10-25 at 10:53 -0700, Srinivas Ramakrishna wrote: > > > John might be able to tell us whether or how hard G1 tries to reuse > > Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 > > code did not make any such attempts, but G1 has seen many recent > > improvements since I last looked). > > afaik all recently emptied regions (evacuated ones) are first put into > a list in the order they've been put into the collection set (i.e. the > regions that were targets for evacuation) and then bulk-added at the > head of the free region list. The collection set in G1 seems to consist of regions in that order: [old gen regions +] new young gen/eden regions [+ survivor regions] where region types in brackets are optional depending on whether they are available. During that process, survivor regions are relabeled as normal young gen/eden regions. Very briefly looking through the code the reason why G1 has explicit survivor regions (it does not have from/to spaces!) seems to be for statistical reasons which may include that some tools (or the users :) probably expect the collector to have survivor regions. Imo, from a pure evacuation point of view, for g1 the survivor regions may be considered just as a fancy label for "the regions that I copied over the old contents of the eden to if an object does not meet the age threshold or the amount space I thought would be appropriate for it so that I avoid copying over too many objects and maybe ten other conditions". It's just so much shorter ;) @Kirk: this is very similar to what you described about the IBM collector. > > I.e. to where the next region allocations will occur from. So you will > automatically get the desired effect to some extent. Note that any of the regions in the collection set have just been touched, except in the probably unusual case that it has been completely empty. Maybe a preference of just recently allocated/used regions would in case of tight space improve the situation a little. I.e. it is possible that by choosing the wrong regions the gc could cause paging of other young gen regions that in turn are needed later (paged in + kicking out others all the time). Maybe someone else tried to evaluate that already? Then again, is a configuration that does not even have enough space to keep the young gen in memory a realistic one? (Just thinking loud). Thomas From ysr1729 at gmail.com Fri Oct 26 01:15:40 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 25 Oct 2012 18:15:40 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Vitaly is exactly correct. In my own experience, even for cases of the kind that Bernd is describing, I have always found MTT=1 to be superior to MTT=0, because the cost of promoting objects prematurely can wreak havoc, especially with certain kinds of data structures such as long lists (at least as long as old gens are much larger and old gen collections much more expensive than young gen ones). -- ramki On Thu, Oct 25, 2012 at 2:36 PM, Vitaly Davidovich wrote: > Hmm, collecting old gen usually involves more work than doing young GC > since it may do additional things (e.g. ref processing) as well as being > larger than eden. I think even with concurrent old you probably don't want > to trigger them due to premature promotion (if it's a non-compacting > concurrent GC, like CMS, you may start accumulating fragmentation where you > otherwise wouldn't). Generally, it makes sense to me to have some > buffering in eden to avoid midlife crisis objects wreaking havoc in old gen. > > Sent from my phone > On Oct 25, 2012 5:28 PM, "Bernd Eckenfels" > wrote: > >> Am 25.10.2012, 23:11 Uhr, schrieb Vitaly Davidovich : >> >> You don't want to tenure them prematurely if they ultimately >>> would die fairly soon but you can't keep them in place if you're >>> employing a copying collector. >>> >> >> Actually you might want to tenure them "early": if your oldgen is >> collected concurrently _and_ the young collection frequency is larger than >> a typical transaction (which is a fairly common situation). >> >> Therefore there is an argument for using MaxTenuring=0 (or only 1). But >> thats not really G1 related, I just wanted to mention it. >> >> Bernd >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Oct 26 02:10:33 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Oct 2012 12:10:33 +1000 Subject: Request for review (xs) - 8001584 In-Reply-To: <50895843.8020701@oracle.com> References: <50895843.8020701@oracle.com> Message-ID: <5089F119.3070909@oracle.com> Looks good to me Jon. David On 26/10/2012 1:18 AM, Jon Masamitsu wrote: > 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() > > The assertion > > assert(dither != FreeBlockDictionary::exactly || > res->size() == size, "Not correct size"); > > does not take into account that res may be NULL (as the assertion > above it does). > > http://cr.openjdk.java.net/~jmasa/8001584/webrev.00/ > > or the diff > > --- a/src/share/vm/memory/binaryTreeDictionary.hpp > > +++ b/src/share/vm/memory/binaryTreeDictionary.hpp > > @@ -259,7 +259,7 @@ > > assert(res == NULL || res->is_free(), > > "Should be returning a free chunk"); > > assert(dither != FreeBlockDictionary::exactly || > > - res->size() == size, "Not correct size"); > > + res == NULL || res->size() == size, "Not correct size"); > > return res; > > } > > Thanks. > > Jon From ysr1729 at gmail.com Fri Oct 26 03:40:49 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 25 Oct 2012 20:40:49 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <1351205327.3424.104.camel@tiantang.ssw.uni-linz.ac.at> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <1351203081.3424.80.camel@tiantang.ssw.uni-linz.ac.at> <1351205327.3424.104.camel@tiantang.ssw.uni-linz.ac.at> Message-ID: Thomas, while adding newly freed regions to the head of a common global free region list probably achieves much reuse, I was suggesting something even stronger and deliberate, in that a much smaller set of regions be preferred for repeated reuse for Eden allocation and for reuse as survivor regions, kind of segregating that smaller subset completely from regions used for tenuring objects. On the other hand, that view of object access frequencies is likely much too simplistic, conflating object age with (the inverse of) short-term access frequency. Anyway, with G1+NUMA, I am sure some of these region allocation policies will get somewhat tweaked and revised. -- ramki On Thu, Oct 25, 2012 at 3:48 PM, Thomas Schatzl wrote: > Hi, > > some more info about the implementation which might clear up other > questions. Did not know where to jump in this discussion because of all > that top-posting. > > On Fri, 2012-10-26 at 00:11 +0200, Thomas Schatzl wrote: > > Hi, > > > > On Thu, 2012-10-25 at 10:53 -0700, Srinivas Ramakrishna wrote: > > > > > John might be able to tell us whether or how hard G1 tries to reuse > > > Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 > > > code did not make any such attempts, but G1 has seen many recent > > > improvements since I last looked). > > > > afaik all recently emptied regions (evacuated ones) are first put into > > a list in the order they've been put into the collection set (i.e. the > > regions that were targets for evacuation) and then bulk-added at the > > head of the free region list. > > The collection set in G1 seems to consist of regions in that order: > > [old gen regions +] new young gen/eden regions [+ survivor regions] > > where region types in brackets are optional depending on whether they > are available. > > During that process, survivor regions are relabeled as normal young > gen/eden regions. Very briefly looking through the code the reason why > G1 has explicit survivor regions (it does not have from/to spaces!) > seems to be for statistical reasons which may include that some tools > (or the users :) probably expect the collector to have survivor regions. > > Imo, from a pure evacuation point of view, for g1 the survivor regions > may be considered just as a fancy label for "the regions that I copied > over the old contents of the eden to if an object does not meet the age > threshold or the amount space I thought would be appropriate for it so > that I avoid copying over too many objects and maybe ten other > conditions". It's just so much shorter ;) > > @Kirk: this is very similar to what you described about the IBM > collector. > > > > > I.e. to where the next region allocations will occur from. So you will > > automatically get the desired effect to some extent. > > Note that any of the regions in the collection set have just been > touched, except in the probably unusual case that it has been completely > empty. Maybe a preference of just recently allocated/used regions would > in case of tight space improve the situation a little. I.e. it is > possible that by choosing the wrong regions the gc could cause paging of > other young gen regions that in turn are needed later (paged in + > kicking out others all the time). Maybe someone else tried to evaluate > that already? > > Then again, is a configuration that does not even have enough space to > keep the young gen in memory a realistic one? > > (Just thinking loud). > > Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.coomes at oracle.com Fri Oct 26 03:55:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:55:34 +0000 Subject: hg: hsx/hotspot-gc: 3 new changesets Message-ID: <20121026035534.D4D6647572@hg.openjdk.java.net> Changeset: c12e759ac4e8 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/c12e759ac4e8 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! README-builds.html + make/scripts/fixpath.pl ! make/scripts/vsvars.sh Changeset: 8a3fe0ae06a8 Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8a3fe0ae06a8 Merge Changeset: 4e984be114bd Author: katleman Date: 2012-10-25 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/4e984be114bd Added tag jdk8-b62 for changeset 8a3fe0ae06a8 ! .hgtags From john.coomes at oracle.com Fri Oct 26 03:55:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:55:38 +0000 Subject: hg: hsx/hotspot-gc/corba: 3 new changesets Message-ID: <20121026035542.5C98047573@hg.openjdk.java.net> Changeset: 0a5931be9176 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0a5931be9176 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 08afb9c6f44f Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/08afb9c6f44f Merge Changeset: bbaef650c3d2 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/bbaef650c3d2 Added tag jdk8-b62 for changeset 08afb9c6f44f ! .hgtags From john.coomes at oracle.com Fri Oct 26 03:55:46 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:55:46 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b62 for changeset 5d0fa0108d02 Message-ID: <20121026035554.B805547574@hg.openjdk.java.net> Changeset: a96e34e038f5 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/a96e34e038f5 Added tag jdk8-b62 for changeset 5d0fa0108d02 ! .hgtags From john.coomes at oracle.com Fri Oct 26 03:56:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:56:02 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b62 for changeset d265b9b4c0f5 Message-ID: <20121026035607.4D5E147575@hg.openjdk.java.net> Changeset: c27ea8d489e8 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/c27ea8d489e8 Added tag jdk8-b62 for changeset d265b9b4c0f5 ! .hgtags From john.coomes at oracle.com Fri Oct 26 03:56:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:56:17 +0000 Subject: hg: hsx/hotspot-gc/jdk: 5 new changesets Message-ID: <20121026035759.5B9A647576@hg.openjdk.java.net> Changeset: 61af38b8d4ff Author: twisti Date: 2012-10-19 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/61af38b8d4ff 8000989: smaller code changes to make future JSR 292 backports easier Reviewed-by: jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/PrivateInvokeTest.java Changeset: 7a7e49acadec Author: kamg Date: 2012-10-22 20:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7a7e49acadec 8001225: Disable jdk regression test java/lang/System/Versions.java until jdk's classfile version code is updated Summary: Exclude java/lang/System/Versions.java test Reviewed-by: sspitsyn, coleenp ! test/ProblemList.txt Changeset: a0a2b186ae28 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a0a2b186ae28 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jdk_generic_profile.sh ! make/tools/freetypecheck/Makefile + make/tools/msys_build_scripts/dospath.sh + make/tools/msys_build_scripts/dospath.vbs Changeset: 50b8b17449d2 Author: katleman Date: 2012-10-24 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/50b8b17449d2 Merge Changeset: 65d2c6726487 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/65d2c6726487 Added tag jdk8-b62 for changeset 50b8b17449d2 ! .hgtags From john.coomes at oracle.com Fri Oct 26 03:58:55 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:58:55 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b62 for changeset b47bb81ba962 Message-ID: <20121026035903.D183C47577@hg.openjdk.java.net> Changeset: 16498acd21b5 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/16498acd21b5 Added tag jdk8-b62 for changeset b47bb81ba962 ! .hgtags From kirk at kodewerk.com Fri Oct 26 05:46:10 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 26 Oct 2012 07:46:10 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Hi Vitaly, Well, depending on the livelyness of the region, I would suggest that you simply don't copy. If you do, copy to a new young gen region. Tenure as per the tenuring threshold. As for fragmentation... with regions being so small, would it really be that big a problem? And if so, would it be a problem for very long? IOWs, are we willing to accept a certain level of fragmentation to reduce copy costs? The problem with the current adaptive sizing policy (AFAICT from various production logs) is that it doesn't account for premature promotion and therefore continuously undersizes survivor spaces. Well, with no survivor spaces, no problem.. right? well, not quite.. the tenuring threshold would still have to be calculated in order to have a minimal amount of space retained for new object creation. On 2012-10-25, at 11:11 PM, Vitaly Davidovich wrote: > So if some objects survive young GC and need to be copied so that new allocations are bump the pointer and fragmentation is avoided, where would they be copied to if there's no concept of survivor space (or something akin to it)? You don't want to tenure them prematurely if they ultimately would die fairly soon but you can't keep them in place if you're employing a copying collector. > > Sent from my phone > > On Oct 25, 2012 5:04 PM, "Kirk Pepperdine" wrote: > Not necessarily, IBM doesn't have survivor spaces and they don't promote until they hit a tenuring threshold. They use a hemispheric scheme in young which I'm wondering would even be necessary in G1. For example, objects would get evacuated from a young gen region when they hit a tenuring threshold. Until then young gen regions would get collected based on occupancy just as old gen regions are. Given weak gen hypothesis I'm not sure if there would be a lot of savings here 'cept when you ran into blocks of long lived objects. > > -- Kirk > > On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: > >> Kirk, >> >> Unless I misunderstood your question, not having survivor spaces means you need to promote to tenured which may be undesired for non long-lived objects. The 2 survivor spaces allow for an object to survive a few young GCs and then die before promotion (provided its tenuring threshold is not breached). >> >> Sent from my phone >> >> On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: >> This is a nice explanation... I would think that not necessarly having a to/from survivor space would cut back on some copy costs? >> >> On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna wrote: >> >>> Kirk, Think of Eden as the minimum space available for allocation before a young GC becomes necessary. Think of a survivor space as the minimum space set aside to hold objects surviving in the young generation and not being tenured. G1 does take advantage of the fact that you do not necessarily need to keep the "To" survivor space in reserve separately, but draw from a common pool of free regions. In practice, it might be sensible to reuse recently collected Eden regions (can't recall how hard G1 tries to do that) because it's possible that some caches are warm, but with today's huge young generation sizes, may be it doesn't make sense to talk about cache reuse. In the presence of paging, reusing Eden and survivor pages becomes more important to reduce the cost of inadvertently picking a region whose physical pages may need to be faulted in because they had been paged out or are being touched for the first time. (This may be more important on Windows because of its proclivity to evict pages that haven't been touched in a while even when there is no virtual memory pressure.) >>> >>> John might be able to tell us whether or how hard G1 tries to reuse Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code did not make any such attempts, but G1 has seen many recent improvements since I last looked). >>> >>> -- ramki >>> >>> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >>> Hi Charlie, >>> >>> Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. >>> >>> As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) >>> >>> Regards, >>> Kirk >>> >>> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >>> >>>> Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? >>>> >>>> Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. >>>> >>>> By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. >>>> >>>> Thanks again for the question! >>>> >>>> charlie ... >>>> >>>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>>> >>>>> Thanks Charlie, >>>>> >>>>> I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. >>>>> >>>>> Again, I'm struggling to think of a use case for this behaviour. >>>>> >>>>> Regards, >>>>> Kirk >>>>> >>>>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>>>> >>>>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>>>> >>>>>> A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: >>>>>> - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>>>> - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle >>>>>> * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. >>>>>> - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. >>>>>> >>>>>> charlie ... >>>>>> >>>>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>>>> >>>>>>> Hi Monica, >>>>>>> >>>>>>> Can you comment on what a value of 0 means? >>>>>>> >>>>>>> Regards, >>>>>>> Kirk >>>>>>> >>>>>>> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >>>>>>> >>>>>>>> Couple of quick observations and questions - >>>>>>>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>>>>>>> What do you mean by old gen collection? Are you talking about MixedGCs? >>>>>>>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>>>>>>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>>>>>>> -Monica >>>>>>>> >>>>>>>> >>>>>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>>>>>> >>>>>>>>> Hello All, >>>>>>>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>>>>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>>>>>>> >>>>>>>>> Is there any parameter to force the old gc happening regularly. >>>>>>>>> >>>>>>>>> I am trying following setting, >>>>>>>>> >>>>>>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>>>>>> >>>>>>>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>>>>>>> >>>>>>>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Soumit >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Monica Beckwith | Java Performance Engineer >>>>>>>> VOIP: +1 512 401 1274 >>>>>>>> Texas >>>>>>>> Oracle is committed to developing practices and products that help protect the environment >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 26 05:54:30 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 26 Oct 2012 07:54:30 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: <52610B64-A7D9-412E-AEAF-B3681DE09846@kodewerk.com> Hi Bernd, I would say in all of the GC logs that I've looked at (and we just created and archive of 400 exemplars) from numerous applications I would say that premature tenuring is a significant problem thus suggesting that tenuring thresholds some where north of 4 and south of 8 often are required.. along with much bigger survivor spaces than is currently defaulted. In my tuning of the Scala compiler I was able to knock more than 1 minute off of an 8 minute compile by simply adjusting survivor space size and tenuring threshold. Lets just say that this problem combined with CMS not cleaning perm has been responsible for a number of very nice vacations for my family. ;-) Regards, Kirk On 2012-10-25, at 11:26 PM, "Bernd Eckenfels" wrote: > Am 25.10.2012, 23:11 Uhr, schrieb Vitaly Davidovich : > >> You don't want to tenure them prematurely if they ultimately >> would die fairly soon but you can't keep them in place if you're employing a copying collector. > > Actually you might want to tenure them "early": if your oldgen is collected concurrently _and_ the young collection frequency is larger than a typical transaction (which is a fairly common situation). > > Therefore there is an argument for using MaxTenuring=0 (or only 1). But thats not really G1 related, I just wanted to mention it. > > Bernd From kirk at kodewerk.com Fri Oct 26 05:57:25 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 26 Oct 2012 07:57:25 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: <59F6AD0D-EC81-4FFE-A108-1E3E77E37B23@kodewerk.com> +1 As I stated, a very common problem is survivor to small hence premature promotion causing too frequent Full GCs or a very busy CMS cycle typically ending badly with concurrent mode failures. Regards, Kirk On 2012-10-25, at 11:36 PM, Vitaly Davidovich wrote: > Hmm, collecting old gen usually involves more work than doing young GC since it may do additional things (e.g. ref processing) as well as being larger than eden. I think even with concurrent old you probably don't want to trigger them due to premature promotion (if it's a non-compacting concurrent GC, like CMS, you may start accumulating fragmentation where you otherwise wouldn't). Generally, it makes sense to me to have some buffering in eden to avoid midlife crisis objects wreaking havoc in old gen. > > Sent from my phone > > On Oct 25, 2012 5:28 PM, "Bernd Eckenfels" wrote: > Am 25.10.2012, 23:11 Uhr, schrieb Vitaly Davidovich : > > You don't want to tenure them prematurely if they ultimately > would die fairly soon but you can't keep them in place if you're employing a copying collector. > > Actually you might want to tenure them "early": if your oldgen is collected concurrently _and_ the young collection frequency is larger than a typical transaction (which is a fairly common situation). > > Therefore there is an argument for using MaxTenuring=0 (or only 1). But thats not really G1 related, I just wanted to mention it. > > Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Fri Oct 26 06:15:32 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 25 Oct 2012 23:15:32 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Kirk, Young regions are always collected at each collection pause, and they are not subjected to the global concurrent marking, so you do not really know their liveness a priori, but just start evacuating them on the fly as you discover reachable objects in them, your classic copying collection with no a-priori liveness information. Of course, one could keep track of statistics of where each live object came out of when evacuating it, and build a post-facto map of the statistical distribution of live objects in regions perhaps based on the "age" of those regions (i.e. when they were first allocated out of the free region pool). Then, using stats of that kind one could perhaps make a good guess as to what kind of young region (e.g. the very youngest regions) might typically have a very high liveness ratio and then use that kind of information to avoid evacuating those regions at all, and treating them, e.g. as "from" survivor spaces for the next collection. However, I really don't see those techniques working for tenuring young (survivor) regions into the old generation, unless you are enormously lucky and end up with all objects in a survivor region having the same age, which is unlikely for typical programs. Now, people have played around with the idea of segregating objects by age into age-based regions, and perhaps something like what you envisage might work in those kinds of cases perhaps (but again it would have to be based on measured historical statistics rather than a-priori correctly known liveness information). I'll let John, Thomas et al. correct my misunderstandings on how current G1 works because it's constantly changing and my recollections are necessarily vague, being based on hallway discussions rather than from ever having worked on the code, and from quite a while ago at that, so possibly obsolete. -- ramki On Thu, Oct 25, 2012 at 10:46 PM, Kirk Pepperdine wrote: > Hi Vitaly, > > Well, depending on the livelyness of the region, I would suggest that you > simply don't copy. If you do, copy to a new young gen region. Tenure as per > the tenuring threshold. As for fragmentation... with regions being so > small, would it really be that big a problem? And if so, would it be a > problem for very long? IOWs, are we willing to accept a certain level of > fragmentation to reduce copy costs? > > The problem with the current adaptive sizing policy (AFAICT from various > production logs) is that it doesn't account for premature promotion and > therefore continuously undersizes survivor spaces. Well, with no survivor > spaces, no problem.. right? well, not quite.. the tenuring threshold would > still have to be calculated in order to have a minimal amount of space > retained for new object creation. > > On 2012-10-25, at 11:11 PM, Vitaly Davidovich wrote: > > So if some objects survive young GC and need to be copied so that new > allocations are bump the pointer and fragmentation is avoided, where would > they be copied to if there's no concept of survivor space (or something > akin to it)? You don't want to tenure them prematurely if they ultimately > would die fairly soon but you can't keep them in place if you're employing > a copying collector. > > Sent from my phone > On Oct 25, 2012 5:04 PM, "Kirk Pepperdine" wrote: > >> Not necessarily, IBM doesn't have survivor spaces and they don't promote >> until they hit a tenuring threshold. They use a hemispheric scheme in young >> which I'm wondering would even be necessary in G1. For example, objects >> would get evacuated from a young gen region when they hit a tenuring >> threshold. Until then young gen regions would get collected based on >> occupancy just as old gen regions are. Given weak gen hypothesis I'm not >> sure if there would be a lot of savings here 'cept when you ran into blocks >> of long lived objects. >> >> -- Kirk >> >> On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: >> >> Kirk, >> >> Unless I misunderstood your question, not having survivor spaces means >> you need to promote to tenured which may be undesired for non long-lived >> objects. The 2 survivor spaces allow for an object to survive a few young >> GCs and then die before promotion (provided its tenuring threshold is not >> breached). >> >> Sent from my phone >> On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: >> >>> This is a nice explanation... I would think that not necessarly having a >>> to/from survivor space would cut back on some copy costs? >>> >>> On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna >>> wrote: >>> >>> Kirk, Think of Eden as the minimum space available for allocation before >>> a young GC becomes necessary. Think of a survivor space as the minimum >>> space set aside to hold objects surviving in the young generation and not >>> being tenured. G1 does take advantage of the fact that you do not >>> necessarily need to keep the "To" survivor space in reserve separately, but >>> draw from a common pool of free regions. In practice, it might be sensible >>> to reuse recently collected Eden regions (can't recall how hard G1 tries to >>> do that) because it's possible that some caches are warm, but with today's >>> huge young generation sizes, may be it doesn't make sense to talk about >>> cache reuse. In the presence of paging, reusing Eden and survivor pages >>> becomes more important to reduce the cost of inadvertently picking a region >>> whose physical pages may need to be faulted in because they had been paged >>> out or are being touched for the first time. (This may be more important on >>> Windows because of its proclivity to evict pages that haven't been touched >>> in a while even when there is no virtual memory pressure.) >>> >>> John might be able to tell us whether or how hard G1 tries to reuse >>> Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code >>> did not make any such attempts, but G1 has seen many recent improvements >>> since I last looked). >>> >>> -- ramki >>> >>> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >>> >>>> Hi Charlie, >>>> >>>> Was thinking that as long as you're evacuating regions was there a need >>>> to make a distinction between Eden and survivor... they are all just >>>> regions in young gen. The distinction seems some what artificial. >>>> >>>> As for your use case.. make sense on one hand but on the other I'm >>>> wondering if it's akin to calling System.gc()... time will tell me thinks. >>>> ;-) >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >>>> >>>> Perhaps if you're really, really ... really squeeze on available heap >>>> space and wanted stuff cleaned from old asap, then >>>> InitiatiingHeapOccupancyPercent=0 could be justified? >>>> >>>> Btw, I thought about your question you asked at J1 on "why use survivor >>>> spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with >>>> Monica are free to offer their thoughts as well. >>>> >>>> By using survivor spaces, you should, (and I'd expect that to be the >>>> case) reduce the amount of concurrent cycles you'll do. And, you will >>>> likely more frequently visit more long live objects if you didn't have >>>> survivor spaces as a result of doing more concurrent cycles. In addition, >>>> the total number of different regions you evacuate may be more without >>>> survivor spaces, and you may evacuate the same (live) objects more times >>>> than without survivor spaces. In short, I would expect in most cases you >>>> end evacuating fewer times per object and you end doing fewer concurrent >>>> cycles, all of which saves you CPU cycles for application threads. Of >>>> course, I'm sure we can write an application where it would be advantageous >>>> to not have a survivor spaces in G1. But, we could also write would that >>>> could never have the need for a concurrent cycle in a G1 heap that has >>>> survivor spaces. >>>> >>>> Thanks again for the question! >>>> >>>> charlie ... >>>> >>>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>>> >>>> Thanks Charlie, >>>> >>>> I only had a cursor look at the source and found the initial >>>> calculation but stopped there figuring someone here would know off the top >>>> of their heads. Didn't expect someone to splunk through the code so a big >>>> thanks for that. >>>> >>>> Again, I'm struggling to think of a use case for this behaviour. >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>>> >>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>> >>>> A quick look at the G1 source code suggests that if >>>> InitiatingHeapOccupancyPercent=0, the following will happen: >>>> - the first minor GC will initiate a concurrent cycle implying that >>>> you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>> - every minor GC there after, as long as there is not an active >>>> concurrent cycle, will initiate the start of a concurrent cycle >>>> * So, in other words, concurrent cycles will run back to back. >>>> Remember that there needs to be a minor GC to initiate the concurrent >>>> cycle, i.e. the initial-mark. There is at least one caveat to that which >>>> I'll explain next. So, once a concurrent cycle complete, the next >>>> concurrent cycle will not start, until the next minor GC, or a humongous >>>> allocation occurs as described next. >>>> - If there is a humongous object allocation, a concurrent cycle will be >>>> initiated (if InitiattingHeapOccupancyPercent=0). This is done before the >>>> humongous allocation is done. >>>> >>>> charlie ... >>>> >>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>> >>>> Hi Monica, >>>> >>>> Can you comment on what a value of 0 means? >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 2:55 PM, Monica Beckwith >>>> wrote: >>>> >>>> Couple of quick observations and questions - >>>> >>>> 1. G1 is officially supported in 7u4. (There are numerous >>>> performance improvements that I recommend updating to the latest jdk7 >>>> update, if possible) >>>> 2. What do you mean by old gen collection? Are you talking about >>>> MixedGCs? >>>> 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have >>>> you tried resizing your young generation? >>>> 1. I see the NewRatio, but that fixes the nursery to 640, >>>> instead have you tried with a lower (than the min default) of nursery using >>>> the NewSize option? >>>> >>>> -Monica >>>> >>>> >>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>> >>>> Hello All, >>>> Sorry for posting this question in this mailing list. I am unable to >>>> find any answer for this. I am trying to tune our application for G1GC as >>>> we need very small pauses Below 500msec. >>>> But the problem is when we are runing with G1GC (under jdk 6_u37) >>>> Old generation of garbage collection only happening when it is reaching the >>>> Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close >>>> to 1sec 2GB close to 2 sec pauses. >>>> >>>> Is there any parameter to force the old gc happening regularly. >>>> >>>> I am trying following setting, >>>> >>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 >>>> -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 >>>> -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 >>>> -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>> >>>> If anyone can give insight on how full GC is triggred internals will be >>>> of great help. >>>> >>>> PS: I have tried without any option for G1 but not of much help hence >>>> .. this one trying to be agressive ? but of not much help. >>>> >>>> >>>> Regards, >>>> Soumit >>>> >>>> >>>> -- >>>> >>>> Monica Beckwith | Java Performance Engineer >>>> VOIP: +1 512 401 1274 <+1%20512%20401%201274> >>>> Texas >>>> Oracle >>>> is committed to developing practices and products that help protect the >>>> environment >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Fri Oct 26 06:48:11 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 26 Oct 2012 08:48:11 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Hi Ramki, Ok, if you put it that way..... I can see that maybe the copy cost would be the worst of the evils. But I can't help thinking that things are less random than you might expect. I think this would definitely require some experimentation. Thanks, Kirk On 2012-10-26, at 8:15 AM, Srinivas Ramakrishna wrote: > Kirk, Young regions are always collected at each collection pause, and they are not subjected to the global concurrent marking, > so you do not really know their liveness a priori, but just start evacuating them on the fly as you discover reachable objects in them, > your classic copying collection with no a-priori liveness information. > > Of course, one could keep track of statistics of where each live object came out of when evacuating it, and build > a post-facto map of the statistical distribution of live objects in regions perhaps based on the "age" of those regions (i.e. > when they were first allocated out of the free region pool). Then, using stats of that kind one could perhaps make a good > guess as to what kind of young region (e.g. the very youngest regions) might typically have a very high liveness ratio and then > use that kind of information to avoid evacuating those regions at all, and treating them, e.g. as > "from" survivor spaces for the next collection. However, I really don't see those techniques working for tenuring > young (survivor) regions into the old generation, unless you are enormously lucky and end up with all objects in > a survivor region having the same age, which is unlikely for typical programs. Now, people have played around with the > idea of segregating objects by age into age-based regions, and perhaps something like what you envisage might work in > those kinds of cases perhaps (but again it would have to be based on measured historical statistics rather than a-priori > correctly known liveness information). > > I'll let John, Thomas et al. correct my misunderstandings on how current G1 works because it's constantly changing and > my recollections are necessarily vague, being based on hallway discussions rather than from ever having worked on the code, > and from quite a while ago at that, so possibly obsolete. > > -- ramki > > On Thu, Oct 25, 2012 at 10:46 PM, Kirk Pepperdine wrote: > Hi Vitaly, > > Well, depending on the livelyness of the region, I would suggest that you simply don't copy. If you do, copy to a new young gen region. Tenure as per the tenuring threshold. As for fragmentation... with regions being so small, would it really be that big a problem? And if so, would it be a problem for very long? IOWs, are we willing to accept a certain level of fragmentation to reduce copy costs? > > The problem with the current adaptive sizing policy (AFAICT from various production logs) is that it doesn't account for premature promotion and therefore continuously undersizes survivor spaces. Well, with no survivor spaces, no problem.. right? well, not quite.. the tenuring threshold would still have to be calculated in order to have a minimal amount of space retained for new object creation. > > On 2012-10-25, at 11:11 PM, Vitaly Davidovich wrote: > >> So if some objects survive young GC and need to be copied so that new allocations are bump the pointer and fragmentation is avoided, where would they be copied to if there's no concept of survivor space (or something akin to it)? You don't want to tenure them prematurely if they ultimately would die fairly soon but you can't keep them in place if you're employing a copying collector. >> >> Sent from my phone >> >> On Oct 25, 2012 5:04 PM, "Kirk Pepperdine" wrote: >> Not necessarily, IBM doesn't have survivor spaces and they don't promote until they hit a tenuring threshold. They use a hemispheric scheme in young which I'm wondering would even be necessary in G1. For example, objects would get evacuated from a young gen region when they hit a tenuring threshold. Until then young gen regions would get collected based on occupancy just as old gen regions are. Given weak gen hypothesis I'm not sure if there would be a lot of savings here 'cept when you ran into blocks of long lived objects. >> >> -- Kirk >> >> On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: >> >>> Kirk, >>> >>> Unless I misunderstood your question, not having survivor spaces means you need to promote to tenured which may be undesired for non long-lived objects. The 2 survivor spaces allow for an object to survive a few young GCs and then die before promotion (provided its tenuring threshold is not breached). >>> >>> Sent from my phone >>> >>> On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: >>> This is a nice explanation... I would think that not necessarly having a to/from survivor space would cut back on some copy costs? >>> >>> On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna wrote: >>> >>>> Kirk, Think of Eden as the minimum space available for allocation before a young GC becomes necessary. Think of a survivor space as the minimum space set aside to hold objects surviving in the young generation and not being tenured. G1 does take advantage of the fact that you do not necessarily need to keep the "To" survivor space in reserve separately, but draw from a common pool of free regions. In practice, it might be sensible to reuse recently collected Eden regions (can't recall how hard G1 tries to do that) because it's possible that some caches are warm, but with today's huge young generation sizes, may be it doesn't make sense to talk about cache reuse. In the presence of paging, reusing Eden and survivor pages becomes more important to reduce the cost of inadvertently picking a region whose physical pages may need to be faulted in because they had been paged out or are being touched for the first time. (This may be more important on Windows because of its proclivity to evict pages that haven't been touched in a while even when there is no virtual memory pressure.) >>>> >>>> John might be able to tell us whether or how hard G1 tries to reuse Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code did not make any such attempts, but G1 has seen many recent improvements since I last looked). >>>> >>>> -- ramki >>>> >>>> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >>>> Hi Charlie, >>>> >>>> Was thinking that as long as you're evacuating regions was there a need to make a distinction between Eden and survivor... they are all just regions in young gen. The distinction seems some what artificial. >>>> >>>> As for your use case.. make sense on one hand but on the other I'm wondering if it's akin to calling System.gc()... time will tell me thinks. ;-) >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >>>> >>>>> Perhaps if you're really, really ... really squeeze on available heap space and wanted stuff cleaned from old asap, then InitiatiingHeapOccupancyPercent=0 could be justified? >>>>> >>>>> Btw, I thought about your question you asked at J1 on "why use survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along with Monica are free to offer their thoughts as well. >>>>> >>>>> By using survivor spaces, you should, (and I'd expect that to be the case) reduce the amount of concurrent cycles you'll do. And, you will likely more frequently visit more long live objects if you didn't have survivor spaces as a result of doing more concurrent cycles. In addition, the total number of different regions you evacuate may be more without survivor spaces, and you may evacuate the same (live) objects more times than without survivor spaces. In short, I would expect in most cases you end evacuating fewer times per object and you end doing fewer concurrent cycles, all of which saves you CPU cycles for application threads. Of course, I'm sure we can write an application where it would be advantageous to not have a survivor spaces in G1. But, we could also write would that could never have the need for a concurrent cycle in a G1 heap that has survivor spaces. >>>>> >>>>> Thanks again for the question! >>>>> >>>>> charlie ... >>>>> >>>>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>>>> >>>>>> Thanks Charlie, >>>>>> >>>>>> I only had a cursor look at the source and found the initial calculation but stopped there figuring someone here would know off the top of their heads. Didn't expect someone to splunk through the code so a big thanks for that. >>>>>> >>>>>> Again, I'm struggling to think of a use case for this behaviour. >>>>>> >>>>>> Regards, >>>>>> Kirk >>>>>> >>>>>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>>>>> >>>>>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>>>>> >>>>>>> A quick look at the G1 source code suggests that if InitiatingHeapOccupancyPercent=0, the following will happen: >>>>>>> - the first minor GC will initiate a concurrent cycle implying that you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>>>>> - every minor GC there after, as long as there is not an active concurrent cycle, will initiate the start of a concurrent cycle >>>>>>> * So, in other words, concurrent cycles will run back to back. Remember that there needs to be a minor GC to initiate the concurrent cycle, i.e. the initial-mark. There is at least one caveat to that which I'll explain next. So, once a concurrent cycle complete, the next concurrent cycle will not start, until the next minor GC, or a humongous allocation occurs as described next. >>>>>>> - If there is a humongous object allocation, a concurrent cycle will be initiated (if InitiattingHeapOccupancyPercent=0). This is done before the humongous allocation is done. >>>>>>> >>>>>>> charlie ... >>>>>>> >>>>>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>>>>> >>>>>>>> Hi Monica, >>>>>>>> >>>>>>>> Can you comment on what a value of 0 means? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Kirk >>>>>>>> >>>>>>>> On 2012-10-19, at 2:55 PM, Monica Beckwith wrote: >>>>>>>> >>>>>>>>> Couple of quick observations and questions - >>>>>>>>> G1 is officially supported in 7u4. (There are numerous performance improvements that I recommend updating to the latest jdk7 update, if possible) >>>>>>>>> What do you mean by old gen collection? Are you talking about MixedGCs? >>>>>>>>> Instead of setting InitiatingHeapOccupancyPercent to zero, have you tried resizing your young generation? >>>>>>>>> I see the NewRatio, but that fixes the nursery to 640, instead have you tried with a lower (than the min default) of nursery using the NewSize option? >>>>>>>>> -Monica >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>>>>>>> >>>>>>>>>> Hello All, >>>>>>>>>> Sorry for posting this question in this mailing list. I am unable to find any answer for this. I am trying to tune our application for G1GC as we need very small pauses Below 500msec. >>>>>>>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) Old generation of garbage collection only happening when it is reaching the Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close to 1sec 2GB close to 2 sec pauses. >>>>>>>>>> >>>>>>>>>> Is there any parameter to force the old gc happening regularly. >>>>>>>>>> >>>>>>>>>> I am trying following setting, >>>>>>>>>> >>>>>>>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>>>>>>> >>>>>>>>>> If anyone can give insight on how full GC is triggred internals will be of great help. >>>>>>>>>> >>>>>>>>>> PS: I have tried without any option for G1 but not of much help hence .. this one trying to be agressive ? but of not much help. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Soumit >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Monica Beckwith | Java Performance Engineer >>>>>>>>> VOIP: +1 512 401 1274 >>>>>>>>> Texas >>>>>>>>> Oracle is committed to developing practices and products that help protect the environment >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.x.helin at oracle.com Fri Oct 26 07:45:25 2012 From: erik.x.helin at oracle.com (Erik Helin) Date: Fri, 26 Oct 2012 09:45:25 +0200 Subject: RFR (S): 8001564: The load balancing function steal_1_random in taskqueue is not random Message-ID: <508A3F95.90608@oracle.com> Hi everyone, the webrev can be found at: http://cr.openjdk.java.net/~brutisso/8001564/webrev.00/ Summary: There are three different algorithms in taskqueue.hpp for stealing an item from a taskqueue: - steal_best_of_2 - steal_best_of_all - steal_1_random However only steal_best_of_2 is currently in use, steal_best_of_all and steal_1_random are not used at all (not anywhere in the hotspot source code). Furthermore the function steal_1_random has a bug in it, as explained in 8001564. This change removes the functions steal_best_of_all and steal_1_random, thereby preventing bit rot as in the case of steal_1_random and also fixing bug 8001564. Testing: JPRT Thanks, Erik From bengt.rutisson at oracle.com Fri Oct 26 08:08:36 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 26 Oct 2012 10:08:36 +0200 Subject: RFR (S): 8001564: The load balancing function steal_1_random in taskqueue is not random In-Reply-To: <508A3F95.90608@oracle.com> References: <508A3F95.90608@oracle.com> Message-ID: <508A4504.4070207@oracle.com> Erik, Looks good! Good to remove untested code that has already started to bit rot. Bengt On 2012-10-26 09:45, Erik Helin wrote: > Hi everyone, > > the webrev can be found at: > > http://cr.openjdk.java.net/~brutisso/8001564/webrev.00/ > > Summary: > There are three different algorithms in taskqueue.hpp for stealing an > item from a taskqueue: > - steal_best_of_2 > - steal_best_of_all > - steal_1_random > > However only steal_best_of_2 is currently in use, steal_best_of_all > and steal_1_random are not used at all (not anywhere in the hotspot > source code). > > Furthermore the function steal_1_random has a bug in it, as explained > in 8001564. > > This change removes the functions steal_best_of_all and > steal_1_random, thereby preventing bit rot as in the case of > steal_1_random and also fixing bug 8001564. > > Testing: > JPRT > > Thanks, > Erik From vitalyd at gmail.com Fri Oct 26 12:02:54 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 26 Oct 2012 08:02:54 -0400 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <09407E71-9FC2-45A7-A596-9828DC3C60D8@kodewerk.com> <59BA54D4-5090-41B3-9949-E923E9E9EA3D@kodewerk.com> Message-ID: Hi Kirk, Not sure how much I can add given Ramki's excellent replies, but I've never seen copying being a big problem on the heap sizes I use (~2.5-3g eden). The reason is that young GC cost, as you know, is a function of the amount of live data. If the application satisfies the generational hypothesis and the heap sizes are properly tuned to ensure that when eden fills up there aren't many survivors, the copying cost of the remaining few survivors is very cheap (relatively speaking). In other words, in a properly tuned app the copy cost should be minimal. Now, if you did have liveness stats a priori, as Ramki says, you could potentially do better by not moving regions that are completely full of survivors and simply treat them as survivor space. But then you have to weigh the cost of this bookkeeping both in terms of CPU and extra memory required. As for regions that have a mix of survivors and dead objects, you do need evacuation so that the region can be used for bump allocation; if you fragment it by not moving survivors, you lose this fast alloc capability. So in the common case I'd venture you won't find regions completely full of survivors (even if they're age based) unless the allocation patterns and heap tuning of the application are just lucky/fortunate enough to be spot on; therefore, you'll almost always have to do some copying. Thanks Sent from my phone On Oct 26, 2012 2:48 AM, "Kirk Pepperdine" wrote: > Hi Ramki, > > Ok, if you put it that way..... I can see that maybe the copy cost would > be the worst of the evils. But I can't help thinking that things are less > random than you might expect. I think this would definitely require some > experimentation. > > Thanks, > Kirk > > On 2012-10-26, at 8:15 AM, Srinivas Ramakrishna wrote: > > Kirk, Young regions are always collected at each collection pause, and > they are not subjected to the global concurrent marking, > so you do not really know their liveness a priori, but just start > evacuating them on the fly as you discover reachable objects in them, > your classic copying collection with no a-priori liveness information. > > Of course, one could keep track of statistics of where each live object > came out of when evacuating it, and build > a post-facto map of the statistical distribution of live objects in > regions perhaps based on the "age" of those regions (i.e. > when they were first allocated out of the free region pool). Then, using > stats of that kind one could perhaps make a good > guess as to what kind of young region (e.g. the very youngest regions) > might typically have a very high liveness ratio and then > use that kind of information to avoid evacuating those regions at all, and > treating them, e.g. as > "from" survivor spaces for the next collection. However, I really don't > see those techniques working for tenuring > young (survivor) regions into the old generation, unless you are > enormously lucky and end up with all objects in > a survivor region having the same age, which is unlikely for typical > programs. Now, people have played around with the > idea of segregating objects by age into age-based regions, and perhaps > something like what you envisage might work in > those kinds of cases perhaps (but again it would have to be based on > measured historical statistics rather than a-priori > correctly known liveness information). > > I'll let John, Thomas et al. correct my misunderstandings on how current > G1 works because it's constantly changing and > my recollections are necessarily vague, being based on hallway discussions > rather than from ever having worked on the code, > and from quite a while ago at that, so possibly obsolete. > > -- ramki > > On Thu, Oct 25, 2012 at 10:46 PM, Kirk Pepperdine wrote: > >> Hi Vitaly, >> >> Well, depending on the livelyness of the region, I would suggest that you >> simply don't copy. If you do, copy to a new young gen region. Tenure as per >> the tenuring threshold. As for fragmentation... with regions being so >> small, would it really be that big a problem? And if so, would it be a >> problem for very long? IOWs, are we willing to accept a certain level of >> fragmentation to reduce copy costs? >> >> The problem with the current adaptive sizing policy (AFAICT from various >> production logs) is that it doesn't account for premature promotion and >> therefore continuously undersizes survivor spaces. Well, with no survivor >> spaces, no problem.. right? well, not quite.. the tenuring threshold would >> still have to be calculated in order to have a minimal amount of space >> retained for new object creation. >> >> On 2012-10-25, at 11:11 PM, Vitaly Davidovich wrote: >> >> So if some objects survive young GC and need to be copied so that new >> allocations are bump the pointer and fragmentation is avoided, where would >> they be copied to if there's no concept of survivor space (or something >> akin to it)? You don't want to tenure them prematurely if they ultimately >> would die fairly soon but you can't keep them in place if you're employing >> a copying collector. >> >> Sent from my phone >> On Oct 25, 2012 5:04 PM, "Kirk Pepperdine" wrote: >> >>> Not necessarily, IBM doesn't have survivor spaces and they don't promote >>> until they hit a tenuring threshold. They use a hemispheric scheme in young >>> which I'm wondering would even be necessary in G1. For example, objects >>> would get evacuated from a young gen region when they hit a tenuring >>> threshold. Until then young gen regions would get collected based on >>> occupancy just as old gen regions are. Given weak gen hypothesis I'm not >>> sure if there would be a lot of savings here 'cept when you ran into blocks >>> of long lived objects. >>> >>> -- Kirk >>> >>> On 2012-10-25, at 10:58 PM, Vitaly Davidovich wrote: >>> >>> Kirk, >>> >>> Unless I misunderstood your question, not having survivor spaces means >>> you need to promote to tenured which may be undesired for non long-lived >>> objects. The 2 survivor spaces allow for an object to survive a few young >>> GCs and then die before promotion (provided its tenuring threshold is not >>> breached). >>> >>> Sent from my phone >>> On Oct 25, 2012 4:43 PM, "Kirk Pepperdine" wrote: >>> >>>> This is a nice explanation... I would think that not necessarly having >>>> a to/from survivor space would cut back on some copy costs? >>>> >>>> On 2012-10-25, at 7:53 PM, Srinivas Ramakrishna >>>> wrote: >>>> >>>> Kirk, Think of Eden as the minimum space available for allocation >>>> before a young GC becomes necessary. Think of a survivor space as the >>>> minimum space set aside to hold objects surviving in the young generation >>>> and not being tenured. G1 does take advantage of the fact that you do not >>>> necessarily need to keep the "To" survivor space in reserve separately, but >>>> draw from a common pool of free regions. In practice, it might be sensible >>>> to reuse recently collected Eden regions (can't recall how hard G1 tries to >>>> do that) because it's possible that some caches are warm, but with today's >>>> huge young generation sizes, may be it doesn't make sense to talk about >>>> cache reuse. In the presence of paging, reusing Eden and survivor pages >>>> becomes more important to reduce the cost of inadvertently picking a region >>>> whose physical pages may need to be faulted in because they had been paged >>>> out or are being touched for the first time. (This may be more important on >>>> Windows because of its proclivity to evict pages that haven't been touched >>>> in a while even when there is no virtual memory pressure.) >>>> >>>> John might be able to tell us whether or how hard G1 tries to reuse >>>> Eden/Survivor pages (I had often lobbied for that because AFAIR old G1 code >>>> did not make any such attempts, but G1 has seen many recent improvements >>>> since I last looked). >>>> >>>> -- ramki >>>> >>>> On Fri, Oct 19, 2012 at 12:38 PM, Kirk Pepperdine wrote: >>>> >>>>> Hi Charlie, >>>>> >>>>> Was thinking that as long as you're evacuating regions was there a >>>>> need to make a distinction between Eden and survivor... they are all just >>>>> regions in young gen. The distinction seems some what artificial. >>>>> >>>>> As for your use case.. make sense on one hand but on the other I'm >>>>> wondering if it's akin to calling System.gc()... time will tell me thinks. >>>>> ;-) >>>>> >>>>> Regards, >>>>> Kirk >>>>> >>>>> On 2012-10-19, at 9:28 PM, Charlie Hunt wrote: >>>>> >>>>> Perhaps if you're really, really ... really squeeze on available heap >>>>> space and wanted stuff cleaned from old asap, then >>>>> InitiatiingHeapOccupancyPercent=0 could be justified? >>>>> >>>>> Btw, I thought about your question you asked at J1 on "why use >>>>> survivor spaces with G1?" ... I'll offer an answer, John Cu or Bengt along >>>>> with Monica are free to offer their thoughts as well. >>>>> >>>>> By using survivor spaces, you should, (and I'd expect that to be the >>>>> case) reduce the amount of concurrent cycles you'll do. And, you will >>>>> likely more frequently visit more long live objects if you didn't have >>>>> survivor spaces as a result of doing more concurrent cycles. In addition, >>>>> the total number of different regions you evacuate may be more without >>>>> survivor spaces, and you may evacuate the same (live) objects more times >>>>> than without survivor spaces. In short, I would expect in most cases you >>>>> end evacuating fewer times per object and you end doing fewer concurrent >>>>> cycles, all of which saves you CPU cycles for application threads. Of >>>>> course, I'm sure we can write an application where it would be advantageous >>>>> to not have a survivor spaces in G1. But, we could also write would that >>>>> could never have the need for a concurrent cycle in a G1 heap that has >>>>> survivor spaces. >>>>> >>>>> Thanks again for the question! >>>>> >>>>> charlie ... >>>>> >>>>> On Oct 19, 2012, at 2:16 PM, Kirk Pepperdine wrote: >>>>> >>>>> Thanks Charlie, >>>>> >>>>> I only had a cursor look at the source and found the initial >>>>> calculation but stopped there figuring someone here would know off the top >>>>> of their heads. Didn't expect someone to splunk through the code so a big >>>>> thanks for that. >>>>> >>>>> Again, I'm struggling to think of a use case for this behaviour. >>>>> >>>>> Regards, >>>>> Kirk >>>>> >>>>> On 2012-10-19, at 8:56 PM, Charlie Hunt wrote: >>>>> >>>>> Don't mean to jump in front of Monica. :-/ But, she can confirm. ;-) >>>>> >>>>> A quick look at the G1 source code suggests that if >>>>> InitiatingHeapOccupancyPercent=0, the following will happen: >>>>> - the first minor GC will initiate a concurrent cycle implying that >>>>> you'll see a young GC with an initial-mark in the GC log w/ +PrintGCDetails >>>>> - every minor GC there after, as long as there is not an active >>>>> concurrent cycle, will initiate the start of a concurrent cycle >>>>> * So, in other words, concurrent cycles will run back to back. >>>>> Remember that there needs to be a minor GC to initiate the concurrent >>>>> cycle, i.e. the initial-mark. There is at least one caveat to that which >>>>> I'll explain next. So, once a concurrent cycle complete, the next >>>>> concurrent cycle will not start, until the next minor GC, or a humongous >>>>> allocation occurs as described next. >>>>> - If there is a humongous object allocation, a concurrent cycle will >>>>> be initiated (if InitiattingHeapOccupancyPercent=0). This is done before >>>>> the humongous allocation is done. >>>>> >>>>> charlie ... >>>>> >>>>> On Oct 19, 2012, at 12:58 PM, Kirk Pepperdine wrote: >>>>> >>>>> Hi Monica, >>>>> >>>>> Can you comment on what a value of 0 means? >>>>> >>>>> Regards, >>>>> Kirk >>>>> >>>>> On 2012-10-19, at 2:55 PM, Monica Beckwith >>>>> wrote: >>>>> >>>>> Couple of quick observations and questions - >>>>> >>>>> 1. G1 is officially supported in 7u4. (There are numerous >>>>> performance improvements that I recommend updating to the latest jdk7 >>>>> update, if possible) >>>>> 2. What do you mean by old gen collection? Are you talking about >>>>> MixedGCs? >>>>> 3. Instead of setting InitiatingHeapOccupancyPercent to zero, have >>>>> you tried resizing your young generation? >>>>> 1. I see the NewRatio, but that fixes the nursery to 640, >>>>> instead have you tried with a lower (than the min default) of nursery using >>>>> the NewSize option? >>>>> >>>>> -Monica >>>>> >>>>> >>>>> On 10/19/2012 12:13 AM, csewhiz wrote: >>>>> >>>>> Hello All, >>>>> Sorry for posting this question in this mailing list. I am unable to >>>>> find any answer for this. I am trying to tune our application for G1GC as >>>>> we need very small pauses Below 500msec. >>>>> But the problem is when we are runing with G1GC (under jdk 6_u37) >>>>> Old generation of garbage collection only happening when it is reaching the >>>>> Max GC size I noticed on jdk 6U 37 if max heap size is 1GB then it is close >>>>> to 1sec 2GB close to 2 sec pauses. >>>>> >>>>> Is there any parameter to force the old gc happening regularly. >>>>> >>>>> I am trying following setting, >>>>> >>>>> -Xms1280M -Xmx1280M -XX:+UseG1GC -XX:MaxTenuringThreshold=15 >>>>> -XX:SurvivorRatio=8 -XX:NewRatio=1 -XX:GCPauseIntervalMillis=7500 >>>>> -XX:MaxGCPauseMillis=500 -XX:InitiatingHeapOccupancyPercent=0 >>>>> -XX:ParallelGCThreads=7 -XX:ConcGCThreads=7 >>>>> >>>>> If anyone can give insight on how full GC is triggred internals will >>>>> be of great help. >>>>> >>>>> PS: I have tried without any option for G1 but not of much help hence >>>>> .. this one trying to be agressive ? but of not much help. >>>>> >>>>> >>>>> Regards, >>>>> Soumit >>>>> >>>>> >>>>> -- >>>>> >>>>> Monica Beckwith | Java Performance Engineer >>>>> VOIP: +1 512 401 1274 <+1%20512%20401%201274> >>>>> Texas >>>>> Oracle >>>>> is committed to developing practices and products that help protect the >>>>> environment >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.murillo at oracle.com Sat Oct 27 10:51:30 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 27 Oct 2012 10:51:30 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 22 new changesets Message-ID: <20121027105222.0A09947628@hg.openjdk.java.net> Changeset: 556dd9e475c6 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/556dd9e475c6 Added tag jdk8-b62 for changeset dccd40de8db1 ! .hgtags Changeset: 85916677fc22 Author: coleenp Date: 2012-10-18 13:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/85916677fc22 7188233: UseVMInterruptibleIO flag deprecate for JDK8 Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8. The flag will still enable Interruptible IO on Solaris, but users will get a warning. Reviewed-by: dholmes, acorn, alanb Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 8ebcedb7604d Author: coleenp Date: 2012-10-18 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8ebcedb7604d 7053130: hs_err file does not record specified CLASSPATH Summary: Added code to write the value of the java.class.path property to the hs_err file. Reviewed-by: kmo, dholmes, kvn Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: c7957b458bf8 Author: minqi Date: 2012-10-19 08:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c7957b458bf8 8000818: SA constant pool need to reference to reference map after permgen removal Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java Changeset: 8eeffbc22f10 Author: minqi Date: 2012-10-19 08:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8eeffbc22f10 8001055: Bytes.swap should follow big endian Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java Changeset: 716c64bda5ba Author: zgu Date: 2012-10-19 21:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/716c64bda5ba 7199092: NMT: NMT needs to deal overlapped virtual memory ranges Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map. Reviewed-by: acorn, coleenp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b988bff99b38 Author: zgu Date: 2012-10-19 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b988bff99b38 Merge Changeset: 80f44792c0c9 Author: coleenp Date: 2012-10-22 12:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/80f44792c0c9 Merge Changeset: b58313cf9afd Author: jcoomes Date: 2012-10-26 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b58313cf9afd Merge Changeset: cfe522e6461c Author: kvn Date: 2012-10-17 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cfe522e6461c 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space Summary: Fix type of method pointer load from vtable. Reviewed-by: twisti, johnc, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp Changeset: e81a8af10cd9 Author: kvn Date: 2012-10-18 07:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e81a8af10cd9 8001071: Add simple range check into VM implemenation of Unsafe access methods Summary: Add simple check in debug version of VM. Reviewed-by: twisti, johnc ! src/share/vm/prims/unsafe.cpp Changeset: aaeb9add1ab3 Author: dlong Date: 2012-10-19 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aaeb9add1ab3 8001101: C2: more general vector rule subsetting Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms. Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/type.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 67f4c477c9ab Author: vlivanov Date: 2012-10-22 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/67f4c477c9ab 8000805: JMM issue: short loads are non-atomic Summary: perform transforms during IGVN phase when Load has a single user. Reviewed-by: jrose, kvn, twisti ! src/share/vm/opto/mulnode.cpp + test/compiler/8000805/Test8000805.java Changeset: fd1d564dd460 Author: twisti Date: 2012-10-22 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fd1d564dd460 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: b2c669fd8114 Author: kvn Date: 2012-10-23 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b2c669fd8114 8001183: incorrect results of char vectors right shift operaiton Summary: do vector right shift operation for small int types only after loads Reviewed-by: jrose, dlong ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! test/compiler/6340864/TestByteVect.java ! test/compiler/6340864/TestIntVect.java ! test/compiler/6340864/TestLongVect.java ! test/compiler/6340864/TestShortVect.java + test/compiler/8001183/TestCharVect.java Changeset: a3ecd773a7b9 Author: kvn Date: 2012-10-24 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a3ecd773a7b9 7184394: add intrinsics to use AES instructions Summary: Use new x86 AES instructions for AESCrypt. Reviewed-by: twisti, kvn, roland Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7184394/TestAESBase.java + test/compiler/7184394/TestAESDecode.java + test/compiler/7184394/TestAESEncode.java + test/compiler/7184394/TestAESMain.java Changeset: 006174cfe979 Author: kvn Date: 2012-10-25 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/006174cfe979 7163534: VM could crashes assert(false) failed: infinite EA connection graph build Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. Reviewed-by: twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/escape.cpp Changeset: 410afdc6a07c Author: kvn Date: 2012-10-26 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/410afdc6a07c 8001635: assert(in_bb(n)) failed: must be Summary: Added missed check that Load node is in processed loop block. Reviewed-by: twisti ! src/share/vm/opto/superword.cpp Changeset: 588f08ed16cf Author: kvn Date: 2012-10-26 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/588f08ed16cf Merge ! src/share/vm/runtime/globals.hpp Changeset: dc16fe422c53 Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dc16fe422c53 Merge Changeset: 57c61f87a1fd Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/57c61f87a1fd Added tag hs25-b07 for changeset dc16fe422c53 ! .hgtags Changeset: a516debe2cee Author: amurillo Date: 2012-10-26 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a516debe2cee 8001663: new hotspot build - hs25-b08 Reviewed-by: jcoomes ! make/hotspot_version From thomas.schatzl at jku.at Sat Oct 27 19:42:37 2012 From: thomas.schatzl at jku.at (Thomas Schatzl) Date: Sat, 27 Oct 2012 21:42:37 +0200 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <1351203081.3424.80.camel@tiantang.ssw.uni-linz.ac.at> <1351205327.3424.104.camel@tiantang.ssw.uni-linz.ac.at> Message-ID: <1351366957.2175.29.camel@tiantang.ssw.uni-linz.ac.at> Hi, On Thu, 2012-10-25 at 20:40 -0700, Srinivas Ramakrishna wrote: > Thomas, while adding newly freed regions to the head of a common > global free region list probably achieves much reuse, I was > suggesting something even stronger and deliberate, in that a much > smaller set of regions be preferred for repeated reuse for Eden > allocation and for reuse as survivor regions, kind of > segregating that smaller subset completely from regions used for > tenuring objects. What I mean is, that to exploit cache effects in the way you suggest, these areas must be much smaller than you suggest; on multi-GB ranges of memory you likely won't benefit from them any more than now. NUMA awareness does not change that, especially because you typically use NUMA on machines because you want to use lots of memory. I.e. just a quick calculation: with NUMA awareness, the amount of memory touched per node/core is likely still too high to benefit a lot from caching. E.g. a 64GB eden divided across 8 nodes still means you're touching 8GB/node with processors that have a few MB of cache each. In the best case. NUMA awareness does not improve upon cacheability (it might as a secondary effect!), but its main point is to improve access to memory beyond the caches imo. One idea where you exploit cache effects by giving each thread/core a very small heap with eden (typically <= 1 MB, i.e. something that fits nicely into the cache) that is reused like you suggest over and over again is generally referred to as "thread local heaps". The problem is, that the threshold to get improvements is much higher than with NUMA awareness. If a thread only has such a small eden, you cannot stop all threads every time it fills up any more, because that would naturally decrease throughput too much. I.e. it needs thread local gcs (so that every thread can collect its own heap without stopping the others) and associated complexity in the VM to work efficiently though. This is not meant to discourage you about NUMA awareness, just a try to clear up things (if there ever was something to clear up). NUMA awareness does have its use and it improves performance, but I don't think it mainly does so because of improved cachability. Thomas From chunt at salesforce.com Mon Oct 29 15:06:55 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Mon, 29 Oct 2012 08:06:55 -0700 Subject: -XX:+TraceClassUnloading enabled w/ -Xloggc ? Message-ID: <1AC081A5-5F23-4DF6-AC47-50CF111C5010@salesforce.com> We stumbled across this last week ... and now curious. With -Xloggc, -XX:+TraceClassUnloading is also enabled. But, with other GC related command line options such as; -XX:+PrintGCDetails, -XX:+PrintGC, -XX:+PrintHeapAtGC, etc. -XX:-TraceClassUnloading remains disabled by default. Anyone know the history that led to the decision to only enable +TraceClassUnloading with -Xloggc, and not with say +PrintGCDetails? thanks, charlie ... From ysr1729 at gmail.com Mon Oct 29 16:01:54 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 29 Oct 2012 09:01:54 -0700 Subject: Question regarding G1 option to run parallel Old generation garbage collection? In-Reply-To: <1351366957.2175.29.camel@tiantang.ssw.uni-linz.ac.at> References: <13a7770622f.3368361147554026191.2919233442948217281@zoho.com> <50814DC1.6010602@oracle.com> <1A6AB65C-E2AB-483C-9533-17BA577BA693@kodewerk.com> <84E37B82-48F5-49B6-9CB3-F3AC0C54DA60@salesforce.com> <38314D3C-8A86-45A9-92FD-3D4C2F7060FD@kodewerk.com> <1351203081.3424.80.camel@tiantang.ssw.uni-linz.ac.at> <1351205327.3424.104.camel@tiantang.ssw.uni-linz.ac.at> <1351366957.2175.29.camel@tiantang.ssw.uni-linz.ac.at> Message-ID: Umm, i don't think I said anything about cache effects in the passage you quoted bwlo. I said we should prefer using a small VA range, so a small set of physical pages would suffice. You may have conflated an earlier reference in passing to caches (and its immediate rejection in the same breath) with the discussion about phytsical pages that followed. My reference to NUMA was that the allocation code would likely be affected and we could expect to see some changes as a result of it, which would be a good time to review the repeated reuse of VA range for young gen allocation..Anyway, hopefully we both know what we mean, and there is no misunderstanding. best regards. -- ramki On Sat, Oct 27, 2012 at 12:42 PM, Thomas Schatzl wrote: > Hi, > > On Thu, 2012-10-25 at 20:40 -0700, Srinivas Ramakrishna wrote: > > Thomas, while adding newly freed regions to the head of a common > > global free region list probably achieves much reuse, I was > > suggesting something even stronger and deliberate, in that a much > > smaller set of regions be preferred for repeated reuse for Eden > > allocation and for reuse as survivor regions, kind of > > segregating that smaller subset completely from regions used for > > tenuring objects. > > What I mean is, that to exploit cache effects in the way you > suggest, these areas must be much smaller than you suggest; on > multi-GB ranges of memory you likely won't benefit from them any > more than now. NUMA awareness does not change that, especially > because you typically use NUMA on machines because you want to > use lots of memory. > > I.e. just a quick calculation: with NUMA awareness, the amount > of memory touched per node/core is likely still too high to > benefit a lot from caching. E.g. a 64GB eden divided across 8 > nodes still means you're touching 8GB/node with processors that > have a few MB of cache each. In the best case. > > NUMA awareness does not improve upon cacheability (it might as a > secondary effect!), but its main point is to improve access > to memory beyond the caches imo. > > One idea where you exploit cache effects by giving each > thread/core a very small heap with eden (typically <= 1 MB, > i.e. something that fits nicely into the cache) that is > reused like you suggest over and over again is generally > referred to as "thread local heaps". > > The problem is, that the threshold to get improvements is > much higher than with NUMA awareness. If a thread only > has such a small eden, you cannot stop all threads every time > it fills up any more, because that would naturally decrease > throughput too much. I.e. it needs thread local gcs (so that > every thread can collect its own heap without stopping the > others) and associated complexity in the VM to work > efficiently though. > > This is not meant to discourage you about NUMA awareness, just > a try to clear up things (if there ever was something to clear > up). NUMA awareness does have its use and it improves > performance, but I don't think it mainly does so because of > improved cachability. > > Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon Oct 29 16:20:03 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 29 Oct 2012 17:20:03 +0100 Subject: RFR: 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java In-Reply-To: <508939A0.3060008@oracle.com> References: <507FE90C.2020508@oracle.com> <508939A0.3060008@oracle.com> Message-ID: <508EACB3.5020106@oracle.com> Hi all, Based on some internal feedback: Here's a new version with "slow" instead of "paranoid" http://cr.openjdk.java.net/~mgerdin/7200229.2/ /Mikael On 2012-10-25 15:07, Mikael Gerdin wrote: > Hi all, > > Here's an updated webrev which breaks out the check for verification > enabling to separate wrapper functions and replaces the use of #ifdef to > use a "const bool" instead. > > http://cr.openjdk.java.net/~mgerdin/7200229.1/ > > Thanks > /Mikael > > On 2012-10-18 13:33, Mikael Gerdin wrote: >> Hi, >> In the Metaspace implementation that replaced perm gen for class meta >> data all allocations are made from "chunks". A ChunkManager is >> responsible for keeping track of all free chunks and currently there is >> a lot of verification of the free chunks by walking the linked lists >> that the free chunks are kept in. >> In a situation where we create a lot of class loaders we will force the >> ChunkManager to allocate a lot of small chunks, this increases the >> verification overhead in debug builds. This can cause tests to time out >> because the verification calls become very expensive with a lot of free >> chunks. >> We've never seen any of the free chunk verification asserts trigger so I >> propose that we disable the over-zealous verification and just add a >> verification call to Universe::verify to make it possible to turn on >> verification if needed. >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/7200229 >> Buglink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200229 >> >> Thanks >> /Mikael >> > -- Mikael Gerdin Java SE VM SQE Stockholm From john.cuthbertson at oracle.com Mon Oct 29 16:37:43 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 29 Oct 2012 09:37:43 -0700 Subject: RFR(S): 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Message-ID: <508EB0D7.8020204@oracle.com> Hi Everyone, Can I have a couple of volunteers review this change that was submitted by Michal Frajt? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7189971/webrev.0/ In the original patch, Michal was returning (if the CMS thread was terminating or if a foreground collection was scheduled) after setting the CMS flag. Michal incorporated my suggestion to change that and return before setting the CMS flag. I'm not an expert in the inner workings of CMS so I'd appreciate further reviews from those more familiar with CMS' operation. Testing: Functional testing was performed using the GC test suite in both incremental and non-incremental modes with various values of CMSWaitDuration and checking the log files. Additional tests: nsk, jprt. Thanks, JohnC From jon.masamitsu at oracle.com Mon Oct 29 19:27:42 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 29 Oct 2012 12:27:42 -0700 Subject: Request for review (xs) - 8000988 Message-ID: <508ED8AE.8010206@oracle.com> 8000988: VM deadlock when running btree006 on windows-i586 http://cr.openjdk.java.net/~jmasa/8000988/webrev.00/ As part of the class data sharing re-implementation, the acquisition of the Heap_lock was removed. The locking of the Heap_lock to get the GC counts was likely added at that time, but the deletion of the MutexUnlocker(Heap_lock) was missed. From john.cuthbertson at oracle.com Mon Oct 29 21:09:45 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 29 Oct 2012 14:09:45 -0700 Subject: Request for review (xs) - 8000988 In-Reply-To: <508ED8AE.8010206@oracle.com> References: <508ED8AE.8010206@oracle.com> Message-ID: <508EF099.2070603@oracle.com> Hi Jon, Looks good to me. JohnC On 10/29/2012 12:27 PM, Jon Masamitsu wrote: > 8000988: VM deadlock when running btree006 on windows-i586 > > http://cr.openjdk.java.net/~jmasa/8000988/webrev.00/ > > As part of the class data sharing re-implementation, the acquisition > of the Heap_lock > was removed. The locking of the Heap_lock to get the GC counts was > likely added at > that time, but the deletion of the MutexUnlocker(Heap_lock) was missed. From John.Coomes at oracle.com Mon Oct 29 23:26:33 2012 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 29 Oct 2012 16:26:33 -0700 Subject: Request for review (xs) - 8000988 In-Reply-To: <508ED8AE.8010206@oracle.com> References: <508ED8AE.8010206@oracle.com> Message-ID: <20623.4265.155862.293306@oracle.com> Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > 8000988: VM deadlock when running btree006 on windows-i586 > > http://cr.openjdk.java.net/~jmasa/8000988/webrev.00/ > > As part of the class data sharing re-implementation, the acquisition of > the Heap_lock > was removed. The locking of the Heap_lock to get the GC counts was > likely added at > that time, but the deletion of the MutexUnlocker(Heap_lock) was missed. Looks good. -John From ysr1729 at gmail.com Tue Oct 30 00:50:48 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 29 Oct 2012 17:50:48 -0700 Subject: Request for review (xs) - 8000988 In-Reply-To: <20623.4265.155862.293306@oracle.com> References: <508ED8AE.8010206@oracle.com> <20623.4265.155862.293306@oracle.com> Message-ID: yes, looks good to me too. -- ramki On Mon, Oct 29, 2012 at 4:26 PM, John Coomes wrote: > Jon Masamitsu (jon.masamitsu at oracle.com) wrote: > > 8000988: VM deadlock when running btree006 on windows-i586 > > > > http://cr.openjdk.java.net/~jmasa/8000988/webrev.00/ > > > > As part of the class data sharing re-implementation, the acquisition of > > the Heap_lock > > was removed. The locking of the Heap_lock to get the GC counts was > > likely added at > > that time, but the deletion of the MutexUnlocker(Heap_lock) was missed. > > Looks good. > > -John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Tue Oct 30 13:34:20 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 30 Oct 2012 14:34:20 +0100 Subject: RFR (S): 8001564: The load balancing function steal_1_random in taskqueue is not random In-Reply-To: <508A3F95.90608@oracle.com> References: <508A3F95.90608@oracle.com> Message-ID: <508FD75C.8070802@oracle.com> Looks good. StefanK On 10/26/2012 09:45 AM, Erik Helin wrote: > Hi everyone, > > the webrev can be found at: > > http://cr.openjdk.java.net/~brutisso/8001564/webrev.00/ > > Summary: > There are three different algorithms in taskqueue.hpp for stealing an > item from a taskqueue: > - steal_best_of_2 > - steal_best_of_all > - steal_1_random > > However only steal_best_of_2 is currently in use, steal_best_of_all > and steal_1_random are not used at all (not anywhere in the hotspot > source code). > > Furthermore the function steal_1_random has a bug in it, as explained > in 8001564. > > This change removes the functions steal_best_of_all and > steal_1_random, thereby preventing bit rot as in the case of > steal_1_random and also fixing bug 8001564. > > Testing: > JPRT > > Thanks, > Erik From john.cuthbertson at oracle.com Tue Oct 30 18:59:27 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 30 Oct 2012 11:59:27 -0700 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 Message-ID: <5090238F.1030300@oracle.com> Hi Everyone, Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ Summary: A patch containing the changes for 7200261, generated by hg export, did not import cleanly into hsx24 sources - the following two hunks in concurrentMark.cpp: @@ -1188,29 +1188,14 @@ // liveness counting data. class CMCountDataClosureBase: public HeapRegionClosure { protected: + G1CollectedHeap* _g1h; ConcurrentMark* _cm; + CardTableModRefBS* _ct_bs; + BitMap* _region_bm; BitMap* _card_bm; - void set_card_bitmap_range(BitMap::idx_t start_idx, BitMap::idx_t last_idx) { - assert(start_idx <= last_idx, "sanity"); - - // Set the inclusive bit range [start_idx, last_idx]. - // For small ranges (up to 8 cards) use a simple loop; otherwise - // use par_at_put_range. - if ((last_idx - start_idx) < 8) { - for (BitMap::idx_t i = start_idx; i <= last_idx; i += 1) { - _card_bm->par_set_bit(i); - } - } else { - assert(last_idx < _card_bm->size(), "sanity"); - // Note BitMap::par_at_put_range() is exclusive. - BitMap::idx_t max_idx = MAX2(last_idx+1, _card_bm->size()); - _card_bm->par_at_put_range(start_idx, max_idx, true); - } - } - - // It takes a region that's not empty (i.e., it has at least one + // Takes a region that's not empty (i.e., it has at least one // live object in it and sets its corresponding bit on the region // bitmap to 1. If the region is "starts humongous" it will also set // to 1 the bits on the region bitmap that correspond to its @@ -1548,24 +1555,29 @@ if (ntams < top) { // This definitely means the region has live objects. set_bit_for_region(hr); - } - - // Now set the bits for [ntams, top] - BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); - // set_card_bitmap_range() expects the last_idx to be with - // the range of the bit map (see assertion in set_card_bitmap_range()), - // so limit it to that range with this application of MIN2. - BitMap::idx_t last_idx = MIN2(_cm->card_bitmap_index_for(top), - _card_bm->size()-1); - if (start_idx < _card_bm->size()) { - set_card_bitmap_range(start_idx, last_idx); - } else { - // To reach here start_idx must be beyond the end of - // the bit map and last_idx must have been limited by - // the MIN2(). - assert(start_idx == last_idx + 1, - err_msg("Not beyond end start_idx " SIZE_FORMAT " last_idx " - SIZE_FORMAT, start_idx, last_idx)); + + // Now set the bits in the card bitmap for [ntams, top) + BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); + BitMap::idx_t end_idx = _cm->card_bitmap_index_for(top); + + // Note: if we're looking at the last region in heap - top + // could be actually just beyond the end of the heap; end_idx + // will then correspond to a (non-existent) card that is also + // just beyond the heap. + if (_g1h->is_in_g1_reserved(top) && !_ct_bs->is_card_aligned(top)) { + // end of object is not card aligned - increment to cover + // all the cards spanned by the object + end_idx += 1; + } + + assert(end_idx <= _card_bm->size(), + err_msg("oob: end_idx= "SIZE_FORMAT", bitmap size= "SIZE_FORMAT, + end_idx, _card_bm->size())); + assert(start_idx < _card_bm->size(), + err_msg("oob: start_idx= "SIZE_FORMAT", bitmap size= "SIZE_FORMAT, + start_idx, _card_bm->size())); + + _cm->set_card_bitmap_range(_card_bm, start_idx, end_idx, true /* is_par */); } // Set the bit for the region if it contains live data did not apply cleanly. These had to be fixed up by hand. The original webrev for 7200261 can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.1 and was originally reviewed by Bengt, Jesper, and Jon Masamitsu. Thanks, JohnC From jon.masamitsu at oracle.com Tue Oct 30 19:17:26 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 30 Oct 2012 12:17:26 -0700 Subject: RFR: 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java In-Reply-To: <508EACB3.5020106@oracle.com> References: <507FE90C.2020508@oracle.com> <508939A0.3060008@oracle.com> <508EACB3.5020106@oracle.com> Message-ID: <509027C6.20904@oracle.com> Looks good. Jon On 10/29/12 09:20, Mikael Gerdin wrote: > Hi all, > > Based on some internal feedback: > Here's a new version with "slow" instead of "paranoid" > http://cr.openjdk.java.net/~mgerdin/7200229.2/ > > /Mikael > > On 2012-10-25 15:07, Mikael Gerdin wrote: >> Hi all, >> >> Here's an updated webrev which breaks out the check for verification >> enabling to separate wrapper functions and replaces the use of #ifdef to >> use a "const bool" instead. >> >> http://cr.openjdk.java.net/~mgerdin/7200229.1/ >> >> Thanks >> /Mikael >> >> On 2012-10-18 13:33, Mikael Gerdin wrote: >>> Hi, >>> In the Metaspace implementation that replaced perm gen for class meta >>> data all allocations are made from "chunks". A ChunkManager is >>> responsible for keeping track of all free chunks and currently there is >>> a lot of verification of the free chunks by walking the linked lists >>> that the free chunks are kept in. >>> In a situation where we create a lot of class loaders we will force the >>> ChunkManager to allocate a lot of small chunks, this increases the >>> verification overhead in debug builds. This can cause tests to time out >>> because the verification calls become very expensive with a lot of free >>> chunks. >>> We've never seen any of the free chunk verification asserts trigger >>> so I >>> propose that we disable the over-zealous verification and just add a >>> verification call to Universe::verify to make it possible to turn on >>> verification if needed. >>> >>> Webrev: http://cr.openjdk.java.net/~mgerdin/7200229 >>> Buglink: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200229 >>> >>> Thanks >>> /Mikael >>> >> > From John.Coomes at oracle.com Tue Oct 30 20:26:54 2012 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 30 Oct 2012 13:26:54 -0700 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 In-Reply-To: <5090238F.1030300@oracle.com> References: <5090238F.1030300@oracle.com> Message-ID: <20624.14350.199381.941721@oracle.com> John Cuthbertson (john.cuthbertson at oracle.com) wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes for this CR? The > webrev can be found at: http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ > > Summary: > A patch containing the changes for 7200261, generated by hg export, did > not import cleanly into hsx24 sources - the following two hunks in > concurrentMark.cpp: > ... Hi John, Not a review (I may get to that :-)), but please use the original issue number (7200261) in the changeset comment and other references, and close 8001985 as a dup. Otherwise, it's much harder to track the fact that 7200261 was backported, and automated tools will miss that fact entirely. -John From john.cuthbertson at oracle.com Tue Oct 30 20:40:38 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 30 Oct 2012 13:40:38 -0700 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 In-Reply-To: <20624.14350.199381.941721@oracle.com> References: <5090238F.1030300@oracle.com> <20624.14350.199381.941721@oracle.com> Message-ID: <50903B46.8070003@oracle.com> Hi John, Thanks for the info. Will there be a problem if there's a different set of reviewers? JohnC On 10/30/2012 1:26 PM, John Coomes wrote: > John Cuthbertson (john.cuthbertson at oracle.com) wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this CR? The >> webrev can be found at: http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ >> >> Summary: >> A patch containing the changes for 7200261, generated by hg export, did >> not import cleanly into hsx24 sources - the following two hunks in >> concurrentMark.cpp: >> ... > Hi John, > > Not a review (I may get to that :-)), but please use the original > issue number (7200261) in the changeset comment and other references, > and close 8001985 as a dup. > > Otherwise, it's much harder to track the fact that 7200261 was > backported, and automated tools will miss that fact entirely. > > -John From jon.masamitsu at oracle.com Tue Oct 30 20:56:05 2012 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Tue, 30 Oct 2012 20:56:05 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8000988: VM deadlock when running btree006 on windows-i586 Message-ID: <20121030205609.0BA664768E@hg.openjdk.java.net> Changeset: 3fadc0e8cffe Author: jmasa Date: 2012-10-30 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3fadc0e8cffe 8000988: VM deadlock when running btree006 on windows-i586 Reviewed-by: johnc, jcoomes, ysr ! src/share/vm/memory/collectorPolicy.cpp From John.Coomes at oracle.com Tue Oct 30 21:01:55 2012 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 30 Oct 2012 14:01:55 -0700 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 In-Reply-To: <50903B46.8070003@oracle.com> References: <5090238F.1030300@oracle.com> <20624.14350.199381.941721@oracle.com> <50903B46.8070003@oracle.com> Message-ID: <20624.16451.126399.842184@oracle.com> John Cuthbertson (john.cuthbertson at oracle.com) wrote: > Hi John, > > Thanks for the info. Will there be a problem if there's a different set > of reviewers? Different reviewers is fine; the main thing is the issue number should be the same. -John > On 10/30/2012 1:26 PM, John Coomes wrote: > > John Cuthbertson (john.cuthbertson at oracle.com) wrote: > >> Hi Everyone, > >> > >> Can I have a couple of volunteers review the changes for this CR? The > >> webrev can be found at: http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ > >> > >> Summary: > >> A patch containing the changes for 7200261, generated by hg export, did > >> not import cleanly into hsx24 sources - the following two hunks in > >> concurrentMark.cpp: > >> ... > > Hi John, > > > > Not a review (I may get to that :-)), but please use the original > > issue number (7200261) in the changeset comment and other references, > > and close 8001985 as a dup. > > > > Otherwise, it's much harder to track the fact that 7200261 was > > backported, and automated tools will miss that fact entirely. > > > > -John > From jesper.wilhelmsson at oracle.com Tue Oct 30 21:22:30 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 30 Oct 2012 22:22:30 +0100 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 In-Reply-To: <5090238F.1030300@oracle.com> References: <5090238F.1030300@oracle.com> Message-ID: <50904516.7030703@oracle.com> Hi John, Looks good to me. /Jesper On 2012-10-30 19:59, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes for this CR? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ > > Summary: > A patch containing the changes for 7200261, generated by hg export, did not > import cleanly into hsx24 sources - the following two hunks in > concurrentMark.cpp: > > @@ -1188,29 +1188,14 @@ > // liveness counting data. > class CMCountDataClosureBase: public HeapRegionClosure { > protected: > + G1CollectedHeap* _g1h; > ConcurrentMark* _cm; > + CardTableModRefBS* _ct_bs; > + > BitMap* _region_bm; > BitMap* _card_bm; > > - void set_card_bitmap_range(BitMap::idx_t start_idx, BitMap::idx_t last_idx) { > - assert(start_idx <= last_idx, "sanity"); > - > - // Set the inclusive bit range [start_idx, last_idx]. > - // For small ranges (up to 8 cards) use a simple loop; otherwise > - // use par_at_put_range. > - if ((last_idx - start_idx) < 8) { > - for (BitMap::idx_t i = start_idx; i <= last_idx; i += 1) { > - _card_bm->par_set_bit(i); > - } > - } else { > - assert(last_idx < _card_bm->size(), "sanity"); > - // Note BitMap::par_at_put_range() is exclusive. > - BitMap::idx_t max_idx = MAX2(last_idx+1, _card_bm->size()); > - _card_bm->par_at_put_range(start_idx, max_idx, true); > - } > - } > - > - // It takes a region that's not empty (i.e., it has at least one > + // Takes a region that's not empty (i.e., it has at least one > // live object in it and sets its corresponding bit on the region > // bitmap to 1. If the region is "starts humongous" it will also set > // to 1 the bits on the region bitmap that correspond to its > > @@ -1548,24 +1555,29 @@ > if (ntams < top) { > // This definitely means the region has live objects. > set_bit_for_region(hr); > - } > - > - // Now set the bits for [ntams, top] > - BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); > - // set_card_bitmap_range() expects the last_idx to be with > - // the range of the bit map (see assertion in set_card_bitmap_range()), > - // so limit it to that range with this application of MIN2. > - BitMap::idx_t last_idx = MIN2(_cm->card_bitmap_index_for(top), > - _card_bm->size()-1); > - if (start_idx < _card_bm->size()) { > - set_card_bitmap_range(start_idx, last_idx); > - } else { > - // To reach here start_idx must be beyond the end of > - // the bit map and last_idx must have been limited by > - // the MIN2(). > - assert(start_idx == last_idx + 1, > - err_msg("Not beyond end start_idx " SIZE_FORMAT " last_idx " > - SIZE_FORMAT, start_idx, last_idx)); > + > + // Now set the bits in the card bitmap for [ntams, top) > + BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); > + BitMap::idx_t end_idx = _cm->card_bitmap_index_for(top); > + > + // Note: if we're looking at the last region in heap - top > + // could be actually just beyond the end of the heap; end_idx > + // will then correspond to a (non-existent) card that is also > + // just beyond the heap. > + if (_g1h->is_in_g1_reserved(top) && !_ct_bs->is_card_aligned(top)) { > + // end of object is not card aligned - increment to cover > + // all the cards spanned by the object > + end_idx += 1; > + } > + > + assert(end_idx <= _card_bm->size(), > + err_msg("oob: end_idx= "SIZE_FORMAT", bitmap size= "SIZE_FORMAT, > + end_idx, _card_bm->size())); > + assert(start_idx < _card_bm->size(), > + err_msg("oob: start_idx= "SIZE_FORMAT", bitmap size= > "SIZE_FORMAT, > + start_idx, _card_bm->size())); > + > + _cm->set_card_bitmap_range(_card_bm, start_idx, end_idx, true /* > is_par */); > } > > // Set the bit for the region if it contains live data > > did not apply cleanly. These had to be fixed up by hand. The original webrev > for 7200261 can be found at: > http://cr.openjdk.java.net/~johnc/7200261/webrev.1 and was originally > reviewed by Bengt, Jesper, and Jon Masamitsu. > > Thanks, > > JohnC -------------- next part -------------- A non-text attachment was scrubbed... Name: jesper_wilhelmsson.vcf Type: text/x-vcard Size: 263 bytes Desc: not available URL: From john.cuthbertson at oracle.com Tue Oct 30 22:48:20 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 30 Oct 2012 15:48:20 -0700 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 In-Reply-To: <50904516.7030703@oracle.com> References: <5090238F.1030300@oracle.com> <50904516.7030703@oracle.com> Message-ID: <50905934.4050609@oracle.com> Hi Jesper, Thanks for reviewing the changes (for the second time) :). JohnC On 10/30/12 14:22, Jesper Wilhelmsson wrote: > Hi John, > > Looks good to me. > /Jesper > > > On 2012-10-30 19:59, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this CR? The >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ >> >> Summary: >> A patch containing the changes for 7200261, generated by hg export, >> did not import cleanly into hsx24 sources - the following two hunks >> in concurrentMark.cpp: >> >> @@ -1188,29 +1188,14 @@ >> // liveness counting data. >> class CMCountDataClosureBase: public HeapRegionClosure { >> protected: >> + G1CollectedHeap* _g1h; >> ConcurrentMark* _cm; >> + CardTableModRefBS* _ct_bs; >> + >> BitMap* _region_bm; >> BitMap* _card_bm; >> >> - void set_card_bitmap_range(BitMap::idx_t start_idx, BitMap::idx_t >> last_idx) { >> - assert(start_idx <= last_idx, "sanity"); >> - >> - // Set the inclusive bit range [start_idx, last_idx]. >> - // For small ranges (up to 8 cards) use a simple loop; otherwise >> - // use par_at_put_range. >> - if ((last_idx - start_idx) < 8) { >> - for (BitMap::idx_t i = start_idx; i <= last_idx; i += 1) { >> - _card_bm->par_set_bit(i); >> - } >> - } else { >> - assert(last_idx < _card_bm->size(), "sanity"); >> - // Note BitMap::par_at_put_range() is exclusive. >> - BitMap::idx_t max_idx = MAX2(last_idx+1, _card_bm->size()); >> - _card_bm->par_at_put_range(start_idx, max_idx, true); >> - } >> - } >> - >> - // It takes a region that's not empty (i.e., it has at least one >> + // Takes a region that's not empty (i.e., it has at least one >> // live object in it and sets its corresponding bit on the region >> // bitmap to 1. If the region is "starts humongous" it will also set >> // to 1 the bits on the region bitmap that correspond to its >> >> @@ -1548,24 +1555,29 @@ >> if (ntams < top) { >> // This definitely means the region has live objects. >> set_bit_for_region(hr); >> - } >> - >> - // Now set the bits for [ntams, top] >> - BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); >> - // set_card_bitmap_range() expects the last_idx to be with >> - // the range of the bit map (see assertion in >> set_card_bitmap_range()), >> - // so limit it to that range with this application of MIN2. >> - BitMap::idx_t last_idx = MIN2(_cm->card_bitmap_index_for(top), >> - _card_bm->size()-1); >> - if (start_idx < _card_bm->size()) { >> - set_card_bitmap_range(start_idx, last_idx); >> - } else { >> - // To reach here start_idx must be beyond the end of >> - // the bit map and last_idx must have been limited by >> - // the MIN2(). >> - assert(start_idx == last_idx + 1, >> - err_msg("Not beyond end start_idx " SIZE_FORMAT " last_idx " >> - SIZE_FORMAT, start_idx, last_idx)); >> + >> + // Now set the bits in the card bitmap for [ntams, top) >> + BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); >> + BitMap::idx_t end_idx = _cm->card_bitmap_index_for(top); >> + >> + // Note: if we're looking at the last region in heap - top >> + // could be actually just beyond the end of the heap; end_idx >> + // will then correspond to a (non-existent) card that is also >> + // just beyond the heap. >> + if (_g1h->is_in_g1_reserved(top) && >> !_ct_bs->is_card_aligned(top)) { >> + // end of object is not card aligned - increment to cover >> + // all the cards spanned by the object >> + end_idx += 1; >> + } >> + >> + assert(end_idx <= _card_bm->size(), >> + err_msg("oob: end_idx= "SIZE_FORMAT", bitmap size= >> "SIZE_FORMAT, >> + end_idx, _card_bm->size())); >> + assert(start_idx < _card_bm->size(), >> + err_msg("oob: start_idx= "SIZE_FORMAT", bitmap size= >> "SIZE_FORMAT, >> + start_idx, _card_bm->size())); >> + >> + _cm->set_card_bitmap_range(_card_bm, start_idx, end_idx, true >> /* is_par */); >> } >> >> // Set the bit for the region if it contains live data >> >> did not apply cleanly. These had to be fixed up by hand. The original >> webrev for 7200261 can be found at: >> http://cr.openjdk.java.net/~johnc/7200261/webrev.1 and was originally >> reviewed by Bengt, Jesper, and Jon Masamitsu. >> >> Thanks, >> >> JohnC > From bengt.rutisson at oracle.com Wed Oct 31 01:20:21 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 31 Oct 2012 01:20:21 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8001564: The load balancing function steal_1_random in taskqueue is not random Message-ID: <20121031012026.2655D47696@hg.openjdk.java.net> Changeset: 3dfffc8b9722 Author: brutisso Date: 2012-10-30 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3dfffc8b9722 8001564: The load balancing function steal_1_random in taskqueue is not random Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all Reviewed-by: brutisso, stefank Contributed-by: erik.x.helin at oracle.com ! src/share/vm/utilities/taskqueue.hpp From bengt.rutisson at oracle.com Wed Oct 31 08:38:07 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Oct 2012 09:38:07 +0100 Subject: RFR(S/M): 8001985: G1: Backport fix for 7200261 to hsx24 In-Reply-To: <5090238F.1030300@oracle.com> References: <5090238F.1030300@oracle.com> Message-ID: <5090E36F.3080905@oracle.com> Hi John, I think this looks good. The conflict seems to be due to some changes introduced by the perm gen removal push: changeset: 3599:da91efe96a93 user: coleenp date: Sat Sep 01 13:25:18 2012 -0400 summary: 6964458: Reimplement class meta-data storage to use native memory As far as I can tell your new code does about the same range checking that the perm gen fix introduced. Have you verified that? Stefan told me that this was probably an issue that perm gen had to fix since we could sometimes get bitmap indices that pointed outside the bitmap. This was benign as long as they still pointed in to the perm gen bitmap. But once the perm gen bitmap was gone it had to be fixed. In hs24 there is still a perm gen bitmap, so I think we are safe. It also looks to me like you also have the correct handling of the indices with the new code - so thumbs up! If you want to dig deeper in to this I think Jon Masamitsu might know more. Bengt src/share/vm/gc_implementation/g1/concurrentMark.cpp On 2012-10-30 19:59, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/8001985/webrev.0/ > > Summary: > A patch containing the changes for 7200261, generated by hg export, > did not import cleanly into hsx24 sources - the following two hunks in > concurrentMark.cpp: > > @@ -1188,29 +1188,14 @@ > // liveness counting data. > class CMCountDataClosureBase: public HeapRegionClosure { > protected: > + G1CollectedHeap* _g1h; > ConcurrentMark* _cm; > + CardTableModRefBS* _ct_bs; > + > BitMap* _region_bm; > BitMap* _card_bm; > > - void set_card_bitmap_range(BitMap::idx_t start_idx, BitMap::idx_t > last_idx) { > - assert(start_idx <= last_idx, "sanity"); > - > - // Set the inclusive bit range [start_idx, last_idx]. > - // For small ranges (up to 8 cards) use a simple loop; otherwise > - // use par_at_put_range. > - if ((last_idx - start_idx) < 8) { > - for (BitMap::idx_t i = start_idx; i <= last_idx; i += 1) { > - _card_bm->par_set_bit(i); > - } > - } else { > - assert(last_idx < _card_bm->size(), "sanity"); > - // Note BitMap::par_at_put_range() is exclusive. > - BitMap::idx_t max_idx = MAX2(last_idx+1, _card_bm->size()); > - _card_bm->par_at_put_range(start_idx, max_idx, true); > - } > - } > - > - // It takes a region that's not empty (i.e., it has at least one > + // Takes a region that's not empty (i.e., it has at least one > // live object in it and sets its corresponding bit on the region > // bitmap to 1. If the region is "starts humongous" it will also set > // to 1 the bits on the region bitmap that correspond to its > > @@ -1548,24 +1555,29 @@ > if (ntams < top) { > // This definitely means the region has live objects. > set_bit_for_region(hr); > - } > - > - // Now set the bits for [ntams, top] > - BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); > - // set_card_bitmap_range() expects the last_idx to be with > - // the range of the bit map (see assertion in > set_card_bitmap_range()), > - // so limit it to that range with this application of MIN2. > - BitMap::idx_t last_idx = MIN2(_cm->card_bitmap_index_for(top), > - _card_bm->size()-1); > - if (start_idx < _card_bm->size()) { > - set_card_bitmap_range(start_idx, last_idx); > - } else { > - // To reach here start_idx must be beyond the end of > - // the bit map and last_idx must have been limited by > - // the MIN2(). > - assert(start_idx == last_idx + 1, > - err_msg("Not beyond end start_idx " SIZE_FORMAT " last_idx " > - SIZE_FORMAT, start_idx, last_idx)); > + > + // Now set the bits in the card bitmap for [ntams, top) > + BitMap::idx_t start_idx = _cm->card_bitmap_index_for(ntams); > + BitMap::idx_t end_idx = _cm->card_bitmap_index_for(top); > + > + // Note: if we're looking at the last region in heap - top > + // could be actually just beyond the end of the heap; end_idx > + // will then correspond to a (non-existent) card that is also > + // just beyond the heap. > + if (_g1h->is_in_g1_reserved(top) && > !_ct_bs->is_card_aligned(top)) { > + // end of object is not card aligned - increment to cover > + // all the cards spanned by the object > + end_idx += 1; > + } > + > + assert(end_idx <= _card_bm->size(), > + err_msg("oob: end_idx= "SIZE_FORMAT", bitmap size= > "SIZE_FORMAT, > + end_idx, _card_bm->size())); > + assert(start_idx < _card_bm->size(), > + err_msg("oob: start_idx= "SIZE_FORMAT", bitmap size= > "SIZE_FORMAT, > + start_idx, _card_bm->size())); > + > + _cm->set_card_bitmap_range(_card_bm, start_idx, end_idx, true > /* is_par */); > } > > // Set the bit for the region if it contains live data > > did not apply cleanly. These had to be fixed up by hand. The original > webrev for 7200261 can be found at: > http://cr.openjdk.java.net/~johnc/7200261/webrev.1 and was originally > reviewed by Bengt, Jesper, and Jon Masamitsu. > > Thanks, > > JohnC From bengt.rutisson at oracle.com Wed Oct 31 15:41:30 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Oct 2012 16:41:30 +0100 Subject: -XX:+TraceClassUnloading enabled w/ -Xloggc ? In-Reply-To: <1AC081A5-5F23-4DF6-AC47-50CF111C5010@salesforce.com> References: <1AC081A5-5F23-4DF6-AC47-50CF111C5010@salesforce.com> Message-ID: <509146AA.5090302@oracle.com> Charlie, I don't see any code that enables TraceClassUnloading when -Xloggc is used. Are you sure that this happens? When I run it also doesn't look like it gets enabled. >java -Xloggc:log.txt -XX:+PrintFlagsFinal -version | grep TraceClassUnloading bool TraceClassUnloading = false {product rw} java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b60) Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode) We do enable PrintGC and PrintGCDetails when -Xloggc is enabled: if (match_option(option, "-Xloggc:", &tail)) { // Redirect GC output to the file. -Xloggc: // ostream_init_log(), when called will use this filename // to initialize a fileStream. _gc_log_filename = strdup(tail); FLAG_SET_CMDLINE(bool, PrintGC, true); FLAG_SET_CMDLINE(bool, PrintGCTimeStamps, true); // JNI hooks } Bengt On 2012-10-29 16:06, Charlie Hunt wrote: > We stumbled across this last week ... and now curious. > > With -Xloggc, -XX:+TraceClassUnloading is also enabled. But, with other GC related command line options such as; -XX:+PrintGCDetails, -XX:+PrintGC, -XX:+PrintHeapAtGC, etc. -XX:-TraceClassUnloading remains disabled by default. > > Anyone know the history that led to the decision to only enable +TraceClassUnloading with -Xloggc, and not with say +PrintGCDetails? > > thanks, > > charlie ... From bernd-2012 at eckenfels.net Wed Oct 31 15:50:50 2012 From: bernd-2012 at eckenfels.net (Bernd Eckenfels) Date: Wed, 31 Oct 2012 16:50:50 +0100 Subject: -XX:+TraceClassUnloading enabled w/ -Xloggc ? In-Reply-To: <509146AA.5090302@oracle.com> References: <1AC081A5-5F23-4DF6-AC47-50CF111C5010@salesforce.com> <509146AA.5090302@oracle.com> Message-ID: Hello, This was changed in 7040420/2209834 The New bugtracker does not really allow me to see the versions but it was around 6.0U22 Bernd Am 31.10.2012 um 16:41 schrieb Bengt Rutisson : > > Charlie, > > I don't see any code that enables TraceClassUnloading when -Xloggc is used. Are you sure that this happens? > > When I run it also doesn't look like it gets enabled. > > >java -Xloggc:log.txt -XX:+PrintFlagsFinal -version | grep TraceClassUnloading > bool TraceClassUnloading = false {product rw} > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b60) > Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode) > > We do enable PrintGC and PrintGCDetails when -Xloggc is enabled: > > if (match_option(option, "-Xloggc:", &tail)) { > // Redirect GC output to the file. -Xloggc: > // ostream_init_log(), when called will use this filename > // to initialize a fileStream. > _gc_log_filename = strdup(tail); > FLAG_SET_CMDLINE(bool, PrintGC, true); > FLAG_SET_CMDLINE(bool, PrintGCTimeStamps, true); > > // JNI hooks > } > > Bengt > > > On 2012-10-29 16:06, Charlie Hunt wrote: >> We stumbled across this last week ... and now curious. >> >> With -Xloggc, -XX:+TraceClassUnloading is also enabled. But, with other GC related command line options such as; -XX:+PrintGCDetails, -XX:+PrintGC, -XX:+PrintHeapAtGC, etc. -XX:-TraceClassUnloading remains disabled by default. >> >> Anyone know the history that led to the decision to only enable +TraceClassUnloading with -Xloggc, and not with say +PrintGCDetails? >> >> thanks, >> >> charlie ... > From chunt at salesforce.com Wed Oct 31 16:51:01 2012 From: chunt at salesforce.com (Charlie Hunt) Date: Wed, 31 Oct 2012 09:51:01 -0700 Subject: -XX:+TraceClassUnloading enabled w/ -Xloggc ? In-Reply-To: <509146AA.5090302@oracle.com> References: <1AC081A5-5F23-4DF6-AC47-50CF111C5010@salesforce.com> <509146AA.5090302@oracle.com> Message-ID: <3E8047DE-8BE2-48C3-A947-4D653C7DAF6B@salesforce.com> Hi Bengt, I also just noticed Bernd's reply as I was drafting this note to you. It appears there was a change made possibly after the Java 7 fork. I checked 6u33, (which isn't too old), and got: $ /home/chunt/jdks/jdk1.6.0_33/bin/java -Xloggc:/tmp/gc.log -XX:+PrintFlagsFinal -version | grep TraceClassUnloading bool TraceClassUnloading := true {product rw} java version "1.6.0_33" Java(TM) SE Runtime Environment (build 1.6.0_33-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) I didn't check any Java 6u* after 33. But, the Java 7 versions I checked shows it disabled with -Xloggc, as you showed with what looks to be a fairly recent HotSpot, or from built directly from hotspot-main's repository. Perhaps someone had already noticed this peculiarity previously and the change was integrated into HotSpot after the fork for Java 7? Or, if it's in a 6u* after 6u33, then perhaps it got back ported to Java 6 since 6u33 came after the Java 7 fork. Ooh, before I forget ... yeah, I noticed +PrintGC and +PrintGCDetails were auto-enabled with -Xloggc. My question, which I may not have made very clear, was if -Xloggc was auto-enabling +TraceClassUnloading, then why wouldn't it be auto-enabled with +PrintGC or +PrintGCDetails. That's a mute point now since a change has been made to to leave TraceClassUnloading disabled with -Xloggc. ;-) Thanks (both you and Bernd) for the additional info and forensics. charlie ... On Oct 31, 2012, at 10:41 AM, Bengt Rutisson wrote: Charlie, I don't see any code that enables TraceClassUnloading when -Xloggc is used. Are you sure that this happens? When I run it also doesn't look like it gets enabled. java -Xloggc:log.txt -XX:+PrintFlagsFinal -version | grep TraceClassUnloading bool TraceClassUnloading = false {product rw} java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b60) Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode) We do enable PrintGC and PrintGCDetails when -Xloggc is enabled: if (match_option(option, "-Xloggc:", &tail)) { // Redirect GC output to the file. -Xloggc: // ostream_init_log(), when called will use this filename // to initialize a fileStream. _gc_log_filename = strdup(tail); FLAG_SET_CMDLINE(bool, PrintGC, true); FLAG_SET_CMDLINE(bool, PrintGCTimeStamps, true); // JNI hooks } Bengt On 2012-10-29 16:06, Charlie Hunt wrote: We stumbled across this last week ... and now curious. With -Xloggc, -XX:+TraceClassUnloading is also enabled. But, with other GC related command line options such as; -XX:+PrintGCDetails, -XX:+PrintGC, -XX:+PrintHeapAtGC, etc. -XX:-TraceClassUnloading remains disabled by default. Anyone know the history that led to the decision to only enable +TraceClassUnloading with -Xloggc, and not with say +PrintGCDetails? thanks, charlie ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From anantiitrke at gmail.com Wed Oct 31 10:20:04 2012 From: anantiitrke at gmail.com (Ashish Saxena) Date: Wed, 31 Oct 2012 15:50:04 +0530 Subject: Old generation doesn't get freed even after multiple System.gc() Message-ID: Hi Team, We are observing that even after multiple full GC, JVM doesn't clear the Old generation. Full GC do occur (as seem from GC logs), but it performs Young generation collection followed by promotion into old generation but the old generation collection doesn't happen. Test: When Heap size is low (1 GB), after multiple full GC, total heap size after GC is around 400 MB. But with Heap size is high(8 GB), after multiple full GC, total heap size after GC is around 1300 MB. GC logs confirms that old generation is not getting collected. It seems that on receiving request for full GC, 1. JVM triggers young generation GC 2. Checks the occupancy of old generation, and triggers Old generation GC only if there is memory pressure. Is there a way by which we can instruct JVM to trigger Old generation collection each time full GC is triggered ? This is required to measure actual memory usage (without garbage) of the application. Thanks and Regards, Ashish A. Saxena From ysr1729 at gmail.com Wed Oct 31 23:40:52 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 31 Oct 2012 16:40:52 -0700 Subject: Old generation doesn't get freed even after multiple System.gc() In-Reply-To: References: Message-ID: don't know what made you believe "System.gc() doesn't trigger old" -- what collector are you using and what makes you believe that's the case? Any representative GC logs to illustrate what you are describing below? Also any details on the JVM/JDK version you are seeing this with? -- ramki On Wed, Oct 31, 2012 at 3:20 AM, Ashish Saxena wrote: > Hi Team, > > We are observing that even after multiple full GC, JVM doesn't clear > the Old generation. Full GC do occur (as seem from GC logs), but it > performs Young generation collection followed by promotion into old > generation but the old generation collection doesn't happen. > > Test: > When Heap size is low (1 GB), after multiple full GC, total heap size > after GC is around 400 MB. > But with Heap size is high(8 GB), after multiple full GC, total heap > size after GC is around 1300 MB. GC logs confirms that old generation > is not getting collected. > > It seems that on receiving request for full GC, > 1. JVM triggers young generation GC > 2. Checks the occupancy of old generation, and triggers Old generation > GC only if there is memory pressure. > > Is there a way by which we can instruct JVM to trigger Old generation > collection each time full GC is triggered ? This is required to > measure actual memory usage (without garbage) of the application. > > Thanks and Regards, > Ashish A. Saxena > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.B.Kessler at Oracle.COM Wed Oct 31 23:54:28 2012 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Wed, 31 Oct 2012 16:54:28 -0700 Subject: Old generation doesn't get freed even after multiple System.gc() In-Reply-To: References: Message-ID: <5091BA34.9030400@Oracle.COM> If your goal is really to measure memory usage without garbage, then you might be interested in jmap[1], in particular "jmap -histo:live pid". (You can find the pid with jps[2].) ... peter [1] http://docs.oracle.com/javase/6/docs/technotes/tools/share/jmap.html [2] http://docs.oracle.com/javase/6/docs/technotes/tools/share/jps.html Ashish Saxena wrote: > Hi Team, > > We are observing that even after multiple full GC, JVM doesn't clear > the Old generation. Full GC do occur (as seem from GC logs), but it > performs Young generation collection followed by promotion into old > generation but the old generation collection doesn't happen. > > Test: > When Heap size is low (1 GB), after multiple full GC, total heap size > after GC is around 400 MB. > But with Heap size is high(8 GB), after multiple full GC, total heap > size after GC is around 1300 MB. GC logs confirms that old generation > is not getting collected. > > It seems that on receiving request for full GC, > 1. JVM triggers young generation GC > 2. Checks the occupancy of old generation, and triggers Old generation > GC only if there is memory pressure. > > Is there a way by which we can instruct JVM to trigger Old generation > collection each time full GC is triggered ? This is required to > measure actual memory usage (without garbage) of the application. > > Thanks and Regards, > Ashish A. Saxena