From john.coomes at oracle.com  Sat Sep  1 03:46:31 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Sat, 01 Sep 2012 03:46:31 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 19 new changesets
Message-ID: <20120901034712.C2D9E47852@hg.openjdk.java.net>

Changeset: 3b77f0c58018
Author:    katleman
Date:      2012-08-30 10:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3b77f0c58018

Added tag jdk8-b54 for changeset e8fb566b9466

! .hgtags

Changeset: be82ef218872
Author:    sla
Date:      2012-08-22 10:01 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/be82ef218872

7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X
Reviewed-by: dholmes, dsamersoff, nloodin

! src/os/posix/launcher/launcher.script

Changeset: b3602ff9c1b8
Author:    dcubed
Date:      2012-08-24 19:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b3602ff9c1b8

Merge


Changeset: 220b59f8413f
Author:    brutisso
Date:      2012-08-31 08:30 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/220b59f8413f

Merge


Changeset: a1c7f6472621
Author:    kvn
Date:      2012-08-27 09:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a1c7f6472621

7148109: C2 compiler consumes too much heap resources
Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit.
Reviewed-by: twisti

! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/reg_split.cpp

Changeset: a5dd6e3ef9f3
Author:    twisti
Date:      2012-08-27 15:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a5dd6e3ef9f3

6677625: Move platform specific flags from globals.hpp to globals_<arch>.hpp
Reviewed-by: kvn, dholmes, coleenp
Contributed-by: Tao Mao <tao.mao at oracle.com>

! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/x86/vm/globals_x86.hpp
! src/cpu/zero/vm/globals_zero.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/globals_extension.hpp

Changeset: 7f813940ac35
Author:    twisti
Date:      2012-08-28 15:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7f813940ac35

7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites
Reviewed-by: kvn

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp

Changeset: 83b6305a5638
Author:    coleenp
Date:      2012-08-29 14:49 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/83b6305a5638

7191926: Remove MKS dependency in Hotspot regression tests
Summary: Add case for CYGWIN in .sh files.
Reviewed-by: coleenp, kvn
Contributed-by: pavel.punegov at oracle.com

! test/compiler/6894807/Test6894807.sh
! test/gc/6941923/test6941923.sh
! test/runtime/6626217/Test6626217.sh
! test/runtime/6878713/Test6878713.sh
! test/runtime/7020373/Test7020373.sh
! test/runtime/7051189/Xchecksig.sh
! test/runtime/7110720/Test7110720.sh
! test/runtime/7158800/Test7158800.sh
! test/runtime/7158988/TestFieldMonitor.sh

Changeset: 0acd345fd810
Author:    kvn
Date:      2012-08-29 13:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0acd345fd810

7160161: Missed safepoint in non-Counted loop
Summary: Do not remove safepoints during peeling optimization.
Reviewed-by: twisti

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp

Changeset: 4d318b1e73ca
Author:    twisti
Date:      2012-08-31 10:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4d318b1e73ca

Merge


Changeset: 0771839a29ab
Author:    jprovino
Date:      2012-08-08 15:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0771839a29ab

7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC
Summary: add "arm" to the list of processors that need -fPIC
Reviewed-by: vladidan, dholmes

! make/pic.make

Changeset: 892ec0920ccd
Author:    vladidan
Date:      2012-08-08 16:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/892ec0920ccd

Merge


Changeset: e2cc1fe53845
Author:    amurillo
Date:      2012-08-17 16:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e2cc1fe53845

Merge


Changeset: a9fed06c01d2
Author:    bpittore
Date:      2012-08-30 11:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a9fed06c01d2

7154641: Servicability agent should work on platforms other than x86, sparc
Summary: Added capability to load support classes for other cpus
Reviewed-by: coleenp, bobv, sla
Contributed-by: Bill Pittore <bill.pittore at oracle.com>

! agent/make/saenv.sh
! agent/make/start-debug-server-proc.sh
! agent/src/os/linux/LinuxDebuggerLocal.c
! agent/src/os/linux/libproc.h
! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
! 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/linux/LinuxCDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.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/ui/classbrowser/HTMLGenerator.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java
! make/defs.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/sa.make
! make/linux/makefiles/saproc.make
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6dcb17434873
Author:    jiangli
Date:      2012-08-31 14:47 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6dcb17434873

Merge


Changeset: 1eb74cd5994b
Author:    jiangli
Date:      2012-08-31 12:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1eb74cd5994b

Merge


Changeset: 09ea7e0752b3
Author:    jcoomes
Date:      2012-08-31 16:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/09ea7e0752b3

Merge


Changeset: af0c8a080851
Author:    jcoomes
Date:      2012-08-31 16:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/af0c8a080851

Added tag hs24-b22 for changeset 09ea7e0752b3

! .hgtags

Changeset: 36d1d483d5d6
Author:    jcoomes
Date:      2012-08-31 16:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/36d1d483d5d6

7195615: new hotspot build - hs25-b01
Reviewed-by: johnc

! make/hotspot_version



From ysr1729 at gmail.com  Sat Sep  1 21:08:13 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Sat, 1 Sep 2012 14:08:13 -0700
Subject: NewRatio behaviour and some interesting PSYoungGen
In-Reply-To: <A6FEE496-A952-498B-A36A-FA5A54A5F1A5@kodewerk.com>
References: <A6FEE496-A952-498B-A36A-FA5A54A5F1A5@kodewerk.com>
Message-ID: <CABzyjyk+FjxbJZvCX4Tp87uzzeEyFwrT_j59SLE7GYeErQPKEw@mail.gmail.com>

Hi Kirk -- Interesting questions... I will try and answer (albeit only
partially) the last two questions  in your email, letting others address
the other questions (as well as add to the following as appropriate).

On Fri, Aug 31, 2012 at 1:49 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> ...
>

> One other thing that I found interesting is that when using ParNew with
> CMS in combination with NewRatio. What I've seen is that when the VM is
> loaded in low ram Heap will resize young gen. However, for some unknown
> reason, the resize never happens when the VM is loaded higher up in memory.
> I first noticed this while running a benchmark at a conference. The demo
> worked as expected prior to my talk, failed during the talk, and then
> worked after the talk. The difference in the runs was that during the talk
> I had keynote and Chrome and a PDF reader and a few other things running.
> They were idle but they were (of course) consuming quite a bit of memory.
> After a little bit of experimentation I noted that the adaptivity of the
> JVM is some affected by where it lies in memory. In my case it wasn't
> swapping but maybe being higher ram causes enough extra work with the
> pointers that you end up with this side effect????? Pure speculation but
> would be interested in any thoughts.
>

I don't think that would be the case.

If you can recreate the conditions and run with a debug build you'd
probably get more info. My guess is that you are short on swap as might
happen when running with more active processes, you are unable to reserve
swap for committing the expansion of the heap. So the expansion fails and
you are unable to resize. The debug build of the JVM, from what i recall,
issues a message indicating its inability to expand the heap. You might
then try configuring more swap (and possibly RAM to avoid actually
swapping) and see if the resize then happens with all of the programs in
memory. What OS was this on?


>
> One last thing, while spelunking through the code I ran into this.
>
>
> // This method currently does not expect to expand into eden (i.e.,
> // the virtual space boundaries is expected to be consistent
> // with the eden boundaries..
> void PSYoungGen::post_resize() {
>   assert_locked_or_safepoint(Heap_lock);
>   assert((eden_space()->bottom() < to_space()->bottom()) &&
>          (eden_space()->bottom() < from_space()->bottom()),
>          "Eden is assumed to be below the survivor spaces");
>
>   MemRegion cmr((HeapWord*)virtual_space()->low(),
>                 (HeapWord*)virtual_space()->high());
>   Universe::heap()->barrier_set()->resize_covered_region(cmr);
>   space_invariants();
> }
>
> The assertion, as I understand it, is asking if the bottom of to_space and
> from_space are both higher up in memory than the bottom of eden. Wouldn't
> you want to make sure that to or from is higher in memory than the top of
> eden?
>

You are right, but in fact the assert can and should be even stronger than
even that, namely that the _end_ of  Eden (which is higher than its _top_
which is equal to its _bottom_, if Eden is empty, which it usually is at
the end of a scavenge) is lower (smaller virtual address) than the _bottom_
of  the survivor spaces. Recall that top is the where new allocation
occurs, and end is the absolute end of the space that new allocation cannot
cross.

PS: Disclaimer: this is from memory, i haven't looked at the code in a
while, just remembering the naming conventions used in the code as i
remember it.

-- ramki


> Regards,
> Kirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120901/9eb34765/attachment.htm>

From coleen.phillimore at oracle.com  Sat Sep  1 21:36:03 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Sat, 01 Sep 2012 21:36:03 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 6964458: Reimplement class meta-data
	storage to use native memory
Message-ID: <20120901213606.3C2664785E@hg.openjdk.java.net>

Changeset: da91efe96a93
Author:    coleenp
Date:      2012-09-01 13:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93

6964458: Reimplement class meta-data storage to use native memory
Summary: Remove PermGen, allocate meta-data in metaspace linked to class loaders, rewrite GC walking, rewrite and rename metadata to be C++ classes
Reviewed-by: jmasa, stefank, never, coleenp, kvn, brutisso, mgerdin, dholmes, jrose, twisti, roland
Contributed-by: jmasa <jon.masamitsu at oracle.com>, stefank <stefan.karlsson at oracle.com>, mgerdin <mikael.gerdin at oracle.com>, never <tom.rodriguez at oracle.com>

! agent/doc/clhsdb.html
! agent/src/os/bsd/ps_core.c
! agent/src/os/linux/ps_core.c
! agent/src/os/solaris/proc/saproc.cpp
! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/HSDB.java
! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java
+ agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java
+ agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java
+ agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java
! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java
! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/ParallelScavengeHeap.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeDisassembler.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeInvoke.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java
! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java
! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Dictionary.java
! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java
! agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Generation.java
! agent/src/share/classes/sun/jvm/hotspot/memory/GenerationFactory.java
- agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java
! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java
! agent/src/share/classes/sun/jvm/hotspot/memory/SharedHeap.java
! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! agent/src/share/classes/sun/jvm/hotspot/oops/AccessFlags.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/BooleanField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ByteField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CIntField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CharField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CheckedExceptionElement.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolder.java
- agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheEntry.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/DataLayout.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/DefaultMetadataVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/oops/DefaultOopVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/oops/DoubleField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/FieldVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/oops/FloatField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/InstanceClassLoaderKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/InstanceRefKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/IntField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/LocalVariableTableElement.java
! agent/src/share/classes/sun/jvm/hotspot/oops/LongField.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/MetadataVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHistogramElement.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java
! agent/src/share/classes/sun/jvm/hotspot/oops/OopField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/OopPrinter.java
! agent/src/share/classes/sun/jvm/hotspot/oops/OopVisitor.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ShortField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java
! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java
! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java
! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java
! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java
! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java
! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/JNIid.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualBaseConstructor.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java
! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/CodeViewerPanel.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadAddressTreeNodeAdapter.java
- agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java
+ agent/src/share/classes/sun/jvm/hotspot/ui/tree/MetadataTreeNodeAdapter.java
! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/GenericArray.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/IntArray.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/KlassArray.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/MethodArray.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/U1Array.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/U2Array.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactory.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFrame.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaMethod.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaScriptEngine.java
+ agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSMetadata.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js
! make/solaris/makefiles/fastdebug.make
! make/solaris/makefiles/launcher.make
! make/solaris/makefiles/mapfile-vers-COMPILER1
! make/solaris/makefiles/mapfile-vers-COMPILER2
! make/solaris/makefiles/mapfile-vers-TIERED
! make/solaris/makefiles/product.make
! make/solaris/makefiles/profiled.make
- make/solaris/makefiles/reorder_COMPILER1_amd64
- make/solaris/makefiles/reorder_COMPILER1_i486
- make/solaris/makefiles/reorder_COMPILER1_sparc
- make/solaris/makefiles/reorder_COMPILER1_sparcv9
- make/solaris/makefiles/reorder_COMPILER2_amd64
- make/solaris/makefiles/reorder_COMPILER2_i486
- make/solaris/makefiles/reorder_COMPILER2_sparc
- make/solaris/makefiles/reorder_COMPILER2_sparcv9
- make/solaris/makefiles/reorder_CORE_i486
- make/solaris/makefiles/reorder_CORE_sparc
- make/solaris/makefiles/reorder_CORE_sparcv9
- make/solaris/makefiles/reorder_TIERED_amd64
- make/solaris/makefiles/reorder_TIERED_i486
- make/solaris/makefiles/reorder_TIERED_sparc
- make/solaris/makefiles/reorder_TIERED_sparcv9
! make/solaris/makefiles/sparc.make
! make/solaris/makefiles/sparcWorks.make
! make/solaris/makefiles/vm.make
- make/solaris/reorder.sh
! make/windows/create_obj_files.sh
! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/bytecodeInterpreter_sparc.cpp
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/c1_globals_sparc.hpp
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/debug_sparc.cpp
- src/cpu/sparc/vm/dump_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.hpp
! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/sparc/vm/icBuffer_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreterRT_sparc.cpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
+ src/cpu/sparc/vm/metaspaceShared_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.hpp
! 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/bytecodeInterpreter_x86.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! 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/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/c1_globals_x86.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
- src/cpu/x86/vm/dump_x86_32.cpp
- src/cpu/x86/vm/dump_x86_64.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.hpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/icBuffer_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/interpreterRT_x86_64.cpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
+ src/cpu/x86/vm/metaspaceShared_x86_32.cpp
+ src/cpu/x86/vm/metaspaceShared_x86_64.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/cpu/zero/vm/bytecodeInterpreter_zero.cpp
! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.hpp
- src/cpu/zero/vm/dump_zero.cpp
! src/cpu/zero/vm/entry_zero.hpp
! src/cpu/zero/vm/frame_zero.cpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/icBuffer_zero.cpp
! src/cpu/zero/vm/interp_masm_zero.cpp
! src/cpu/zero/vm/interpreterFrame_zero.hpp
! src/cpu/zero/vm/interpreterRT_zero.cpp
! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/interpreter_zero.hpp
+ src/cpu/zero/vm/metaspaceShared_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/cpu/zero/vm/sharkFrame_zero.hpp
! src/cpu/zero/vm/shark_globals_zero.hpp
! src/cpu/zero/vm/stubGenerator_zero.cpp
! src/cpu/zero/vm/templateInterpreter_zero.cpp
! src/cpu/zero/vm/templateTable_zero.cpp
! src/os/bsd/dtrace/generateJvmOffsets.cpp
! src/os/bsd/dtrace/jhelper.d
! src/os/bsd/dtrace/libjvm_db.c
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/os/solaris/dtrace/libjvm_db.c
! src/os/solaris/vm/dtraceJSDT_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp
! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp
! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp
! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp
! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp
! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp
! src/share/tools/whitebox/sun/hotspot/WhiteBox.java
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/main.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_Instruction.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! 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.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_MacroAssembler.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_ValueType.cpp
! src/share/vm/c1/c1_ValueType.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/bcEscapeAnalyzer.hpp
! src/share/vm/ci/ciArrayKlass.cpp
! src/share/vm/ci/ciArrayKlass.hpp
- src/share/vm/ci/ciArrayKlassKlass.hpp
+ src/share/vm/ci/ciBaseObject.cpp
+ src/share/vm/ci/ciBaseObject.hpp
- src/share/vm/ci/ciCPCache.cpp
- src/share/vm/ci/ciCPCache.hpp
! src/share/vm/ci/ciClassList.hpp
! src/share/vm/ci/ciConstantPoolCache.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciInstance.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/ci/ciInstanceKlass.hpp
- src/share/vm/ci/ciInstanceKlassKlass.cpp
- src/share/vm/ci/ciInstanceKlassKlass.hpp
! src/share/vm/ci/ciKlass.cpp
! src/share/vm/ci/ciKlass.hpp
- src/share/vm/ci/ciKlassKlass.cpp
- src/share/vm/ci/ciKlassKlass.hpp
! src/share/vm/ci/ciMemberName.cpp
+ src/share/vm/ci/ciMetadata.cpp
+ src/share/vm/ci/ciMetadata.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciMethodData.cpp
! src/share/vm/ci/ciMethodData.hpp
! src/share/vm/ci/ciMethodHandle.cpp
- src/share/vm/ci/ciMethodKlass.cpp
- src/share/vm/ci/ciMethodKlass.hpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciObjArrayKlass.hpp
- src/share/vm/ci/ciObjArrayKlassKlass.cpp
- src/share/vm/ci/ciObjArrayKlassKlass.hpp
! src/share/vm/ci/ciObject.cpp
! src/share/vm/ci/ciObject.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciObjectFactory.hpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/ci/ciSymbol.hpp
! src/share/vm/ci/ciType.cpp
! src/share/vm/ci/ciType.hpp
! src/share/vm/ci/ciTypeArrayKlass.cpp
! src/share/vm/ci/ciTypeArrayKlass.hpp
- src/share/vm/ci/ciTypeArrayKlassKlass.cpp
- src/share/vm/ci/ciTypeArrayKlassKlass.hpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/ci/compilerInterface.hpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/classLoader.cpp
+ src/share/vm/classfile/classLoaderData.cpp
+ src/share/vm/classfile/classLoaderData.hpp
+ src/share/vm/classfile/classLoaderData.inline.hpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/dictionary.hpp
! src/share/vm/classfile/javaAssertions.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/loaderConstraints.cpp
! src/share/vm/classfile/loaderConstraints.hpp
! src/share/vm/classfile/placeholders.cpp
! src/share/vm/classfile/placeholders.hpp
! src/share/vm/classfile/resolutionErrors.cpp
! src/share/vm/classfile/resolutionErrors.hpp
! src/share/vm/classfile/stackMapFrame.hpp
! src/share/vm/classfile/stackMapTable.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verificationType.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/verifier.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/compiledIC.cpp
! src/share/vm/code/compiledIC.hpp
! src/share/vm/code/debugInfo.cpp
! src/share/vm/code/debugInfo.hpp
! src/share/vm/code/debugInfoRec.cpp
! src/share/vm/code/debugInfoRec.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/dependencies.hpp
! src/share/vm/code/exceptionHandlerTable.hpp
! src/share/vm/code/icBuffer.cpp
! src/share/vm/code/icBuffer.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/oopRecorder.cpp
! src/share/vm/code/oopRecorder.hpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/code/relocInfo.hpp
! src/share/vm/code/scopeDesc.cpp
! src/share/vm/code/scopeDesc.hpp
! src/share/vm/code/vtableStubs.cpp
! src/share/vm/code/vtableStubs.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compileLog.hpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.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/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/satbQueue.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parOopClosures.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp
! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp
! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp
! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! 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/parallelScavenge/psScavenge.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp
! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp
! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp
! src/share/vm/gc_implementation/parallelScavenge/vmStructs_parallelgc.hpp
! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
! src/share/vm/gc_implementation/shared/immutableSpace.cpp
! src/share/vm/gc_implementation/shared/immutableSpace.hpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_implementation/shared/markSweep.inline.hpp
! src/share/vm/gc_implementation/shared/mutableSpace.cpp
! src/share/vm/gc_implementation/shared/mutableSpace.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/gc_interface/collectedHeap.inline.hpp
! src/share/vm/gc_interface/gcCause.cpp
! src/share/vm/gc_interface/gcCause.hpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/bytecode.cpp
! src/share/vm/interpreter/bytecode.hpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp
! src/share/vm/interpreter/bytecodeStream.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/oopMapCache.cpp
! src/share/vm/interpreter/oopMapCache.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/interpreter/templateTable.cpp
! src/share/vm/interpreter/templateTable.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/barrierSet.hpp
! src/share/vm/memory/binaryTreeDictionary.hpp
! src/share/vm/memory/blockOffsetTable.cpp
! src/share/vm/memory/blockOffsetTable.hpp
! src/share/vm/memory/blockOffsetTable.inline.hpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
- src/share/vm/memory/classify.cpp
- src/share/vm/memory/classify.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.hpp
- src/share/vm/memory/compactPermGen.hpp
- src/share/vm/memory/compactingPermGenGen.cpp
- src/share/vm/memory/compactingPermGenGen.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/defNewGeneration.hpp
- src/share/vm/memory/dump.cpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/freeBlockDictionary.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genOopClosures.hpp
! src/share/vm/memory/genOopClosures.inline.hpp
! src/share/vm/memory/genRemSet.cpp
! src/share/vm/memory/genRemSet.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/generationSpec.cpp
! src/share/vm/memory/generationSpec.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/iterator.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/memory/memRegion.hpp
+ src/share/vm/memory/metadataFactory.hpp
+ src/share/vm/memory/metaspace.cpp
+ src/share/vm/memory/metaspace.hpp
+ src/share/vm/memory/metaspaceCounters.cpp
+ src/share/vm/memory/metaspaceCounters.hpp
+ src/share/vm/memory/metaspaceShared.cpp
+ src/share/vm/memory/metaspaceShared.hpp
! src/share/vm/memory/modRefBarrierSet.hpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
- src/share/vm/memory/permGen.cpp
- src/share/vm/memory/permGen.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
- src/share/vm/memory/restore.cpp
- src/share/vm/memory/serialize.cpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/memory/specialized_oop_closures.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
+ src/share/vm/oops/annotations.cpp
+ src/share/vm/oops/annotations.hpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
- src/share/vm/oops/arrayKlassKlass.cpp
- src/share/vm/oops/arrayKlassKlass.hpp
! src/share/vm/oops/arrayOop.hpp
+ src/share/vm/oops/compiledICHolder.cpp
+ src/share/vm/oops/compiledICHolder.hpp
- src/share/vm/oops/compiledICHolderKlass.cpp
- src/share/vm/oops/compiledICHolderKlass.hpp
- src/share/vm/oops/compiledICHolderOop.cpp
- src/share/vm/oops/compiledICHolderOop.hpp
+ src/share/vm/oops/constMethod.cpp
+ src/share/vm/oops/constMethod.hpp
- src/share/vm/oops/constMethodKlass.cpp
- src/share/vm/oops/constMethodKlass.hpp
- src/share/vm/oops/constMethodOop.cpp
- src/share/vm/oops/constMethodOop.hpp
+ src/share/vm/oops/constantPool.cpp
+ src/share/vm/oops/constantPool.hpp
- src/share/vm/oops/constantPoolKlass.cpp
- src/share/vm/oops/constantPoolKlass.hpp
- src/share/vm/oops/constantPoolOop.cpp
- src/share/vm/oops/constantPoolOop.hpp
+ src/share/vm/oops/cpCache.cpp
+ src/share/vm/oops/cpCache.hpp
- src/share/vm/oops/cpCacheKlass.cpp
- src/share/vm/oops/cpCacheKlass.hpp
- src/share/vm/oops/cpCacheOop.cpp
- src/share/vm/oops/cpCacheOop.hpp
! src/share/vm/oops/fieldInfo.hpp
! src/share/vm/oops/fieldStreams.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/generateOopMap.hpp
+ src/share/vm/oops/instanceClassLoaderKlass.cpp
+ src/share/vm/oops/instanceClassLoaderKlass.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
- src/share/vm/oops/instanceKlassKlass.cpp
- src/share/vm/oops/instanceKlassKlass.hpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.hpp
! src/share/vm/oops/instanceOop.hpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/instanceRefKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
- src/share/vm/oops/klassKlass.cpp
- src/share/vm/oops/klassKlass.hpp
- src/share/vm/oops/klassOop.cpp
- src/share/vm/oops/klassOop.hpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/markOop.cpp
! src/share/vm/oops/markOop.hpp
! src/share/vm/oops/markOop.inline.hpp
+ src/share/vm/oops/metadata.cpp
+ src/share/vm/oops/metadata.hpp
+ src/share/vm/oops/method.cpp
+ src/share/vm/oops/method.hpp
+ src/share/vm/oops/methodData.cpp
+ src/share/vm/oops/methodData.hpp
- src/share/vm/oops/methodDataKlass.cpp
- src/share/vm/oops/methodDataKlass.hpp
- src/share/vm/oops/methodDataOop.cpp
- src/share/vm/oops/methodDataOop.hpp
- src/share/vm/oops/methodKlass.cpp
- src/share/vm/oops/methodKlass.hpp
- src/share/vm/oops/methodOop.cpp
- src/share/vm/oops/methodOop.hpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/objArrayKlass.inline.hpp
- src/share/vm/oops/objArrayKlassKlass.cpp
- src/share/vm/oops/objArrayKlassKlass.hpp
! src/share/vm/oops/objArrayOop.cpp
! src/share/vm/oops/oop.cpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oop.inline2.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/symbol.cpp
! src/share/vm/oops/symbol.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.hpp
- src/share/vm/oops/typeArrayKlassKlass.cpp
- src/share/vm/oops/typeArrayKlassKlass.hpp
! src/share/vm/oops/typeArrayOop.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/machnode.hpp
! 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/multnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/forte.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jniCheck.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h
! src/share/vm/prims/jvm_misc.hpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.hpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiEnv.xsl
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiEnvThreadState.cpp
! src/share/vm/prims/jvmtiEnvThreadState.hpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiGetLoadedClasses.cpp
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/jvmtiLib.xsl
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/jvmtiThreadState.cpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/prims/jvmtiTrace.cpp
! src/share/vm/prims/methodComparator.cpp
! src/share/vm/prims/methodComparator.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/prims/privilegedStack.cpp
! src/share/vm/prims/privilegedStack.hpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/prims/wbtestmethods/parserTests.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/advancedThresholdPolicy.hpp
! src/share/vm/runtime/aprofiler.cpp
! src/share/vm/runtime/aprofiler.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/dtraceJSDT.cpp
! src/share/vm/runtime/fieldDescriptor.cpp
! src/share/vm/runtime/fieldDescriptor.hpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/frame.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/javaCalls.hpp
! src/share/vm/runtime/jfieldIDWorkaround.hpp
! src/share/vm/runtime/jniHandles.cpp
! src/share/vm/runtime/jniHandles.hpp
! src/share/vm/runtime/memprofiler.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/objectMonitor.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/perfData.hpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/reflection.hpp
! src/share/vm/runtime/reflectionUtils.cpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/relocator.cpp
! src/share/vm/runtime/relocator.hpp
! src/share/vm/runtime/rframe.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/runtime/signature.cpp
! src/share/vm/runtime/signature.hpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.hpp
! src/share/vm/runtime/simpleThresholdPolicy.inline.hpp
! src/share/vm/runtime/stackValue.cpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/unhandledOops.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframeArray.hpp
! src/share/vm/runtime/vframe_hp.cpp
! src/share/vm/runtime/vframe_hp.hpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vmStructs.hpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/classLoadingService.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/gcNotifier.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/heapDumper.hpp
! src/share/vm/services/lowMemoryDetector.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/memoryManager.cpp
! src/share/vm/services/memoryPool.cpp
! src/share/vm/services/memoryPool.hpp
! src/share/vm/services/memoryService.cpp
! src/share/vm/services/memoryService.hpp
! src/share/vm/services/psMemoryPool.cpp
! src/share/vm/services/psMemoryPool.hpp
! src/share/vm/services/serviceUtil.hpp
! src/share/vm/services/threadService.cpp
! src/share/vm/services/threadService.hpp
! src/share/vm/shark/sharkBuilder.cpp
! src/share/vm/shark/sharkCacheDecache.cpp
! src/share/vm/shark/sharkContext.cpp
! src/share/vm/shark/sharkContext.hpp
! src/share/vm/shark/sharkRuntime.cpp
! src/share/vm/shark/sharkRuntime.hpp
! src/share/vm/shark/sharkStack.cpp
! src/share/vm/shark/sharkState.cpp
! src/share/vm/shark/sharkTopLevelBlock.cpp
! src/share/vm/shark/sharkType.hpp
! src/share/vm/utilities/accessFlags.cpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/constantTag.cpp
! src/share/vm/utilities/constantTag.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/exceptions.cpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/growableArray.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp
! src/share/vm/utilities/xmlstream.cpp
! src/share/vm/utilities/xmlstream.hpp
! test/compiler/6859338/Test6859338.java



From kirk at kodewerk.com  Sat Sep  1 22:12:19 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Sun, 2 Sep 2012 00:12:19 +0200
Subject: NewRatio behaviour and some interesting PSYoungGen
In-Reply-To: <CABzyjyk+FjxbJZvCX4Tp87uzzeEyFwrT_j59SLE7GYeErQPKEw@mail.gmail.com>
References: <A6FEE496-A952-498B-A36A-FA5A54A5F1A5@kodewerk.com>
	<CABzyjyk+FjxbJZvCX4Tp87uzzeEyFwrT_j59SLE7GYeErQPKEw@mail.gmail.com>
Message-ID: <363222A6-9E7E-4450-80DB-10847BA8916B@kodewerk.com>


On 2012-09-01, at 11:08 PM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:

> 
> Hi Kirk -- Interesting questions... I will try and answer (albeit only partially) the last two questions  in your email, letting others address the other questions (as well as add to the following as appropriate).
> 
> On Fri, Aug 31, 2012 at 1:49 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> ... 
> 
> One other thing that I found interesting is that when using ParNew with CMS in combination with NewRatio. What I've seen is that when the VM is loaded in low ram Heap will resize young gen. However, for some unknown reason, the resize never happens when the VM is loaded higher up in memory. I first noticed this while running a benchmark at a conference. The demo worked as expected prior to my talk, failed during the talk, and then worked after the talk. The difference in the runs was that during the talk I had keynote and Chrome and a PDF reader and a few other things running. They were idle but they were (of course) consuming quite a bit of memory. After a little bit of experimentation I noted that the adaptivity of the JVM is some affected by where it lies in memory. In my case it wasn't swapping but maybe being higher ram causes enough extra work with the pointers that you end up with this side effect????? Pure speculation but would be interested in any thoughts.
> 
> I don't think that would be the case.
> 
> If you can recreate the conditions and run with a debug build you'd probably get more info. My guess is that you are short on swap as might happen when running with more active processes, you are unable to reserve swap for committing the expansion of the heap. So the expansion fails and you are unable to resize. The debug build of the JVM, from what i recall, issues a message indicating its inability to expand the heap. You might then try configuring more swap (and possibly RAM to avoid actually swapping) and see if the resize then happens with all of the programs in memory. What OS was this on?

This was running on OSX Snow Leopard, Lion and Mountain Lion. It's pretty consistent across all of the 6.0 and 7.0 versions of the JVM I've run.. and I'm intrigued by your explanation but I've been able to run VMs with much much larger heaps with lots of other things running. My heap setting (sorry I should have said this in the original email) -Xmx1g -XX:SurvivorRatio=1 -XX:NewRatio=1. I'll try running the bench using debug, with Linux and see how well it sticks.


> 
> 
> 
> One last thing, while spelunking through the code I ran into this.
> 
> 
> // This method currently does not expect to expand into eden (i.e.,
> // the virtual space boundaries is expected to be consistent
> // with the eden boundaries..
> void PSYoungGen::post_resize() {
>   assert_locked_or_safepoint(Heap_lock);
>   assert((eden_space()->bottom() < to_space()->bottom()) &&
>          (eden_space()->bottom() < from_space()->bottom()),
>          "Eden is assumed to be below the survivor spaces");
> 
>   MemRegion cmr((HeapWord*)virtual_space()->low(),
>                 (HeapWord*)virtual_space()->high());
>   Universe::heap()->barrier_set()->resize_covered_region(cmr);
>   space_invariants();
> }
> 
> The assertion, as I understand it, is asking if the bottom of to_space and from_space are both higher up in memory than the bottom of eden. Wouldn't you want to make sure that to or from is higher in memory than the top of eden?
> 
> You are right, but in fact the assert can and should be even stronger than even that, namely that the _end_ of  Eden (which is higher than its _top_ which is equal to its _bottom_, if Eden is empty, which it usually is at the end of a scavenge) is lower (smaller virtual address) than the _bottom_ of  the survivor spaces. Recall that top is the where new allocation occurs, and end is the absolute end of the space that new allocation cannot cross.

I've sloppily said top of eden when I should have said _end_of_Eden.
 
> 
> PS: Disclaimer: this is from memory, i haven't looked at the code in a while, just remembering the naming conventions used in the code as i remember it.

I think you've done quite well.

-- Kirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120902/d5e58dd3/attachment.htm>

From coleen.phillimore at oracle.com  Tue Sep  4 01:13:36 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 04 Sep 2012 01:13:36 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195823: NPG: CMS reserved() doesn't
	match _rs.base().
Message-ID: <20120904011339.4BF114788A@hg.openjdk.java.net>

Changeset: 03049e0e8544
Author:    coleenp
Date:      2012-09-03 18:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/03049e0e8544

7195823: NPG: CMS reserved() doesn't match _rs.base().
Summary: If the commit fails, the size isn't set so the assert fails.
Reviewed-by: kamg

! src/share/vm/memory/metaspace.cpp



From stefan.karlsson at oracle.com  Tue Sep  4 11:07:44 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 04 Sep 2012 13:07:44 +0200
Subject: Review request (XS): NPG: oopDesc::list_ptr_from_klass is broken
Message-ID: <5045E100.5030609@oracle.com>

http://cr.openjdk.java.net/~stefank/7195968/webrev/

Removed an incorrect cast.

 From the bug report:
With the following code in list_ptr_from_klass:
if (UseCompressedKlassPointers) {
return (oop)decode_heap_oop((oop)(address)_metadata._compressed_klass);

The _compressed_klass is casted to an oop, before being passed to 
decode_heap_oop. Because of this we call the wrong version of 
decode_heap_oop and fail to unpack the narrowOop.

This is a benign bug since this code path is never used. However, GCC 
4.6 complains with:
oop.inline.hpp: In member function ?oopDesc* 
oopDesc::list_ptr_from_klass()?:
oop.inline.hpp:138:57: error: cast to pointer from integer of different 
size [-Werror=int-to-pointer-cast]

StefanK


From coleen.phillimore at oracle.com  Tue Sep  4 11:39:04 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 04 Sep 2012 07:39:04 -0400
Subject: Review request (XS): NPG: oopDesc::list_ptr_from_klass is broken
In-Reply-To: <5045E100.5030609@oracle.com>
References: <5045E100.5030609@oracle.com>
Message-ID: <5045E858.6060504@oracle.com>

This looks good.   Please check this into hotspot-gc before the full 
integration up to hotspot-main if possible.
thanks,
Coleen

On 9/4/2012 7:07 AM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/7195968/webrev/
>
> Removed an incorrect cast.
>
> From the bug report:
> With the following code in list_ptr_from_klass:
> if (UseCompressedKlassPointers) {
> return (oop)decode_heap_oop((oop)(address)_metadata._compressed_klass);
>
> The _compressed_klass is casted to an oop, before being passed to 
> decode_heap_oop. Because of this we call the wrong version of 
> decode_heap_oop and fail to unpack the narrowOop.
>
> This is a benign bug since this code path is never used. However, GCC 
> 4.6 complains with:
> oop.inline.hpp: In member function ?oopDesc* 
> oopDesc::list_ptr_from_klass()?:
> oop.inline.hpp:138:57: error: cast to pointer from integer of 
> different size [-Werror=int-to-pointer-cast]
>
> StefanK



From bengt.rutisson at oracle.com  Tue Sep  4 11:44:11 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 04 Sep 2012 13:44:11 +0200
Subject: Review request (XS): NPG: oopDesc::list_ptr_from_klass is broken
In-Reply-To: <5045E100.5030609@oracle.com>
References: <5045E100.5030609@oracle.com>
Message-ID: <5045E98B.4030902@oracle.com>


Stefan,

Looks good!

In the long run I think we should remove the dead code, but this is a 
good fix for now.

Ship it!
Bengt

On 2012-09-04 13:07, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/7195968/webrev/
>
> Removed an incorrect cast.
>
> From the bug report:
> With the following code in list_ptr_from_klass:
> if (UseCompressedKlassPointers) {
> return (oop)decode_heap_oop((oop)(address)_metadata._compressed_klass);
>
> The _compressed_klass is casted to an oop, before being passed to 
> decode_heap_oop. Because of this we call the wrong version of 
> decode_heap_oop and fail to unpack the narrowOop.
>
> This is a benign bug since this code path is never used. However, GCC 
> 4.6 complains with:
> oop.inline.hpp: In member function ?oopDesc* 
> oopDesc::list_ptr_from_klass()?:
> oop.inline.hpp:138:57: error: cast to pointer from integer of 
> different size [-Werror=int-to-pointer-cast]
>
> StefanK



From stefan.karlsson at oracle.com  Tue Sep  4 17:27:57 2012
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Tue, 04 Sep 2012 17:27:57 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195968: NPG:
	oopDesc::list_ptr_from_klass is broken
Message-ID: <20120904172759.34A13478AC@hg.openjdk.java.net>

Changeset: 46c017102631
Author:    stefank
Date:      2012-09-04 13:01 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/46c017102631

7195968: NPG: oopDesc::list_ptr_from_klass is broken
Summary: Remove incorrect cast
Reviewed-by: brutisso, coleenp

! src/share/vm/oops/oop.inline.hpp



From jon.masamitsu at oracle.com  Tue Sep  4 23:16:52 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 04 Sep 2012 16:16:52 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <504664D4.1060500@oracle.com>
References: <504664D4.1060500@oracle.com>
Message-ID: <50468BE4.1000203@oracle.com>


7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong

The assertion failure was occurring at a point where an allocation by 
another thread could invalidate
the expected consistency. Created an unsafe version of used_in_bytes() 
for use in those cases.

http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/




From christian.thalinger at oracle.com  Wed Sep  5 03:39:57 2012
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Wed, 05 Sep 2012 03:39:57 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7196120: NPG: JSR 2292 test fails because
	missing fix for 7188911
Message-ID: <20120905034002.A3916478C7@hg.openjdk.java.net>

Changeset: d17383603741
Author:    twisti
Date:      2012-09-04 18:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d17383603741

7196120: NPG: JSR 2292 test fails because missing fix for 7188911
Reviewed-by: kvn, coleenp

! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/utilities/exceptions.hpp



From mikael.gerdin at oracle.com  Wed Sep  5 08:13:07 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 05 Sep 2012 10:13:07 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
Message-ID: <50470993.2060102@oracle.com>

Hi,

With the perm gen removal changes the number of memory pools exported by 
the VM has changed. This causes the tests 
java/lang/management/MemoryMXBean/MemoryTest.java and 
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.

My suggested fix is to modify the tests to work with VMs both with and 
without perm gen memory pools.

CR link:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
Webrev:
http://cr.openjdk.java.net/~mgerdin/7195557/webrev

I'd also like to request that this fix be allowed to be pushed to 
hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test 
failures in the hotspot testing before we integrate perm removal into jdk8.
With that I'll need someone to sponsor the push since I'm not a Committer.

Thanks
/Mikael

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From rickard.backman at oracle.com  Wed Sep  5 08:23:16 2012
From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=)
Date: Wed, 5 Sep 2012 10:23:16 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50470993.2060102@oracle.com>
References: <50470993.2060102@oracle.com>
Message-ID: <9E85EB0A-F2E2-42C4-8C14-660C9030C805@oracle.com>

Mikael,

the change looks good.

Thanks
/R

On Sep 5, 2012, at 10:13 AM, Mikael Gerdin wrote:

> Hi,
> 
> With the perm gen removal changes the number of memory pools exported by the VM has changed. This causes the tests java/lang/management/MemoryMXBean/MemoryTest.java and java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
> 
> My suggested fix is to modify the tests to work with VMs both with and without perm gen memory pools.
> 
> CR link:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
> Webrev:
> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
> 
> I'd also like to request that this fix be allowed to be pushed to hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test failures in the hotspot testing before we integrate perm removal into jdk8.
> With that I'll need someone to sponsor the push since I'm not a Committer.
> 
> Thanks
> /Mikael
> 
> -- 
> Mikael Gerdin
> Java SE VM SQE Stockholm



From bengt.rutisson at oracle.com  Wed Sep  5 08:52:11 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 05 Sep 2012 10:52:11 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50470993.2060102@oracle.com>
References: <50470993.2060102@oracle.com>
Message-ID: <504712BB.6000900@oracle.com>


Hi Mikael,

I think this looks good.

One minor thing. You kind of solved the same problem in two different 
ways. In CollectionUsageThreshold.java you reduce the expected number 
and then increase it if you find a perm gen pool. In 
MemoryMXBean/MemoryTest.java you left the expected value unchanged and 
only reduce it if we do not find a perm gen pool.

I think it would be cleaner to use the same approach for both tests and 
I think I prefer the way you did it in CollectionUsageThreshold.java 
since the "normal" case from now on should be that there is no perm gen.

Bengt

On 2012-09-05 10:13, Mikael Gerdin wrote:
> Hi,
>
> With the perm gen removal changes the number of memory pools exported 
> by the VM has changed. This causes the tests 
> java/lang/management/MemoryMXBean/MemoryTest.java and 
> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>
> My suggested fix is to modify the tests to work with VMs both with and 
> without perm gen memory pools.
>
> CR link:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
> Webrev:
> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>
> I'd also like to request that this fix be allowed to be pushed to 
> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test 
> failures in the hotspot testing before we integrate perm removal into 
> jdk8.
> With that I'll need someone to sponsor the push since I'm not a 
> Committer.
>
> Thanks
> /Mikael
>



From Alan.Bateman at oracle.com  Wed Sep  5 09:00:11 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 05 Sep 2012 10:00:11 +0100
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50470993.2060102@oracle.com>
References: <50470993.2060102@oracle.com>
Message-ID: <5047149B.2000200@oracle.com>

On 05/09/2012 09:13, Mikael Gerdin wrote:
> Hi,
>
> With the perm gen removal changes the number of memory pools exported 
> by the VM has changed. This causes the tests 
> java/lang/management/MemoryMXBean/MemoryTest.java and 
> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>
> My suggested fix is to modify the tests to work with VMs both with and 
> without perm gen memory pools.
>
> CR link:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
> Webrev:
> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>
> I'd also like to request that this fix be allowed to be pushed to 
> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test 
> failures in the hotspot testing before we integrate perm removal into 
> jdk8.
> With that I'll need someone to sponsor the push since I'm not a 
> Committer.
>
> Thanks
> /Mikael
>
It should okay to push this via the hsx/hotspot-gc forest, assuming of 
course that the tests in its jdk repository are actually used for the 
testing that you mention. One thing to know is that 
test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java is 
on the exclude list (see jdk/test/ProblemList.txt) so the test should 
not be run (so in Oracle this means it is excluded in JPRT, in testing 
of jdk8/tl, etc.). If you are happy that the test is now stable then it 
would be good to remove it, but I think you might want to check 7067973 
in case that issue and failure mode still exists.

-Alan.


From jon.masamitsu at oracle.com  Wed Sep  5 09:01:39 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Wed, 05 Sep 2012 09:01:39 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195789: NPG: assert(used + free ==
	capacity) failed: Accounting is wrong
Message-ID: <20120905090143.31C16478D1@hg.openjdk.java.net>

Changeset: 5d2156bcb78b
Author:    jmasa
Date:      2012-09-04 16:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5d2156bcb78b

7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong
Reviewed-by: coleenp, jcoomes

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp



From mikael.gerdin at oracle.com  Wed Sep  5 10:38:50 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 05 Sep 2012 12:38:50 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <504712BB.6000900@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
Message-ID: <50472BBA.7030904@oracle.com>

Bengt,

On 2012-09-05 10:52, Bengt Rutisson wrote:
>
> Hi Mikael,
>
> I think this looks good.
>
> One minor thing. You kind of solved the same problem in two different
> ways. In CollectionUsageThreshold.java you reduce the expected number
> and then increase it if you find a perm gen pool. In
> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
> only reduce it if we do not find a perm gen pool.
>
> I think it would be cleaner to use the same approach for both tests and
> I think I prefer the way you did it in CollectionUsageThreshold.java
> since the "normal" case from now on should be that there is no perm gen.

Good point, I agree that it looks strange, I've updated the MemoryTest 
changes to act in a similar way to CollectionUsageThreshold.

I've uploaded a new webrev with the updated version:
http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1

/Mikael

>
> Bengt
>
> On 2012-09-05 10:13, Mikael Gerdin wrote:
>> Hi,
>>
>> With the perm gen removal changes the number of memory pools exported
>> by the VM has changed. This causes the tests
>> java/lang/management/MemoryMXBean/MemoryTest.java and
>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>>
>> My suggested fix is to modify the tests to work with VMs both with and
>> without perm gen memory pools.
>>
>> CR link:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>> Webrev:
>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>
>> I'd also like to request that this fix be allowed to be pushed to
>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>> failures in the hotspot testing before we integrate perm removal into
>> jdk8.
>> With that I'll need someone to sponsor the push since I'm not a
>> Committer.
>>
>> Thanks
>> /Mikael
>>
>

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From bengt.rutisson at oracle.com  Wed Sep  5 11:29:40 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 05 Sep 2012 13:29:40 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50472BBA.7030904@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com>
Message-ID: <504737A4.5080403@oracle.com>


Thanks for the update, Mikael!

Looks good!

Bengt

On 2012-09-05 12:38, Mikael Gerdin wrote:
> Bengt,
>
> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>
>> Hi Mikael,
>>
>> I think this looks good.
>>
>> One minor thing. You kind of solved the same problem in two different
>> ways. In CollectionUsageThreshold.java you reduce the expected number
>> and then increase it if you find a perm gen pool. In
>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>> only reduce it if we do not find a perm gen pool.
>>
>> I think it would be cleaner to use the same approach for both tests and
>> I think I prefer the way you did it in CollectionUsageThreshold.java
>> since the "normal" case from now on should be that there is no perm gen.
>
> Good point, I agree that it looks strange, I've updated the MemoryTest 
> changes to act in a similar way to CollectionUsageThreshold.
>
> I've uploaded a new webrev with the updated version:
> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>
> /Mikael
>
>>
>> Bengt
>>
>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> With the perm gen removal changes the number of memory pools exported
>>> by the VM has changed. This causes the tests
>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to 
>>> fail.
>>>
>>> My suggested fix is to modify the tests to work with VMs both with and
>>> without perm gen memory pools.
>>>
>>> CR link:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>> Webrev:
>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>
>>> I'd also like to request that this fix be allowed to be pushed to
>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>> failures in the hotspot testing before we integrate perm removal into
>>> jdk8.
>>> With that I'll need someone to sponsor the push since I'm not a
>>> Committer.
>>>
>>> Thanks
>>> /Mikael
>>>
>>
>



From mikael.gerdin at oracle.com  Wed Sep  5 11:46:46 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 05 Sep 2012 13:46:46 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <5047149B.2000200@oracle.com>
References: <50470993.2060102@oracle.com> <5047149B.2000200@oracle.com>
Message-ID: <50473BA6.2070100@oracle.com>

Alan,

On 2012-09-05 11:00, Alan Bateman wrote:
> On 05/09/2012 09:13, Mikael Gerdin wrote:
>> Hi,
>>
>> With the perm gen removal changes the number of memory pools exported
>> by the VM has changed. This causes the tests
>> java/lang/management/MemoryMXBean/MemoryTest.java and
>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>>
>> My suggested fix is to modify the tests to work with VMs both with and
>> without perm gen memory pools.
>>
>> CR link:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>> Webrev:
>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>
>> I'd also like to request that this fix be allowed to be pushed to
>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>> failures in the hotspot testing before we integrate perm removal into
>> jdk8.
>> With that I'll need someone to sponsor the push since I'm not a
>> Committer.
>>
>> Thanks
>> /Mikael
>>
> It should okay to push this via the hsx/hotspot-gc forest, assuming of
> course that the tests in its jdk repository are actually used for the
> testing that you mention. One thing to know is that
> test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java is
> on the exclude list (see jdk/test/ProblemList.txt) so the test should
> not be run (so in Oracle this means it is excluded in JPRT, in testing
> of jdk8/tl, etc.). If you are happy that the test is now stable then it
> would be good to remove it, but I think you might want to check 7067973
> in case that issue and failure mode still exists.

Good point about looking up where the java/lang/management tests for 
hotspot-gc actually come from. It appears that we pick up the sources 
from the latest promoted build of jdk8 for those tests. So there's 
really no point in pushing the fix to hotspot-gc.
I guess I'll need someone to push this through 8-tl then when it's reviewed.

The nightly testing done on hotspot ignores ProblemList.txt so it's 
still run in our testing. I looked at the recent test execution history 
of CollectionUsageThreshold and I see some timeouts but only when 
running -XX:+UseG1GC and -XX:+ExplicitGCInvokesConcurrent

/Mikael

>
> -Alan.

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From Alan.Bateman at oracle.com  Wed Sep  5 12:04:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 05 Sep 2012 13:04:25 +0100
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50473BA6.2070100@oracle.com>
References: <50470993.2060102@oracle.com> <5047149B.2000200@oracle.com>
	<50473BA6.2070100@oracle.com>
Message-ID: <50473FC9.9020407@oracle.com>

On 05/09/2012 12:46, Mikael Gerdin wrote:
>
> Good point about looking up where the java/lang/management tests for 
> hotspot-gc actually come from. It appears that we pick up the sources 
> from the latest promoted build of jdk8 for those tests. So there's 
> really no point in pushing the fix to hotspot-gc.
> I guess I'll need someone to push this through 8-tl then when it's 
> reviewed.
>
> The nightly testing done on hotspot ignores ProblemList.txt so it's 
> still run in our testing. I looked at the recent test execution 
> history of CollectionUsageThreshold and I see some timeouts but only 
> when running -XX:+UseG1GC and -XX:+ExplicitGCInvokesConcurrent
>
I see 7173460 was created to track the G1 issue but it was fixed some 
time ago. Perhaps there is another (or new) failure mode now.

G1 aside, is the failure in 7067973 still relevant? If not then perhaps 
we should close that bug and as part of your changes then you could 
remove it from the ProblemList file.

-Alan.



From jon.masamitsu at oracle.com  Wed Sep  5 15:46:50 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 05 Sep 2012 08:46:50 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <50468BE4.1000203@oracle.com>
References: <504664D4.1060500@oracle.com> <50468BE4.1000203@oracle.com>
Message-ID: <504773EA.30907@oracle.com>

Based on review comments, this is a better fix for 7195789.

7196298: Better fix for 7195789

http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/


On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>
> 7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong
>
> The assertion failure was occurring at a point where an allocation by 
> another thread could invalidate
> the expected consistency. Created an unsafe version of used_in_bytes() 
> for use in those cases.
>
> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>
>


From stefan.karlsson at oracle.com  Wed Sep  5 15:57:03 2012
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Wed, 05 Sep 2012 15:57:03 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195935: NPG: Some issues with compressed
	oops
Message-ID: <20120905155708.0F1EB478E5@hg.openjdk.java.net>

Changeset: 044a77cd0c8b
Author:    stefank
Date:      2012-09-05 10:39 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/044a77cd0c8b

7195935: NPG: Some issues with compressed oops
Summary: Don't decompress the klass pointer in the G1 pre-barrier code when !UseCompressedKlassPointers
Reviewed-by: coleenp, brutisso

! src/share/vm/c1/c1_LIRGenerator.cpp



From roland.westrelin at oracle.com  Tue Sep  4 23:57:07 2012
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Tue, 04 Sep 2012 23:57:07 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7184649: NPG: Implement another
	MetdataPtr case
Message-ID: <20120904235710.12CE2478BC@hg.openjdk.java.net>

Changeset: ca11db66f9de
Author:    roland
Date:      2012-09-04 23:27 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ca11db66f9de

7184649: NPG: Implement another MetdataPtr case
Summary: xmeet when both inputs are MetadataPtr.
Reviewed-by: kvn

! src/share/vm/opto/type.cpp



From vladimir.kozlov at oracle.com  Wed Sep  5 20:17:39 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Wed, 05 Sep 2012 20:17:39 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7196167: NPG: mismerge in
	make/solaris/makefiles/fastdebug.make
Message-ID: <20120905201743.38457478FE@hg.openjdk.java.net>

Changeset: 78b56e53050e
Author:    kvn
Date:      2012-09-05 10:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/78b56e53050e

7196167: NPG: mismerge in make/solaris/makefiles/fastdebug.make
Summary: Remove the workaround of 7187454 problem which was restored incorrectly during NPG merge.
Reviewed-by: coleenp, dholmes

! make/solaris/makefiles/fastdebug.make



From bengt.rutisson at oracle.com  Wed Sep  5 21:13:15 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 05 Sep 2012 23:13:15 +0200
Subject: Request for review (s) - 7195789
In-Reply-To: <504773EA.30907@oracle.com>
References: <504664D4.1060500@oracle.com> <50468BE4.1000203@oracle.com>
	<504773EA.30907@oracle.com>
Message-ID: <5047C06B.9050006@oracle.com>


Hi Jon,

Thanks for proposing a fix even after the first change was pushed. I 
appreciate it!

I think it is a good idea to clean up the previous fix a bit, so thanks 
for sending out a new webrev. But if you have more important PermGen 
bugs to fix I think you should focus on them and disregard my comments 
below for now. From my perspective we can save 7196298 until things have 
calmed down a bit in the PermGen work.

On 2012-09-05 17:46, Jon Masamitsu wrote:
> Based on review comments, this is a better fix for 7195789.
>
> 7196298: Better fix for 7195789
>
> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/

I'm not so sure I like how the "unsafe" parameter propagates out in the 
code. It is only important for the assert and, as you mentioned in an 
earlier email, the assert is placed in MetaspaceAux::used_in_bytes() 
just to be somewhere. It does not necessarily have to be in that method. 
So, to me we are making the surrounding code more difficult to follow 
just to be able to add the assert.

How about making it more explicit? Maybe we can add a method 
MetaspaceAux::check_consitency() that looks something like:

void MetaspaceAux::check_consitency(Metaspace::MetadataType mdtype) {
   assert(SafepointSynchronize::is_at_safepoint(), "must be at safepoint");
   ClassLoaderDataGraphMetaspaceIterator iter;
   while (iter.repeat()) {
     Metaspace* msp = iter.get_next();
     if (msp != NULL) {
       size_t used = msp->used_words(mdtype);
       size_t free = msp->free_words(mdtype);
       size_t capacity = msp->capacity_words(mdtype);
       assert(used + free == capacity,
         err_msg("Accounting is wrong used " SIZE_FORMAT
                 " free " SIZE_FORMAT " capacity " SIZE_FORMAT,
                 used, free, capacity));
     }
   }
}

And make MetaspaceAux::used_in_bytes() simply be:

size_t MetaspaceAux::used_in_bytes(Metaspace::MetadataType mdtype) {
   size_t used = 0;
   ClassLoaderDataGraphMetaspaceIterator iter;
   while (iter.repeat()) {
     Metaspace* msp = iter.get_next();
     // Sum allocation_total for each metaspace
     if (msp != NULL) {
       used += msp->used_words(mdtype);
     }
   }
   return used * BytesPerWord;
}

That way we can explicity do:

   size_t metadata_prev_used = MetaspaceAux::used_in_bytes();
   debug_only(MetaspaceAux::check_consistency());

In places where we know we are at a safepoint.

Bengt


>
>
> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>>
>> 7195789: NPG: assert(used + free == capacity) failed: Accounting is 
>> wrong
>>
>> The assertion failure was occurring at a point where an allocation by 
>> another thread could invalidate
>> the expected consistency. Created an unsafe version of 
>> used_in_bytes() for use in those cases.
>>
>> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>>
>>



From John.Coomes at oracle.com  Wed Sep  5 23:19:20 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 5 Sep 2012 16:19:20 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <504773EA.30907@oracle.com>
References: <504664D4.1060500@oracle.com> <50468BE4.1000203@oracle.com>
	<504773EA.30907@oracle.com>
Message-ID: <20551.56824.303996.686924@oracle.com>

Jon Masamitsu (jon.masamitsu at oracle.com) wrote:
> Based on review comments, this is a better fix for 7195789.
> 
> 7196298: Better fix for 7195789
> 
> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/

Looks good to me.

-John

> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
> >
> > 7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong
> >
> > The assertion failure was occurring at a point where an allocation by 
> > another thread could invalidate
> > the expected consistency. Created an unsafe version of used_in_bytes() 
> > for use in those cases.
> >
> > http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
> >
> >


From jon.masamitsu at oracle.com  Wed Sep  5 23:50:11 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 05 Sep 2012 16:50:11 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <5047C06B.9050006@oracle.com>
References: <504664D4.1060500@oracle.com>
	<50468BE4.1000203@oracle.com>	<504773EA.30907@oracle.com>
	<5047C06B.9050006@oracle.com>
Message-ID: <5047E533.4070209@oracle.com>

Bengt,

The point of not complicating code unnecessarily is certainly
worth considering.  I have to smile a little though since your
suggestion does duplicate code.

The reason I put the consistency check where it is,
is that I'm doing the check without having to remember
to call another function.  It's strictly a convenience.

The current consistency check is actually not worth doing.
The original check had to do with a running sum that was
maintained as metadata was allocated but that's not there
anymore.  I'm going to delete the check and revert to
used_in_bytes() without the "bool unsafe".

Jon

On 9/5/2012 2:13 PM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Thanks for proposing a fix even after the first change was pushed. I 
> appreciate it!
>
> I think it is a good idea to clean up the previous fix a bit, so 
> thanks for sending out a new webrev. But if you have more important 
> PermGen bugs to fix I think you should focus on them and disregard my 
> comments below for now. From my perspective we can save 7196298 until 
> things have calmed down a bit in the PermGen work.
>
> On 2012-09-05 17:46, Jon Masamitsu wrote:
>> Based on review comments, this is a better fix for 7195789.
>>
>> 7196298: Better fix for 7195789
>>
>> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/
>
> I'm not so sure I like how the "unsafe" parameter propagates out in 
> the code. It is only important for the assert and, as you mentioned in 
> an earlier email, the assert is placed in 
> MetaspaceAux::used_in_bytes() just to be somewhere. It does not 
> necessarily have to be in that method. So, to me we are making the 
> surrounding code more difficult to follow just to be able to add the 
> assert.
>
> How about making it more explicit? Maybe we can add a method 
> MetaspaceAux::check_consitency() that looks something like:
>
> void MetaspaceAux::check_consitency(Metaspace::MetadataType mdtype) {
>   assert(SafepointSynchronize::is_at_safepoint(), "must be at 
> safepoint");
>   ClassLoaderDataGraphMetaspaceIterator iter;
>   while (iter.repeat()) {
>     Metaspace* msp = iter.get_next();
>     if (msp != NULL) {
>       size_t used = msp->used_words(mdtype);
>       size_t free = msp->free_words(mdtype);
>       size_t capacity = msp->capacity_words(mdtype);
>       assert(used + free == capacity,
>         err_msg("Accounting is wrong used " SIZE_FORMAT
>                 " free " SIZE_FORMAT " capacity " SIZE_FORMAT,
>                 used, free, capacity));
>     }
>   }
> }
>
> And make MetaspaceAux::used_in_bytes() simply be:
>
> size_t MetaspaceAux::used_in_bytes(Metaspace::MetadataType mdtype) {
>   size_t used = 0;
>   ClassLoaderDataGraphMetaspaceIterator iter;
>   while (iter.repeat()) {
>     Metaspace* msp = iter.get_next();
>     // Sum allocation_total for each metaspace
>     if (msp != NULL) {
>       used += msp->used_words(mdtype);
>     }
>   }
>   return used * BytesPerWord;
> }
>
> That way we can explicity do:
>
>   size_t metadata_prev_used = MetaspaceAux::used_in_bytes();
>   debug_only(MetaspaceAux::check_consistency());
>
> In places where we know we are at a safepoint.
>
> Bengt
>
>
>>
>>
>> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>>>
>>> 7195789: NPG: assert(used + free == capacity) failed: Accounting is 
>>> wrong
>>>
>>> The assertion failure was occurring at a point where an allocation 
>>> by another thread could invalidate
>>> the expected consistency. Created an unsafe version of 
>>> used_in_bytes() for use in those cases.
>>>
>>> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>>>
>>>
>


From coleen.phillimore at oracle.com  Thu Sep  6 02:57:47 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 06 Sep 2012 02:57:47 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195867: NPG: SAJDI tests fail with
	sun.jvm.hotspot.types.WrongTypeException: No suitable match for type
Message-ID: <20120906025752.CC40C47928@hg.openjdk.java.net>

Changeset: fa6e618671d7
Author:    coleenp
Date:      2012-09-05 20:08 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fa6e618671d7

7195867: NPG: SAJDI tests fail with sun.jvm.hotspot.types.WrongTypeException: No suitable match for type
Summary: Need to restore the vtable in metadata when we restore the type from the shared archive.
Reviewed-by: acorn, jcoomes, jmasa, jrose

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/method.hpp



From jon.masamitsu at oracle.com  Thu Sep  6 03:25:30 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 05 Sep 2012 20:25:30 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <20551.56824.303996.686924@oracle.com>
References: <504664D4.1060500@oracle.com>	<50468BE4.1000203@oracle.com>	<504773EA.30907@oracle.com>
	<20551.56824.303996.686924@oracle.com>
Message-ID: <504817AA.7010307@oracle.com>

Thanks for the review, but there is another version coming.  It's 
getting simpler.

Jon

On 9/5/2012 4:19 PM, John Coomes wrote:
> Jon Masamitsu (jon.masamitsu at oracle.com) wrote:
>> Based on review comments, this is a better fix for 7195789.
>>
>> 7196298: Better fix for 7195789
>>
>> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/
> Looks good to me.
>
> -John
>
>> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>>> 7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong
>>>
>>> The assertion failure was occurring at a point where an allocation by
>>> another thread could invalidate
>>> the expected consistency. Created an unsafe version of used_in_bytes()
>>> for use in those cases.
>>>
>>> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>>>
>>>


From bengt.rutisson at oracle.com  Thu Sep  6 03:38:52 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 06 Sep 2012 05:38:52 +0200
Subject: Request for review (s) - 7195789
In-Reply-To: <5047E533.4070209@oracle.com>
References: <504664D4.1060500@oracle.com>
	<50468BE4.1000203@oracle.com>	<504773EA.30907@oracle.com>
	<5047C06B.9050006@oracle.com> <5047E533.4070209@oracle.com>
Message-ID: <50481ACC.6000808@oracle.com>


Jon,

On 2012-09-06 01:50, Jon Masamitsu wrote:
> Bengt,
>
> The point of not complicating code unnecessarily is certainly
> worth considering.  I have to smile a little though since your
> suggestion does duplicate code.

Point taken. :-)

But to my defense the duplicated code with the check_consistency() 
method is just boiler plate in the same way that there is code 
duplication between MetaspaceAux::used_in_bytes(), 
MetaspaceAux::free_in_bytes() and MetaspaceAux::capacity_in_bytes(). If 
we want to change how used_in_bytes() is really calculated there is only 
one place to change with my suggestion.

> The reason I put the consistency check where it is,
> is that I'm doing the check without having to remember
> to call another function.  It's strictly a convenience.
>
> The current consistency check is actually not worth doing.
> The original check had to do with a running sum that was
> maintained as metadata was allocated but that's not there
> anymore.  I'm going to delete the check and revert to
> used_in_bytes() without the "bool unsafe".

I agree that the simplest solution is to remove the check, but I don't 
fully understand why the check is less important now than before.

Anyway, thanks for keeping the interest in this small issue and it 
sounds good to me to remove the assert.

Bengt

>
> Jon
>
> On 9/5/2012 2:13 PM, Bengt Rutisson wrote:
>>
>> Hi Jon,
>>
>> Thanks for proposing a fix even after the first change was pushed. I 
>> appreciate it!
>>
>> I think it is a good idea to clean up the previous fix a bit, so 
>> thanks for sending out a new webrev. But if you have more important 
>> PermGen bugs to fix I think you should focus on them and disregard my 
>> comments below for now. From my perspective we can save 7196298 until 
>> things have calmed down a bit in the PermGen work.
>>
>> On 2012-09-05 17:46, Jon Masamitsu wrote:
>>> Based on review comments, this is a better fix for 7195789.
>>>
>>> 7196298: Better fix for 7195789
>>>
>>> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/
>>
>> I'm not so sure I like how the "unsafe" parameter propagates out in 
>> the code. It is only important for the assert and, as you mentioned 
>> in an earlier email, the assert is placed in 
>> MetaspaceAux::used_in_bytes() just to be somewhere. It does not 
>> necessarily have to be in that method. So, to me we are making the 
>> surrounding code more difficult to follow just to be able to add the 
>> assert.
>>
>> How about making it more explicit? Maybe we can add a method 
>> MetaspaceAux::check_consitency() that looks something like:
>>
>> void MetaspaceAux::check_consitency(Metaspace::MetadataType mdtype) {
>>   assert(SafepointSynchronize::is_at_safepoint(), "must be at 
>> safepoint");
>>   ClassLoaderDataGraphMetaspaceIterator iter;
>>   while (iter.repeat()) {
>>     Metaspace* msp = iter.get_next();
>>     if (msp != NULL) {
>>       size_t used = msp->used_words(mdtype);
>>       size_t free = msp->free_words(mdtype);
>>       size_t capacity = msp->capacity_words(mdtype);
>>       assert(used + free == capacity,
>>         err_msg("Accounting is wrong used " SIZE_FORMAT
>>                 " free " SIZE_FORMAT " capacity " SIZE_FORMAT,
>>                 used, free, capacity));
>>     }
>>   }
>> }
>>
>> And make MetaspaceAux::used_in_bytes() simply be:
>>
>> size_t MetaspaceAux::used_in_bytes(Metaspace::MetadataType mdtype) {
>>   size_t used = 0;
>>   ClassLoaderDataGraphMetaspaceIterator iter;
>>   while (iter.repeat()) {
>>     Metaspace* msp = iter.get_next();
>>     // Sum allocation_total for each metaspace
>>     if (msp != NULL) {
>>       used += msp->used_words(mdtype);
>>     }
>>   }
>>   return used * BytesPerWord;
>> }
>>
>> That way we can explicity do:
>>
>>   size_t metadata_prev_used = MetaspaceAux::used_in_bytes();
>>   debug_only(MetaspaceAux::check_consistency());
>>
>> In places where we know we are at a safepoint.
>>
>> Bengt
>>
>>
>>>
>>>
>>> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>>>>
>>>> 7195789: NPG: assert(used + free == capacity) failed: Accounting is 
>>>> wrong
>>>>
>>>> The assertion failure was occurring at a point where an allocation 
>>>> by another thread could invalidate
>>>> the expected consistency. Created an unsafe version of 
>>>> used_in_bytes() for use in those cases.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>>>>
>>>>
>>



From jon.masamitsu at oracle.com  Thu Sep  6 03:54:46 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 05 Sep 2012 20:54:46 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <504773EA.30907@oracle.com>
References: <504664D4.1060500@oracle.com> <50468BE4.1000203@oracle.com>
	<504773EA.30907@oracle.com>
Message-ID: <50481E86.5060205@oracle.com>

New version that just deletes the consistency checking.

http://cr.openjdk.java.net/~jmasa/7196298/webrev.01/

Thanks.

Jon

On 9/5/2012 8:46 AM, Jon Masamitsu wrote:
> Based on review comments, this is a better fix for 7195789.
>
> 7196298: Better fix for 7195789
>
> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/
>
>
> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>>
>> 7195789: NPG: assert(used + free == capacity) failed: Accounting is 
>> wrong
>>
>> The assertion failure was occurring at a point where an allocation by 
>> another thread could invalidate
>> the expected consistency. Created an unsafe version of 
>> used_in_bytes() for use in those cases.
>>
>> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>>
>>


From bengt.rutisson at oracle.com  Thu Sep  6 04:29:48 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 6 Sep 2012 06:29:48 +0200
Subject: Request for review (s) - 7195789
In-Reply-To: <50481E86.5060205@oracle.com>
References: <504664D4.1060500@oracle.com> <50468BE4.1000203@oracle.com>
	<504773EA.30907@oracle.com> <50481E86.5060205@oracle.com>
Message-ID: <45C489BA-46A6-4EA7-8490-154826302357@oracle.com>


Looks good.

Bengt

6 sep 2012 kl. 05:54 skrev Jon Masamitsu <jon.masamitsu at oracle.com>:

> New version that just deletes the consistency checking.
> 
> http://cr.openjdk.java.net/~jmasa/7196298/webrev.01/
> 
> Thanks.
> 
> Jon
> 
> On 9/5/2012 8:46 AM, Jon Masamitsu wrote:
>> Based on review comments, this is a better fix for 7195789.
>> 
>> 7196298: Better fix for 7195789
>> 
>> http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/
>> 
>> 
>> On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
>>> 
>>> 7195789: NPG: assert(used + free == capacity) failed: Accounting is wrong
>>> 
>>> The assertion failure was occurring at a point where an allocation by another thread could invalidate
>>> the expected consistency. Created an unsafe version of used_in_bytes() for use in those cases.
>>> 
>>> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
>>> 
>>> 


From John.Coomes at oracle.com  Thu Sep  6 04:47:30 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Wed, 5 Sep 2012 21:47:30 -0700
Subject: Request for review (s) - 7195789
In-Reply-To: <50481E86.5060205@oracle.com>
References: <504664D4.1060500@oracle.com> <50468BE4.1000203@oracle.com>
	<504773EA.30907@oracle.com> <50481E86.5060205@oracle.com>
Message-ID: <20552.10978.456341.722881@oracle.com>

Jon Masamitsu (jon.masamitsu at oracle.com) wrote:
> New version that just deletes the consistency checking.
> 
> http://cr.openjdk.java.net/~jmasa/7196298/webrev.01/

Looks fine.

-John

> On 9/5/2012 8:46 AM, Jon Masamitsu wrote:
> > Based on review comments, this is a better fix for 7195789.
> >
> > 7196298: Better fix for 7195789
> >
> > http://cr.openjdk.java.net/~jmasa/7196298/webrev.00/
> >
> >
> > On 9/4/2012 4:16 PM, Jon Masamitsu wrote:
> >>
> >> 7195789: NPG: assert(used + free == capacity) failed: Accounting is 
> >> wrong
> >>
> >> The assertion failure was occurring at a point where an allocation by 
> >> another thread could invalidate
> >> the expected consistency. Created an unsafe version of 
> >> used_in_bytes() for use in those cases.
> >>
> >> http://cr.openjdk.java.net/~jmasa/7195789/webrev.00/
> >>
> >>


From mikael.gerdin at oracle.com  Thu Sep  6 06:54:55 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 06 Sep 2012 08:54:55 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50472BBA.7030904@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com>
Message-ID: <504848BF.6030906@oracle.com>

Somehow serviceability-dev was dropped from the CC list.
I uploaded a new webrev since I thought Bengt had a point about being 
consistent.
We talked about where to integrate the fix during the perm gen removal 
meeting and decided that we'd like to push this through jdk8/tl/jdk
since we're not in a rush for the bug fix, it's already marked as a 
known failure.

Can someone from the jdk8 project please Review this fix?
Thanks
/Mikael

On 2012-09-05 12:38, Mikael Gerdin wrote:
> Bengt,
>
> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>
>> Hi Mikael,
>>
>> I think this looks good.
>>
>> One minor thing. You kind of solved the same problem in two different
>> ways. In CollectionUsageThreshold.java you reduce the expected number
>> and then increase it if you find a perm gen pool. In
>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>> only reduce it if we do not find a perm gen pool.
>>
>> I think it would be cleaner to use the same approach for both tests and
>> I think I prefer the way you did it in CollectionUsageThreshold.java
>> since the "normal" case from now on should be that there is no perm gen.
>
> Good point, I agree that it looks strange, I've updated the MemoryTest
> changes to act in a similar way to CollectionUsageThreshold.
>
> I've uploaded a new webrev with the updated version:
> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>
> /Mikael
>
>>
>> Bengt
>>
>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> With the perm gen removal changes the number of memory pools exported
>>> by the VM has changed. This causes the tests
>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>>>
>>> My suggested fix is to modify the tests to work with VMs both with and
>>> without perm gen memory pools.
>>>
>>> CR link:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>> Webrev:
>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>
>>> I'd also like to request that this fix be allowed to be pushed to
>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>> failures in the hotspot testing before we integrate perm removal into
>>> jdk8.
>>> With that I'll need someone to sponsor the push since I'm not a
>>> Committer.
>>>
>>> Thanks
>>> /Mikael
>>>
>>
>

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From bengt.rutisson at oracle.com  Thu Sep  6 06:58:28 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 06 Sep 2012 08:58:28 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <504848BF.6030906@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
Message-ID: <50484994.8080406@oracle.com>


Thanks, Mikael! I think this fix looks good also when sent out to the 
serviceability mailing list :-)

I am not a JDK reviewer...

Bengt

On 2012-09-06 08:54, Mikael Gerdin wrote:
> Somehow serviceability-dev was dropped from the CC list.
> I uploaded a new webrev since I thought Bengt had a point about being 
> consistent.
> We talked about where to integrate the fix during the perm gen removal 
> meeting and decided that we'd like to push this through jdk8/tl/jdk
> since we're not in a rush for the bug fix, it's already marked as a 
> known failure.
>
> Can someone from the jdk8 project please Review this fix?
> Thanks
> /Mikael
>
> On 2012-09-05 12:38, Mikael Gerdin wrote:
>> Bengt,
>>
>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>
>>> Hi Mikael,
>>>
>>> I think this looks good.
>>>
>>> One minor thing. You kind of solved the same problem in two different
>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>> and then increase it if you find a perm gen pool. In
>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>>> only reduce it if we do not find a perm gen pool.
>>>
>>> I think it would be cleaner to use the same approach for both tests and
>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>> since the "normal" case from now on should be that there is no perm 
>>> gen.
>>
>> Good point, I agree that it looks strange, I've updated the MemoryTest
>> changes to act in a similar way to CollectionUsageThreshold.
>>
>> I've uploaded a new webrev with the updated version:
>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>
>> /Mikael
>>
>>>
>>> Bengt
>>>
>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>> Hi,
>>>>
>>>> With the perm gen removal changes the number of memory pools exported
>>>> by the VM has changed. This causes the tests
>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to 
>>>> fail.
>>>>
>>>> My suggested fix is to modify the tests to work with VMs both with and
>>>> without perm gen memory pools.
>>>>
>>>> CR link:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>
>>>> I'd also like to request that this fix be allowed to be pushed to
>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>>> failures in the hotspot testing before we integrate perm removal into
>>>> jdk8.
>>>> With that I'll need someone to sponsor the push since I'm not a
>>>> Committer.
>>>>
>>>> Thanks
>>>> /Mikael
>>>>
>>>
>>
>



From david.holmes at oracle.com  Thu Sep  6 09:04:16 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 06 Sep 2012 19:04:16 +1000
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <B2A6F6EE-652E-4BD2-94CC-A3ABDCAD8414@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
	<50484994.8080406@oracle.com>
	<B2A6F6EE-652E-4BD2-94CC-A3ABDCAD8414@oracle.com>
Message-ID: <50486710.1050308@oracle.com>

On 6/09/2012 5:07 PM, Staffan Larsen wrote:
> Looks good to me, too.

Me too.

> Not a Reviewer, either.

I am :)

David
-----

> /Staffan
>
> On 6 sep 2012, at 08:58, Bengt Rutisson<bengt.rutisson at oracle.com>  wrote:
>
>>
>> Thanks, Mikael! I think this fix looks good also when sent out to the serviceability mailing list :-)
>>
>> I am not a JDK reviewer...
>>
>> Bengt
>>
>> On 2012-09-06 08:54, Mikael Gerdin wrote:
>>> Somehow serviceability-dev was dropped from the CC list.
>>> I uploaded a new webrev since I thought Bengt had a point about being consistent.
>>> We talked about where to integrate the fix during the perm gen removal meeting and decided that we'd like to push this through jdk8/tl/jdk
>>> since we're not in a rush for the bug fix, it's already marked as a known failure.
>>>
>>> Can someone from the jdk8 project please Review this fix?
>>> Thanks
>>> /Mikael
>>>
>>> On 2012-09-05 12:38, Mikael Gerdin wrote:
>>>> Bengt,
>>>>
>>>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>>>
>>>>> Hi Mikael,
>>>>>
>>>>> I think this looks good.
>>>>>
>>>>> One minor thing. You kind of solved the same problem in two different
>>>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>>>> and then increase it if you find a perm gen pool. In
>>>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>>>>> only reduce it if we do not find a perm gen pool.
>>>>>
>>>>> I think it would be cleaner to use the same approach for both tests and
>>>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>>>> since the "normal" case from now on should be that there is no perm gen.
>>>>
>>>> Good point, I agree that it looks strange, I've updated the MemoryTest
>>>> changes to act in a similar way to CollectionUsageThreshold.
>>>>
>>>> I've uploaded a new webrev with the updated version:
>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> Bengt
>>>>>
>>>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> With the perm gen removal changes the number of memory pools exported
>>>>>> by the VM has changed. This causes the tests
>>>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>>>>>>
>>>>>> My suggested fix is to modify the tests to work with VMs both with and
>>>>>> without perm gen memory pools.
>>>>>>
>>>>>> CR link:
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>>>
>>>>>> I'd also like to request that this fix be allowed to be pushed to
>>>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>>>>> failures in the hotspot testing before we integrate perm removal into
>>>>>> jdk8.
>>>>>> With that I'll need someone to sponsor the push since I'm not a
>>>>>> Committer.
>>>>>>
>>>>>> Thanks
>>>>>> /Mikael
>>>>>>
>>>>>
>>>>
>>>
>>
>


From mikael.gerdin at oracle.com  Thu Sep  6 10:53:22 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 06 Sep 2012 12:53:22 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50486710.1050308@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
	<50484994.8080406@oracle.com>
	<B2A6F6EE-652E-4BD2-94CC-A3ABDCAD8414@oracle.com>
	<50486710.1050308@oracle.com>
Message-ID: <504880A2.80900@oracle.com>

Thanks for the reviews,
I'll try to get someone here in Stockholm to push this to jdk8 for me.

/Mikael

On 2012-09-06 11:04, David Holmes wrote:
> On 6/09/2012 5:07 PM, Staffan Larsen wrote:
>> Looks good to me, too.
>
> Me too.
>
>> Not a Reviewer, either.
>
> I am :)
>
> David
> -----
>
>> /Staffan
>>
>> On 6 sep 2012, at 08:58, Bengt Rutisson<bengt.rutisson at oracle.com>
>> wrote:
>>
>>>
>>> Thanks, Mikael! I think this fix looks good also when sent out to the
>>> serviceability mailing list :-)
>>>
>>> I am not a JDK reviewer...
>>>
>>> Bengt
>>>
>>> On 2012-09-06 08:54, Mikael Gerdin wrote:
>>>> Somehow serviceability-dev was dropped from the CC list.
>>>> I uploaded a new webrev since I thought Bengt had a point about
>>>> being consistent.
>>>> We talked about where to integrate the fix during the perm gen
>>>> removal meeting and decided that we'd like to push this through
>>>> jdk8/tl/jdk
>>>> since we're not in a rush for the bug fix, it's already marked as a
>>>> known failure.
>>>>
>>>> Can someone from the jdk8 project please Review this fix?
>>>> Thanks
>>>> /Mikael
>>>>
>>>> On 2012-09-05 12:38, Mikael Gerdin wrote:
>>>>> Bengt,
>>>>>
>>>>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Mikael,
>>>>>>
>>>>>> I think this looks good.
>>>>>>
>>>>>> One minor thing. You kind of solved the same problem in two different
>>>>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>>>>> and then increase it if you find a perm gen pool. In
>>>>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged
>>>>>> and
>>>>>> only reduce it if we do not find a perm gen pool.
>>>>>>
>>>>>> I think it would be cleaner to use the same approach for both
>>>>>> tests and
>>>>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>>>>> since the "normal" case from now on should be that there is no
>>>>>> perm gen.
>>>>>
>>>>> Good point, I agree that it looks strange, I've updated the MemoryTest
>>>>> changes to act in a similar way to CollectionUsageThreshold.
>>>>>
>>>>> I've uploaded a new webrev with the updated version:
>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> Bengt
>>>>>>
>>>>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> With the perm gen removal changes the number of memory pools
>>>>>>> exported
>>>>>>> by the VM has changed. This causes the tests
>>>>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
>>>>>>> to fail.
>>>>>>>
>>>>>>> My suggested fix is to modify the tests to work with VMs both
>>>>>>> with and
>>>>>>> without perm gen memory pools.
>>>>>>>
>>>>>>> CR link:
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>>>>
>>>>>>> I'd also like to request that this fix be allowed to be pushed to
>>>>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these
>>>>>>> test
>>>>>>> failures in the hotspot testing before we integrate perm removal
>>>>>>> into
>>>>>>> jdk8.
>>>>>>> With that I'll need someone to sponsor the push since I'm not a
>>>>>>> Committer.
>>>>>>>
>>>>>>> Thanks
>>>>>>> /Mikael
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From jon.masamitsu at oracle.com  Thu Sep  6 15:05:44 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 06 Sep 2012 08:05:44 -0700
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <504848BF.6030906@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
Message-ID: <5048BBC8.5080801@oracle.com>

Mikael,

Does the code in CollectionUsageThreshold.java
happen to work if perm is the last memory pool
in the list and the test

  139                 if (result.size() == numMemoryPools) {
  140                     break;
  141                 }

exits the loop having never seen perm (so not incrementing
numMemoryPools?

Jon

On 09/05/12 23:54, Mikael Gerdin wrote:
> Somehow serviceability-dev was dropped from the CC list.
> I uploaded a new webrev since I thought Bengt had a point about being 
> consistent.
> We talked about where to integrate the fix during the perm gen removal 
> meeting and decided that we'd like to push this through jdk8/tl/jdk
> since we're not in a rush for the bug fix, it's already marked as a 
> known failure.
>
> Can someone from the jdk8 project please Review this fix?
> Thanks
> /Mikael
>
> On 2012-09-05 12:38, Mikael Gerdin wrote:
>> Bengt,
>>
>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>
>>> Hi Mikael,
>>>
>>> I think this looks good.
>>>
>>> One minor thing. You kind of solved the same problem in two different
>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>> and then increase it if you find a perm gen pool. In
>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>>> only reduce it if we do not find a perm gen pool.
>>>
>>> I think it would be cleaner to use the same approach for both tests and
>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>> since the "normal" case from now on should be that there is no perm 
>>> gen.
>>
>> Good point, I agree that it looks strange, I've updated the MemoryTest
>> changes to act in a similar way to CollectionUsageThreshold.
>>
>> I've uploaded a new webrev with the updated version:
>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>
>> /Mikael
>>
>>>
>>> Bengt
>>>
>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>> Hi,
>>>>
>>>> With the perm gen removal changes the number of memory pools exported
>>>> by the VM has changed. This causes the tests
>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to 
>>>> fail.
>>>>
>>>> My suggested fix is to modify the tests to work with VMs both with and
>>>> without perm gen memory pools.
>>>>
>>>> CR link:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>
>>>> I'd also like to request that this fix be allowed to be pushed to
>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>>> failures in the hotspot testing before we integrate perm removal into
>>>> jdk8.
>>>> With that I'll need someone to sponsor the push since I'm not a
>>>> Committer.
>>>>
>>>> Thanks
>>>> /Mikael
>>>>
>>>
>>
>


From staffan.larsen at oracle.com  Thu Sep  6 07:07:38 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 6 Sep 2012 09:07:38 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <50484994.8080406@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
	<50484994.8080406@oracle.com>
Message-ID: <B2A6F6EE-652E-4BD2-94CC-A3ABDCAD8414@oracle.com>

Looks good to me, too.

Not a Reviewer, either.
/Staffan

On 6 sep 2012, at 08:58, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:

> 
> Thanks, Mikael! I think this fix looks good also when sent out to the serviceability mailing list :-)
> 
> I am not a JDK reviewer...
> 
> Bengt
> 
> On 2012-09-06 08:54, Mikael Gerdin wrote:
>> Somehow serviceability-dev was dropped from the CC list.
>> I uploaded a new webrev since I thought Bengt had a point about being consistent.
>> We talked about where to integrate the fix during the perm gen removal meeting and decided that we'd like to push this through jdk8/tl/jdk
>> since we're not in a rush for the bug fix, it's already marked as a known failure.
>> 
>> Can someone from the jdk8 project please Review this fix?
>> Thanks
>> /Mikael
>> 
>> On 2012-09-05 12:38, Mikael Gerdin wrote:
>>> Bengt,
>>> 
>>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>> 
>>>> Hi Mikael,
>>>> 
>>>> I think this looks good.
>>>> 
>>>> One minor thing. You kind of solved the same problem in two different
>>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>>> and then increase it if you find a perm gen pool. In
>>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>>>> only reduce it if we do not find a perm gen pool.
>>>> 
>>>> I think it would be cleaner to use the same approach for both tests and
>>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>>> since the "normal" case from now on should be that there is no perm gen.
>>> 
>>> Good point, I agree that it looks strange, I've updated the MemoryTest
>>> changes to act in a similar way to CollectionUsageThreshold.
>>> 
>>> I've uploaded a new webrev with the updated version:
>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>> 
>>> /Mikael
>>> 
>>>> 
>>>> Bengt
>>>> 
>>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>>> Hi,
>>>>> 
>>>>> With the perm gen removal changes the number of memory pools exported
>>>>> by the VM has changed. This causes the tests
>>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
>>>>> 
>>>>> My suggested fix is to modify the tests to work with VMs both with and
>>>>> without perm gen memory pools.
>>>>> 
>>>>> CR link:
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>> 
>>>>> I'd also like to request that this fix be allowed to be pushed to
>>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>>>> failures in the hotspot testing before we integrate perm removal into
>>>>> jdk8.
>>>>> With that I'll need someone to sponsor the push since I'm not a
>>>>> Committer.
>>>>> 
>>>>> Thanks
>>>>> /Mikael
>>>>> 
>>>> 
>>> 
>> 
> 



From mikael.gerdin at oracle.com  Thu Sep  6 15:40:30 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 06 Sep 2012 17:40:30 +0200
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <5048BBC8.5080801@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
	<5048BBC8.5080801@oracle.com>
Message-ID: <5048C3EE.1090205@oracle.com>

(adding serviceability-dev again)
Jon

On 2012-09-06 17:05, Jon Masamitsu wrote:
> Mikael,
>
> Does the code in CollectionUsageThreshold.java
> happen to work if perm is the last memory pool
> in the list and the test
>
>   139                 if (result.size() == numMemoryPools) {
>   140                     break;
>   141                 }
>
> exits the loop having never seen perm (so not incrementing
> numMemoryPools?

Good point. I'll have to look at this tomorrow. Unfortunately this 
version of the fix has already been pushed so if we need to fix this 
I'll open a new CR.

/Mikael

>
> Jon
>
> On 09/05/12 23:54, Mikael Gerdin wrote:
>> Somehow serviceability-dev was dropped from the CC list.
>> I uploaded a new webrev since I thought Bengt had a point about being
>> consistent.
>> We talked about where to integrate the fix during the perm gen removal
>> meeting and decided that we'd like to push this through jdk8/tl/jdk
>> since we're not in a rush for the bug fix, it's already marked as a
>> known failure.
>>
>> Can someone from the jdk8 project please Review this fix?
>> Thanks
>> /Mikael
>>
>> On 2012-09-05 12:38, Mikael Gerdin wrote:
>>> Bengt,
>>>
>>> On 2012-09-05 10:52, Bengt Rutisson wrote:
>>>>
>>>> Hi Mikael,
>>>>
>>>> I think this looks good.
>>>>
>>>> One minor thing. You kind of solved the same problem in two different
>>>> ways. In CollectionUsageThreshold.java you reduce the expected number
>>>> and then increase it if you find a perm gen pool. In
>>>> MemoryMXBean/MemoryTest.java you left the expected value unchanged and
>>>> only reduce it if we do not find a perm gen pool.
>>>>
>>>> I think it would be cleaner to use the same approach for both tests and
>>>> I think I prefer the way you did it in CollectionUsageThreshold.java
>>>> since the "normal" case from now on should be that there is no perm
>>>> gen.
>>>
>>> Good point, I agree that it looks strange, I've updated the MemoryTest
>>> changes to act in a similar way to CollectionUsageThreshold.
>>>
>>> I've uploaded a new webrev with the updated version:
>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev.1
>>>
>>> /Mikael
>>>
>>>>
>>>> Bengt
>>>>
>>>> On 2012-09-05 10:13, Mikael Gerdin wrote:
>>>>> Hi,
>>>>>
>>>>> With the perm gen removal changes the number of memory pools exported
>>>>> by the VM has changed. This causes the tests
>>>>> java/lang/management/MemoryMXBean/MemoryTest.java and
>>>>> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to
>>>>> fail.
>>>>>
>>>>> My suggested fix is to modify the tests to work with VMs both with and
>>>>> without perm gen memory pools.
>>>>>
>>>>> CR link:
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195557
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mgerdin/7195557/webrev
>>>>>
>>>>> I'd also like to request that this fix be allowed to be pushed to
>>>>> hsx/hotspot-gc/jdk instead of 8-tl/jdk so we can get rid of these test
>>>>> failures in the hotspot testing before we integrate perm removal into
>>>>> jdk8.
>>>>> With that I'll need someone to sponsor the push since I'm not a
>>>>> Committer.
>>>>>
>>>>> Thanks
>>>>> /Mikael
>>>>>
>>>>
>>>
>>

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From jon.masamitsu at oracle.com  Thu Sep  6 16:35:20 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Thu, 06 Sep 2012 16:35:20 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7196298: Better fix for 7195789
Message-ID: <20120906163523.0AC704793B@hg.openjdk.java.net>

Changeset: 942bb29b20b0
Author:    jmasa
Date:      2012-09-06 07:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/942bb29b20b0

7196298: Better fix for 7195789
Reviewed-by: jcoomes, brutisso

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp



From mandy.chung at oracle.com  Thu Sep  6 21:59:10 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 06 Sep 2012 14:59:10 -0700
Subject: Review request (S) 7195557 NPG: Unexpected number of memory pools
In-Reply-To: <5048C3EE.1090205@oracle.com>
References: <50470993.2060102@oracle.com> <504712BB.6000900@oracle.com>
	<50472BBA.7030904@oracle.com> <504848BF.6030906@oracle.com>
	<5048BBC8.5080801@oracle.com> <5048C3EE.1090205@oracle.com>
Message-ID: <50491CAE.4070600@oracle.com>

Mikael,

On 9/6/2012 8:40 AM, Mikael Gerdin wrote:
> On 2012-09-06 17:05, Jon Masamitsu wrote:
>> Mikael,
>>
>> Does the code in CollectionUsageThreshold.java
>> happen to work if perm is the last memory pool
>> in the list and the test
>>
>>   139                 if (result.size() == numMemoryPools) {
>>   140                     break;
>>   141                 }
>>
>> exits the loop having never seen perm (so not incrementing
>> numMemoryPools?
>
> Good point. I'll have to look at this tomorrow. Unfortunately this 
> version of the fix has already been pushed so if we need to fix this 
> I'll open a new CR. 
FYI - the following check was added as part of the fix for:
   4959889 Spec change: Revise low memory detection mechanism

    if (result.size() != EXPECTED_NUM_POOLS) {
        throw new RuntimeException("Unexpected number of selected pools");
    }

I believe L139-141 is a test bug that should have been removed
when the above check was added.  The next time when you modify
this test, it'd be good to consider modernizing this test to
use for-each and generics.  Many of the j.l.m. tests were written
during the development of JDK 5 language support.

Hope this helps.
Mandy




From john.coomes at oracle.com  Fri Sep  7 10:04:08 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Sep 2012 10:04:08 +0000
Subject: hg: hsx/hotspot-gc: 2 new changesets
Message-ID: <20120907100408.9A5A947978@hg.openjdk.java.net>

Changeset: b85b44cced24
Author:    jcoomes
Date:      2012-09-05 12:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b85b44cced24

7196361: add hotspot/make/closed to hgforest.sh
Reviewed-by: ohair

! make/scripts/hgforest.sh

Changeset: 76844579fa4b
Author:    katleman
Date:      2012-09-06 17:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/76844579fa4b

Added tag jdk8-b55 for changeset b85b44cced24

! .hgtags



From john.coomes at oracle.com  Fri Sep  7 10:04:16 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Sep 2012 10:04:16 +0000
Subject: hg: hsx/hotspot-gc/corba: 4 new changesets
Message-ID: <20120907100420.D2C1447979@hg.openjdk.java.net>

Changeset: 18a02ad8dc73
Author:    coffeys
Date:      2012-08-16 10:33 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/18a02ad8dc73

7056731: Race condition in CORBA code causes re-use of ABORTed connections
Reviewed-by: lancea
Contributed-by: d.macdonald at auckland.ac.nz

! src/share/classes/com/sun/corba/se/impl/transport/CorbaResponseWaitingRoomImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java

Changeset: d086e67eb9dd
Author:    lana
Date:      2012-08-27 10:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/d086e67eb9dd

Merge


Changeset: e8a0e84383d6
Author:    lana
Date:      2012-08-30 20:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/e8a0e84383d6

Merge


Changeset: bf1bb47414e1
Author:    katleman
Date:      2012-09-06 17:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/bf1bb47414e1

Added tag jdk8-b55 for changeset e8a0e84383d6

! .hgtags



From john.coomes at oracle.com  Fri Sep  7 10:04:31 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Sep 2012 10:04:31 +0000
Subject: hg: hsx/hotspot-gc/jaxp: 4 new changesets
Message-ID: <20120907100448.687C64797A@hg.openjdk.java.net>

Changeset: 2946807a6d7f
Author:    joehw
Date:      2012-08-17 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/2946807a6d7f

7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected
Summary: similar to the patch for 6756677 for XMLInputFactory and XMLOutputFactory, this patch fixes an error in XMLEventFactory where factoryId was taken as factory class.
Reviewed-by: lancea

! src/javax/xml/stream/XMLEventFactory.java

Changeset: 933d0234670f
Author:    lana
Date:      2012-08-27 10:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/933d0234670f

Merge


Changeset: 7c2363666890
Author:    lana
Date:      2012-08-30 20:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/7c2363666890

Merge


Changeset: f19d63b2119a
Author:    katleman
Date:      2012-09-06 17:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/f19d63b2119a

Added tag jdk8-b55 for changeset 7c2363666890

! .hgtags



From john.coomes at oracle.com  Fri Sep  7 10:04:59 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Sep 2012 10:04:59 +0000
Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b55 for changeset
	109c9e1f2d85
Message-ID: <20120907100505.192F64797B@hg.openjdk.java.net>

Changeset: 7813455ccdb0
Author:    katleman
Date:      2012-09-06 17:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/7813455ccdb0

Added tag jdk8-b55 for changeset 109c9e1f2d85

! .hgtags



From john.coomes at oracle.com  Fri Sep  7 10:07:29 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Sep 2012 10:07:29 +0000
Subject: hg: hsx/hotspot-gc/jdk: 85 new changesets
Message-ID: <20120907102637.365A24797C@hg.openjdk.java.net>

Changeset: baf30df50ce3
Author:    andrew
Date:      2012-08-23 15:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/baf30df50ce3

7192804: Build should not install jvisualvm man page for OpenJDK
Summary: OpenJDK builds don't ship VisualVM so shouldn't ship its man page either.
Reviewed-by: dholmes

! make/common/Release.gmk
! makefiles/Images.gmk

Changeset: 70ad0ed1d6ce
Author:    katleman
Date:      2012-08-29 15:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/70ad0ed1d6ce

Merge


Changeset: 906acc4f3c78
Author:    katleman
Date:      2012-08-30 10:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/906acc4f3c78

Added tag jdk8-b54 for changeset 70ad0ed1d6ce

! .hgtags

Changeset: a4f0043a5621
Author:    jrose
Date:      2012-08-17 13:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a4f0043a5621

7191102: nightly failures after JSR 292 lazy method handle update (round 3)
Reviewed-by: twisti, kvn

! src/share/classes/java/lang/invoke/BoundMethodHandle.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/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/SimpleMethodHandle.java
! src/share/classes/java/lang/invoke/WrongMethodTypeException.java
! src/share/classes/sun/invoke/util/ValueConversions.java
+ test/java/lang/invoke/BigArityTest.java
- test/java/lang/invoke/MaxTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/RicochetTest.java
! test/sun/invoke/util/ValueConversionsTest.java

Changeset: 26a8b57bd6c0
Author:    twisti
Date:      2012-08-24 15:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/26a8b57bd6c0

Merge

- test/java/lang/invoke/MaxTest.java

Changeset: a43f1cd05776
Author:    jrose
Date:      2012-08-28 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a43f1cd05776

7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa
Reviewed-by: kvn, twisti

! src/share/classes/java/lang/invoke/MemberName.java

Changeset: 59231f2cb6e1
Author:    twisti
Date:      2012-08-28 14:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/59231f2cb6e1

7194662: JSR 292: PermuteArgsTest times out in nightly test runs
Reviewed-by: kvn

! test/java/lang/invoke/PermuteArgsTest.java

Changeset: 3f42c0d924d2
Author:    twisti
Date:      2012-08-31 15:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3f42c0d924d2

Merge


Changeset: ecc1c8085ec7
Author:    bae
Date:      2012-08-17 11:22 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ecc1c8085ec7

7150594: VM chash in JCK api/java_awt/Image/ConvolveOp/ tests for 64 bit jdk8 on linux.
Reviewed-by: jgodinez, prr

! src/share/native/sun/awt/medialib/mlib_sys.c

Changeset: 61076e7e3c04
Author:    lana
Date:      2012-08-27 11:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/61076e7e3c04

Merge

- src/share/classes/java/lang/invoke/AdapterMethodHandle.java
- src/share/classes/java/lang/invoke/CountingMethodHandle.java

Changeset: b41845694f39
Author:    serb
Date:      2012-08-13 17:43 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b41845694f39

7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders
Reviewed-by: art, anthony
Contributed-by: Marco Dinacci <marco.dinacci at gmail.com>

! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java
! src/macosx/native/sun/awt/CFileDialog.h
! src/macosx/native/sun/awt/CFileDialog.m

Changeset: adbef77870e1
Author:    leonidr
Date:      2012-08-13 17:53 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/adbef77870e1

7159381: [macosx] Dock Icon defaults to Generic Java Application Category
Reviewed-by: anthony

! src/macosx/native/sun/osxapp/NSApplicationAWT.h
! src/macosx/native/sun/osxapp/NSApplicationAWT.m

Changeset: f63010f4655d
Author:    kizune
Date:      2012-08-13 19:19 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f63010f4655d

Merge


Changeset: 0025dab4c283
Author:    kizune
Date:      2012-08-13 19:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0025dab4c283

7177144: [macosx] Drag and drop not working (regression in 7u6)
Reviewed-by: art, serb

! src/share/classes/java/awt/EventQueue.java

Changeset: f003387c33ad
Author:    omajid
Date:      2012-08-14 17:11 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f003387c33ad

7190813: (launcher) RPATH needs to have additional paths
Reviewed-by: anthony, ksrini

! make/common/Program.gmk
! make/sun/jawt/Makefile
+ test/tools/launcher/RunpathTest.java

Changeset: 164919db548b
Author:    rupashka
Date:      2012-08-15 14:33 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/164919db548b

7190543: Nimbus LaF: regression: JSplitPane is not opaque -- or should it?
Reviewed-by: alexsch

+ test/javax/swing/JSplitPane/4201995/bug4201995.java

Changeset: 65d874d16d59
Author:    serb
Date:      2012-08-15 15:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/65d874d16d59

7172187: [macosx] JAWT native CALayer not positioned over Canvas
Reviewed-by: art, anthony

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/PlatformComponent.java
! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java
! src/macosx/native/sun/awt/AWTSurfaceLayers.m

Changeset: 8d570757fe95
Author:    rupashka
Date:      2012-08-17 17:04 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8d570757fe95

7190597: Nimbus: regtest for 4235420 fails
Reviewed-by: alexsch

+ test/javax/swing/JTable/4235420/bug4235420.java

Changeset: 2fe9c1f0b16b
Author:    dingxmin
Date:      2012-08-20 13:16 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2fe9c1f0b16b

7188612: JTable's AccessibleJTable throws IllegalComponentStateException instead of null
Reviewed-by: rupashka

! src/share/classes/javax/swing/JTable.java
+ test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java

Changeset: fbf21a561c45
Author:    malenkov
Date:      2012-08-20 13:38 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fbf21a561c45

7189112: java.beans.Introspector misses write methods
Reviewed-by: rupashka

! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/Test7189112.java

Changeset: 8a2bc6e82d81
Author:    rupashka
Date:      2012-08-21 14:37 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8a2bc6e82d81

6866747: J2SE_Swing_Reg:can not see any HSB tab
Reviewed-by: alexsch

- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: d769dbb87c49
Author:    zhouyx
Date:      2012-08-24 11:35 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d769dbb87c49

7193169: The code example in javadoc of Component.java misses 'implements' keyword
Reviewed-by: anthony

! src/share/classes/java/awt/Component.java

Changeset: e3122759abe3
Author:    anthony
Date:      2012-08-24 14:58 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e3122759abe3

7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941)
Summary: Constrain window dimensions with screen bounds and GL_MAX_TEXTURE_SIZE
Reviewed-by: art, serb

! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/PlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m
+ src/share/classes/sun/awt/TextureSizeConstraining.java
+ test/java/awt/Frame/HugeFrame/HugeFrame.java

Changeset: eaec23aae76a
Author:    lana
Date:      2012-08-27 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eaec23aae76a

Merge

- src/share/classes/java/lang/invoke/AdapterMethodHandle.java
- src/share/classes/java/lang/invoke/CountingMethodHandle.java

Changeset: f54660c18774
Author:    serb
Date:      2012-08-28 16:04 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f54660c18774

7186371: [macosx] Main menu shortcuts not displayed (7u6 regression)
Reviewed-by: leonidr

! src/macosx/classes/com/apple/laf/ScreenMenuItem.java
! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java

Changeset: 5378c339ed47
Author:    lana
Date:      2012-08-28 12:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5378c339ed47

Merge

- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: 717ed00b7787
Author:    sherman
Date:      2012-08-09 10:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/717ed00b7787

7189363: Regex Pattern compilation buggy for special sequences
Summary: fixed the incorrect implementation in expr(...)
Reviewed-by: psandoz, alanb

! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java

Changeset: 57b5025548d6
Author:    mullan
Date:      2012-08-10 09:12 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/57b5025548d6

7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null
Reviewed-by: valeriep

! src/share/classes/sun/security/provider/certpath/BasicChecker.java

Changeset: 629f357fc17b
Author:    mullan
Date:      2012-08-10 09:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/629f357fc17b

Merge


Changeset: 114fbbeb8f75
Author:    valeriep
Date:      2012-08-10 13:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/114fbbeb8f75

7107613: scalability bloker in javax.crypto.CryptoPermissions
Summary: Changed the type of field "perms" from Hashtable to ConcurrentHashMap.
Reviewed-by: weijun, xuelei

! src/share/classes/javax/crypto/CryptoPermissions.java

Changeset: 175036ada2e3
Author:    valeriep
Date:      2012-08-10 13:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/175036ada2e3

7107616: scalability bloker in javax.crypto.JceSecurityManager
Summary: Changed the type of field "exemptCache" from HashMap to ConcurrentHashMap.
Reviewed-by: weijun, xuelei

! src/share/classes/javax/crypto/JceSecurityManager.java

Changeset: 9e97dacbfd35
Author:    valeriep
Date:      2012-08-10 13:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9e97dacbfd35

7185471: Avoid key expansion when AES cipher is re-init w/ the same key
Summary: Saved the last cipher key value and skip key expansion if key value is the same.
Reviewed-by: weijun, xuelei

! src/share/classes/com/sun/crypto/provider/AESCrypt.java

Changeset: 449c17c7a63a
Author:    lana
Date:      2012-08-10 12:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/449c17c7a63a

Merge


Changeset: e8b14276d434
Author:    lana
Date:      2012-08-10 14:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e8b14276d434

Merge


Changeset: e7d125f2575b
Author:    chegar
Date:      2012-08-12 22:56 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e7d125f2575b

7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c
Reviewed-by: chegar
Contributed-by: Christian Schulte <cs at schulte.it>

! src/share/classes/sun/net/spi/DefaultProxySelector.java
+ test/java/net/ProxySelector/MultiThreadedSystemProxies.java

Changeset: bf0c6f91bc22
Author:    luchsh
Date:      2012-08-13 19:51 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bf0c6f91bc22

7190219: (bf) CharBuffer.put(String,int,int) modifies position even if BufferOverflowException thrown
Reviewed-by: alanb

! 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: 399c2adf3ad6
Author:    chegar
Date:      2012-08-13 13:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/399c2adf3ad6

7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value
Reviewed-by: chegar
Contributed-by: Shirish Kuncolienkar <shirishk at linux.vnet.ibm.com>

! src/solaris/native/java/net/NetworkInterface.c

Changeset: 5e5bdfd18325
Author:    vinnie
Date:      2012-08-13 14:06 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e5bdfd18325

7190945: pkcs11 problem loading NSS libs on Ubuntu
Reviewed-by: xuelei, alanb

! src/share/classes/sun/security/pkcs11/Secmod.java
! test/sun/security/pkcs11/PKCS11Test.java
! test/sun/security/pkcs11/Secmod/keystore.jks

Changeset: f0bf7358ba23
Author:    jfranck
Date:      2012-08-09 17:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f0bf7358ba23

7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy
Reviewed-by: darcy, jjg

+ src/share/classes/java/lang/annotation/ContainedBy.java
- src/share/classes/java/lang/annotation/ContainerAnnotation.java

Changeset: 35e024c6a62c
Author:    andrew
Date:      2012-08-15 14:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/35e024c6a62c

7110151: Use underlying platform's zlib library for Java zlib support
Summary: Make SYSTEM_ZLIB more flexible by using ZLIB_{CFLAGS,LIBS} and building on more than just MACOSX.
Reviewed-by: sherman, alanb

! make/com/sun/java/pack/Makefile
! make/common/Program.gmk
! make/common/shared/Defs-linux.gmk
! make/common/shared/Defs-macosx.gmk
! make/common/shared/Defs-solaris.gmk
! make/java/jli/Makefile
! make/java/zip/Makefile
! make/jdk_generic_profile.sh
! make/sun/splashscreen/Makefile
! src/share/native/com/sun/java/util/jar/pack/defines.h
! src/share/native/java/util/zip/Adler32.c
! src/share/native/java/util/zip/CRC32.c
! src/share/native/java/util/zip/Deflater.c
! src/share/native/java/util/zip/Inflater.c
! src/share/native/java/util/zip/zip_util.c

Changeset: da14e2c90bcb
Author:    robm
Date:      2012-08-15 22:46 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/da14e2c90bcb

6931128: (spec) File attribute tests fail when run as root.
Reviewed-by: alanb

! src/share/classes/java/io/File.java
! test/java/io/File/Basic.java
! test/java/io/File/SetAccess.java
! test/java/io/File/SetReadOnly.java
! test/java/io/File/SymLinks.java
+ test/java/io/File/Util.java

Changeset: 39b01268b845
Author:    coffeys
Date:      2012-08-16 10:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/39b01268b845

7056731: Race condition in CORBA code causes re-use of ABORTed connections
Reviewed-by: lancea
Contributed-by: d.macdonald at auckland.ac.nz

! test/Makefile
+ test/com/sun/corba/cachedSocket/7056731.sh
+ test/com/sun/corba/cachedSocket/Hello.idl
+ test/com/sun/corba/cachedSocket/HelloClient.java
+ test/com/sun/corba/cachedSocket/HelloServer.java

Changeset: 56d8756749bd
Author:    coffeys
Date:      2012-08-16 10:48 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/56d8756749bd

7185965: Build error in javadoc make stage for bundles not containing crypto package
Reviewed-by: chegar

! make/common/shared/Defs-java.gmk

Changeset: e48a9a1c14e3
Author:    alanb
Date:      2012-08-16 11:14 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e48a9a1c14e3

7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code
Reviewed-by: andrew

! make/java/nio/Makefile
! make/java/nio/mapfile-bsd
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java
! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c
! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c
! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c
! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c
! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c

Changeset: 4fb8792725d5
Author:    alanb
Date:      2012-08-16 11:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4fb8792725d5

7191892: ProblemList.txt updates (8/2012)
Reviewed-by: alanb
Contributed-by: amy.lu at oracle.com

! test/ProblemList.txt

Changeset: e50a39d011b5
Author:    alanb
Date:      2012-08-16 14:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e50a39d011b5

7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin
Reviewed-by: alanb
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/ProblemList.txt
! test/java/rmi/registry/readTest/readTest.sh

Changeset: 4993f8aa7f2e
Author:    dingxmin
Date:      2012-08-17 17:10 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4993f8aa7f2e

7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms
Reviewed-by: chegar

! src/solaris/native/java/net/PlainDatagramSocketImpl.c

Changeset: 6b2ebf3c4964
Author:    mullan
Date:      2012-08-17 14:32 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6b2ebf3c4964

6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank
Reviewed-by: mullan
Contributed-by: jason.uh at oracle.com

! src/share/classes/sun/security/x509/URIName.java
+ test/sun/security/x509/URIName/Parse.java

Changeset: 509421263cdd
Author:    dcubed
Date:      2012-08-17 12:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/509421263cdd

7191322: add test for 7064927 to java.lang.instrument
Summary: Add support for canRetransform attribute to the test manager. Add test for 7064927.
Reviewed-by: dsamersoff, sspitsyn, ohair

! test/java/lang/instrument/ATransformerManagementTestCase.java
+ test/java/lang/instrument/DummyClassWithLVT.java
+ test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java
+ test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh
+ test/java/lang/instrument/retransformAgent.mf

Changeset: 16f2865aac24
Author:    ksrini
Date:      2012-08-17 08:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/16f2865aac24

7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java

Changeset: a2359f0f9533
Author:    alanb
Date:      2012-08-19 13:03 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a2359f0f9533

7192275: Minimize LogManager dependencies on java.beans
Summary: Reduce dependency to PropertyChangeListener and PropertyChangeEvent. Also add basic test coverage.
Reviewed-by: dcubed, dsamersoff, mchung

! src/share/classes/java/util/logging/LogManager.java
+ test/java/util/logging/Listeners.java
+ test/java/util/logging/ListenersWithSM.java
+ test/java/util/logging/java.policy

Changeset: 5e7cfe034df4
Author:    alanb
Date:      2012-08-19 13:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e7cfe034df4

7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11]
Reviewed-by: chegar

! src/solaris/classes/sun/nio/fs/SolarisWatchService.java
! test/java/nio/file/WatchService/MayFlies.java

Changeset: 86c963b1dbf8
Author:    weijun
Date:      2012-08-20 07:59 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/86c963b1dbf8

7192202: Make sure keytool prints both unknown and unparseable extensions
Reviewed-by: mullan

+ test/sun/security/tools/keytool/UnknownAndUnparseable.java

Changeset: 59aa7660ade4
Author:    robm
Date:      2012-08-20 14:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/59aa7660ade4

7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896
Reviewed-by: dholmes, alanb

! test/java/lang/ProcessBuilder/Basic.java

Changeset: 6d29c2af040f
Author:    alanb
Date:      2012-08-21 13:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6d29c2af040f

7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close
Reviewed-by: alanb
Contributed-by: Shirish Kuncolienkar <shirishk at linux.vnet.ibm.com>

! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java
+ test/java/nio/channels/SelectionKey/RacyRegister.java

Changeset: 131a683a2ce0
Author:    naoto
Date:      2012-08-21 11:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/131a683a2ce0

6336885: RFE: Locale Data Deployment Enhancements
4609153: Provide locale data for Indic locales
5104387: Support for gl_ES locale (galician language)
6337471: desktop/system locale preferences support
7056139: (cal) SPI support for locale-dependent Calendar parameters
7058206: Provide CalendarData SPI for week params and display field value names
7073852: Support multiple scripts for digits and decimal symbols per locale
7079560: [Fmt-Da] Context dependent month names support in SimpleDateFormat
7171324: getAvailableLocales() of locale sensitive services should return the actual availability of locales
7151414: (cal) Support calendar type identification
7168528: LocaleServiceProvider needs to be aware of Locale extensions
7171372: (cal) locale's default Calendar should be created if unknown calendar is specified
Summary: JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (part 1 w/o packaging changes. by Naoto Sato and Masayoshi Okutsu)
Reviewed-by: erikj, sherman, peytoia

! make/java/java/Exportedfiles.gmk
! make/java/java/FILES_c.gmk
! make/java/java/FILES_java.gmk
! make/java/java/Makefile
! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/java/mapfile-vers
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/java/util/Makefile
! make/sun/Makefile
+ make/sun/cldr/Makefile
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! make/sun/text/Makefile
! make/tools/Makefile
+ make/tools/cldrconverter/Makefile
+ make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
+ make/tools/src/build/tools/cldrconverter/Bundle.java
+ make/tools/src/build/tools/cldrconverter/BundleGenerator.java
+ make/tools/src/build/tools/cldrconverter/CLDRConverter.java
+ make/tools/src/build/tools/cldrconverter/CalendarType.java
+ make/tools/src/build/tools/cldrconverter/Container.java
+ make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java
+ make/tools/src/build/tools/cldrconverter/Entry.java
+ make/tools/src/build/tools/cldrconverter/IgnoredContainer.java
+ make/tools/src/build/tools/cldrconverter/KeyContainer.java
+ make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
+ make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
+ make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java
+ make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
+ make/tools/src/build/tools/cldrconverter/StringArrayElement.java
+ make/tools/src/build/tools/cldrconverter/StringArrayEntry.java
+ make/tools/src/build/tools/cldrconverter/StringEntry.java
+ make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java
+ make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java
! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java
! makefiles/CreateJars.gmk
! makefiles/GendataBreakIterator.gmk
! makefiles/GenerateJavaSources.gmk
+ makefiles/GensrcCLDR.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! makefiles/GensrcProperties.gmk
! makefiles/Tools.gmk
+ src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
+ src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
- src/share/classes/java/text/BreakDictionary.java
! src/share/classes/java/text/BreakIterator.java
- src/share/classes/java/text/CollationRules.java
! src/share/classes/java/text/Collator.java
! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
! src/share/classes/java/text/NumberFormat.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/TimeZone.java
+ src/share/classes/java/util/spi/CalendarDataProvider.java
! src/share/classes/java/util/spi/CurrencyNameProvider.java
! src/share/classes/java/util/spi/LocaleServiceProvider.java
! src/share/classes/javax/swing/JSpinner.java
- src/share/classes/sun/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
! src/share/classes/sun/text/resources/FormatData.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
+ src/share/classes/sun/text/resources/ar/CollationData_ar.java
+ src/share/classes/sun/text/resources/ar/FormatData_ar.java
+ src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java
+ src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java
+ src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java
+ src/share/classes/sun/text/resources/be/CollationData_be.java
+ src/share/classes/sun/text/resources/be/FormatData_be.java
+ src/share/classes/sun/text/resources/be/FormatData_be_BY.java
+ src/share/classes/sun/text/resources/bg/CollationData_bg.java
+ src/share/classes/sun/text/resources/bg/FormatData_bg.java
+ src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java
+ src/share/classes/sun/text/resources/ca/CollationData_ca.java
+ src/share/classes/sun/text/resources/ca/FormatData_ca.java
+ src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java
+ src/share/classes/sun/text/resources/cs/CollationData_cs.java
+ src/share/classes/sun/text/resources/cs/FormatData_cs.java
+ src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java
+ src/share/classes/sun/text/resources/da/CollationData_da.java
+ src/share/classes/sun/text/resources/da/FormatData_da.java
+ src/share/classes/sun/text/resources/da/FormatData_da_DK.java
+ src/share/classes/sun/text/resources/de/FormatData_de.java
+ src/share/classes/sun/text/resources/de/FormatData_de_AT.java
+ src/share/classes/sun/text/resources/de/FormatData_de_CH.java
+ src/share/classes/sun/text/resources/de/FormatData_de_DE.java
+ src/share/classes/sun/text/resources/de/FormatData_de_LU.java
+ src/share/classes/sun/text/resources/el/CollationData_el.java
+ src/share/classes/sun/text/resources/el/FormatData_el.java
+ src/share/classes/sun/text/resources/el/FormatData_el_CY.java
+ src/share/classes/sun/text/resources/el/FormatData_el_GR.java
+ src/share/classes/sun/text/resources/en/FormatData_en.java
+ src/share/classes/sun/text/resources/en/FormatData_en_AU.java
+ src/share/classes/sun/text/resources/en/FormatData_en_CA.java
+ src/share/classes/sun/text/resources/en/FormatData_en_GB.java
+ src/share/classes/sun/text/resources/en/FormatData_en_IE.java
+ src/share/classes/sun/text/resources/en/FormatData_en_IN.java
+ src/share/classes/sun/text/resources/en/FormatData_en_MT.java
+ src/share/classes/sun/text/resources/en/FormatData_en_NZ.java
+ src/share/classes/sun/text/resources/en/FormatData_en_PH.java
+ src/share/classes/sun/text/resources/en/FormatData_en_SG.java
+ src/share/classes/sun/text/resources/en/FormatData_en_US.java
+ src/share/classes/sun/text/resources/en/FormatData_en_ZA.java
+ src/share/classes/sun/text/resources/es/CollationData_es.java
+ src/share/classes/sun/text/resources/es/FormatData_es.java
+ src/share/classes/sun/text/resources/es/FormatData_es_AR.java
+ src/share/classes/sun/text/resources/es/FormatData_es_BO.java
+ src/share/classes/sun/text/resources/es/FormatData_es_CL.java
+ src/share/classes/sun/text/resources/es/FormatData_es_CO.java
+ src/share/classes/sun/text/resources/es/FormatData_es_CR.java
+ src/share/classes/sun/text/resources/es/FormatData_es_DO.java
+ src/share/classes/sun/text/resources/es/FormatData_es_EC.java
+ src/share/classes/sun/text/resources/es/FormatData_es_ES.java
+ src/share/classes/sun/text/resources/es/FormatData_es_GT.java
+ src/share/classes/sun/text/resources/es/FormatData_es_HN.java
+ src/share/classes/sun/text/resources/es/FormatData_es_MX.java
+ src/share/classes/sun/text/resources/es/FormatData_es_NI.java
+ src/share/classes/sun/text/resources/es/FormatData_es_PA.java
+ src/share/classes/sun/text/resources/es/FormatData_es_PE.java
+ src/share/classes/sun/text/resources/es/FormatData_es_PR.java
+ src/share/classes/sun/text/resources/es/FormatData_es_PY.java
+ src/share/classes/sun/text/resources/es/FormatData_es_SV.java
+ src/share/classes/sun/text/resources/es/FormatData_es_US.java
+ src/share/classes/sun/text/resources/es/FormatData_es_UY.java
+ src/share/classes/sun/text/resources/es/FormatData_es_VE.java
+ src/share/classes/sun/text/resources/et/CollationData_et.java
+ src/share/classes/sun/text/resources/et/FormatData_et.java
+ src/share/classes/sun/text/resources/et/FormatData_et_EE.java
+ src/share/classes/sun/text/resources/fi/CollationData_fi.java
+ src/share/classes/sun/text/resources/fi/FormatData_fi.java
+ src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java
+ src/share/classes/sun/text/resources/fr/CollationData_fr.java
+ src/share/classes/sun/text/resources/fr/FormatData_fr.java
+ src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java
+ src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java
+ src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java
+ src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java
+ src/share/classes/sun/text/resources/ga/FormatData_ga.java
+ src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java
+ src/share/classes/sun/text/resources/hi/CollationData_hi.java
+ src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
+ src/share/classes/sun/text/resources/hr/CollationData_hr.java
+ src/share/classes/sun/text/resources/hr/FormatData_hr.java
+ src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java
+ src/share/classes/sun/text/resources/hu/CollationData_hu.java
+ src/share/classes/sun/text/resources/hu/FormatData_hu.java
+ src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java
+ src/share/classes/sun/text/resources/in/FormatData_in.java
+ src/share/classes/sun/text/resources/in/FormatData_in_ID.java
+ src/share/classes/sun/text/resources/is/CollationData_is.java
+ src/share/classes/sun/text/resources/is/FormatData_is.java
+ src/share/classes/sun/text/resources/is/FormatData_is_IS.java
+ src/share/classes/sun/text/resources/it/FormatData_it.java
+ src/share/classes/sun/text/resources/it/FormatData_it_CH.java
+ src/share/classes/sun/text/resources/it/FormatData_it_IT.java
+ src/share/classes/sun/text/resources/iw/CollationData_iw.java
+ src/share/classes/sun/text/resources/iw/FormatData_iw.java
+ src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java
+ src/share/classes/sun/text/resources/ja/CollationData_ja.java
+ src/share/classes/sun/text/resources/ja/FormatData_ja.java
+ src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java
+ src/share/classes/sun/text/resources/ko/CollationData_ko.java
+ src/share/classes/sun/text/resources/ko/FormatData_ko.java
+ src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java
+ src/share/classes/sun/text/resources/lt/CollationData_lt.java
+ src/share/classes/sun/text/resources/lt/FormatData_lt.java
+ src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java
+ src/share/classes/sun/text/resources/lv/CollationData_lv.java
+ src/share/classes/sun/text/resources/lv/FormatData_lv.java
+ src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java
+ src/share/classes/sun/text/resources/mk/CollationData_mk.java
+ src/share/classes/sun/text/resources/mk/FormatData_mk.java
+ src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java
+ src/share/classes/sun/text/resources/ms/FormatData_ms.java
+ src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java
+ src/share/classes/sun/text/resources/mt/FormatData_mt.java
+ src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java
+ src/share/classes/sun/text/resources/nl/FormatData_nl.java
+ src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java
+ src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java
+ src/share/classes/sun/text/resources/no/CollationData_no.java
+ src/share/classes/sun/text/resources/no/FormatData_no.java
+ src/share/classes/sun/text/resources/no/FormatData_no_NO.java
+ src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java
+ src/share/classes/sun/text/resources/pl/CollationData_pl.java
+ src/share/classes/sun/text/resources/pl/FormatData_pl.java
+ src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java
+ src/share/classes/sun/text/resources/pt/FormatData_pt.java
+ src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java
+ src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java
+ src/share/classes/sun/text/resources/ro/CollationData_ro.java
+ src/share/classes/sun/text/resources/ro/FormatData_ro.java
+ src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java
+ src/share/classes/sun/text/resources/ru/CollationData_ru.java
+ src/share/classes/sun/text/resources/ru/FormatData_ru.java
+ src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java
+ src/share/classes/sun/text/resources/sk/CollationData_sk.java
+ src/share/classes/sun/text/resources/sk/FormatData_sk.java
+ src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java
+ src/share/classes/sun/text/resources/sl/CollationData_sl.java
+ src/share/classes/sun/text/resources/sl/FormatData_sl.java
+ src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java
+ src/share/classes/sun/text/resources/sq/CollationData_sq.java
+ src/share/classes/sun/text/resources/sq/FormatData_sq.java
+ src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java
+ src/share/classes/sun/text/resources/sr/CollationData_sr.java
+ src/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java
+ src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java
+ src/share/classes/sun/text/resources/sv/CollationData_sv.java
+ src/share/classes/sun/text/resources/sv/FormatData_sv.java
+ src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java
+ src/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java
+ src/share/classes/sun/text/resources/th/BreakIteratorRules_th.java
+ src/share/classes/sun/text/resources/th/CollationData_th.java
+ src/share/classes/sun/text/resources/th/FormatData_th.java
+ src/share/classes/sun/text/resources/th/FormatData_th_TH.java
+ src/share/classes/sun/text/resources/th/thai_dict
- src/share/classes/sun/text/resources/thai_dict
+ src/share/classes/sun/text/resources/tr/CollationData_tr.java
+ src/share/classes/sun/text/resources/tr/FormatData_tr.java
+ src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java
+ src/share/classes/sun/text/resources/uk/CollationData_uk.java
+ src/share/classes/sun/text/resources/uk/FormatData_uk.java
+ src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java
+ src/share/classes/sun/text/resources/vi/CollationData_vi.java
+ src/share/classes/sun/text/resources/vi/FormatData_vi.java
+ src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java
+ src/share/classes/sun/text/resources/zh/CollationData_zh.java
+ src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java
+ src/share/classes/sun/text/resources/zh/CollationData_zh_TW.java
+ src/share/classes/sun/text/resources/zh/FormatData_zh.java
+ src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java
+ src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java
+ src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java
+ src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java
! src/share/classes/sun/util/BuddhistCalendar.java
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
+ src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
+ src/share/classes/sun/util/cldr/resources/21_0_1/LICENSE
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldml.dtd
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldmlSupplemental.dtd
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_DJ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ER.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ET.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_NA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak_GH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am_ET.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_001.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_AE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_BH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_DZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_EG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_IQ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_JO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_KW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_MA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_OM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_QA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_TN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_YE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl_AZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn_AZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be_BY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem_ZM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg_BG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm_ML.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_BD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_CN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br_FR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs_BA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn_ER.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca_ES.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg_UG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr_US.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs_CZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy_GB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da_DK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_AT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_BE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_CH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_DE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje_NE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo_SN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz_BT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_GH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_TG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_CY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_GR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AS.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_CA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt_US.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_HK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_JM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MP.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_SG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_TT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_UM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US_POSIX.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_VI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_419.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_AR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_BO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_DO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_EC.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_ES.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GQ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_HN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_MX.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_NI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_SV.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_US.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_UY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_VE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et_EE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu_ES.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_AF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_IR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff_SN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi_FI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil_PH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo_FO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BJ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_DJ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_FR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GP.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GQ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_KM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_LU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MC.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_ML.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MQ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_NE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_SN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_YT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur_IT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga_IE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd_GB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl_ES.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw_CH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv_GB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_GH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw_US.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he_IL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr_HR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu_HU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy_AM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ia.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id_ID.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig_NG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii_CN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is_IS.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_CH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_IT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja_JP.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka_GE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab_DZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea_CV.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq_ML.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl_KZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl_GL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km_KH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko_KR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh_DE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw_GB.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg_UG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo_LA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt_LT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu_CD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv_LV.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe_MU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg_MG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh_MZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk_MK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_BN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_MY.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt_MT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my_MM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq_NA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb_NO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd_ZW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_NP.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_AW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_BE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_CW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_NL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_SX.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn_NO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus_SD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn_UG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_ET.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab_PK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl_PL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps_AF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_AO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_BR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_GW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_MZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_PT.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_ST.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm_CH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn_BI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_MD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_RO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_MD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_RU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_UA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw_RW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah_RU.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_FI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_NO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh_MZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses_ML.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg_CF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn_MA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng_MA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si_LK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk_SK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl_SI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn_ZW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_DJ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_ET.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_SO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq_AL.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_BA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_ME.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_RS.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_BA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_ME.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_RS.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_SZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy_ER.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_LS.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_FI.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_SE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc_CD.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_LK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_KE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_UG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl_TJ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th_TH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ER.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ET.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig_ER.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to_TO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr_TR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq_NE.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn_MA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk_UA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_IN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_PK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab_AF.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl_UZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn_UZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn_LR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii_LR.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi_VN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun_TZ.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae_CH.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal_ET.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog_UG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav_CM.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo_NG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_CN.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_HK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_MO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_SG.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_HK.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_MO.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_TW.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu_ZA.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/metaZones.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/numberingSystems.xml
+ src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/supplementalData.xml
! src/share/classes/sun/util/locale/LocaleUtils.java
+ src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/AvailableLanguageTags.java
+ src/share/classes/sun/util/locale/provider/BreakDictionary.java
+ src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java
+ src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
+ src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
+ src/share/classes/sun/util/locale/provider/CollationRules.java
+ src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java
+ src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java
+ src/share/classes/sun/util/locale/provider/DateFormatProviderImpl.java
+ src/share/classes/sun/util/locale/provider/DateFormatSymbolsProviderImpl.java
+ src/share/classes/sun/util/locale/provider/DecimalFormatSymbolsProviderImpl.java
+ src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java
+ src/share/classes/sun/util/locale/provider/HostLocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/JRELocaleConstants.java
+ src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template
+ src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java
+ src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/LocaleResources.java
+ src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
+ src/share/classes/sun/util/locale/provider/NumberFormatProviderImpl.java
+ src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java
+ src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
+ src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
! src/share/classes/sun/util/resources/LocaleData.java
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java
+ src/share/classes/sun/util/resources/ar/CalendarData_ar.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties
+ src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties
+ src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties
+ src/share/classes/sun/util/resources/be/CalendarData_be.properties
+ src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties
+ src/share/classes/sun/util/resources/be/LocaleNames_be.properties
+ src/share/classes/sun/util/resources/bg/CalendarData_bg.properties
+ src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties
+ src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties
+ src/share/classes/sun/util/resources/ca/CalendarData_ca.properties
+ src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties
+ src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties
+ src/share/classes/sun/util/resources/cs/CalendarData_cs.properties
+ src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties
+ src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties
+ src/share/classes/sun/util/resources/da/CalendarData_da.properties
+ src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties
+ src/share/classes/sun/util/resources/da/LocaleNames_da.properties
+ src/share/classes/sun/util/resources/de/CalendarData_de.properties
+ src/share/classes/sun/util/resources/de/CurrencyNames_de.properties
+ src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties
+ src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties
+ src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties
+ src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties
+ src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties
+ src/share/classes/sun/util/resources/de/LocaleNames_de.properties
+ src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
+ src/share/classes/sun/util/resources/el/CalendarData_el.properties
+ src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties
+ src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties
+ src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties
+ src/share/classes/sun/util/resources/el/LocaleNames_el.properties
+ src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties
+ src/share/classes/sun/util/resources/en/CalendarData_en.properties
+ src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties
+ src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties
+ src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties
+ src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties
+ src/share/classes/sun/util/resources/en/LocaleNames_en.properties
+ src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties
+ src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties
+ src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties
+ src/share/classes/sun/util/resources/en/TimeZoneNames_en.java
+ src/share/classes/sun/util/resources/en/TimeZoneNames_en_CA.java
+ src/share/classes/sun/util/resources/en/TimeZoneNames_en_GB.java
+ src/share/classes/sun/util/resources/en/TimeZoneNames_en_IE.java
+ src/share/classes/sun/util/resources/es/CalendarData_es.properties
+ src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties
+ src/share/classes/sun/util/resources/es/CalendarData_es_US.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_PE.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties
+ src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties
+ src/share/classes/sun/util/resources/es/LocaleNames_es.properties
+ src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties
+ src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
+ src/share/classes/sun/util/resources/et/CalendarData_et.properties
+ src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties
+ src/share/classes/sun/util/resources/et/LocaleNames_et.properties
+ src/share/classes/sun/util/resources/fi/CalendarData_fi.properties
+ src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties
+ src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties
+ src/share/classes/sun/util/resources/fr/CalendarData_fr.properties
+ src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties
+ src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties
+ src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties
+ src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties
+ src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties
+ src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties
+ src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties
+ src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties
+ src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
+ src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties
+ src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties
+ src/share/classes/sun/util/resources/hi/CalendarData_hi.properties
+ src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties
+ src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties
+ src/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java
+ src/share/classes/sun/util/resources/hr/CalendarData_hr.properties
+ src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties
+ src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties
+ src/share/classes/sun/util/resources/hu/CalendarData_hu.properties
+ src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties
+ src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties
+ src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties
+ src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties
+ src/share/classes/sun/util/resources/in/LocaleNames_in.properties
+ src/share/classes/sun/util/resources/is/CalendarData_is.properties
+ src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties
+ src/share/classes/sun/util/resources/is/LocaleNames_is.properties
+ src/share/classes/sun/util/resources/it/CalendarData_it.properties
+ src/share/classes/sun/util/resources/it/CurrencyNames_it.properties
+ src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties
+ src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties
+ src/share/classes/sun/util/resources/it/LocaleNames_it.properties
+ src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
+ src/share/classes/sun/util/resources/iw/CalendarData_iw.properties
+ src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties
+ src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties
+ src/share/classes/sun/util/resources/ja/CalendarData_ja.properties
+ src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties
+ src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties
+ src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties
+ src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
+ src/share/classes/sun/util/resources/ko/CalendarData_ko.properties
+ src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties
+ src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties
+ src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties
+ src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
+ src/share/classes/sun/util/resources/lt/CalendarData_lt.properties
+ src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties
+ src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties
+ src/share/classes/sun/util/resources/lv/CalendarData_lv.properties
+ src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties
+ src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties
+ src/share/classes/sun/util/resources/mk/CalendarData_mk.properties
+ src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties
+ src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties
+ src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties
+ src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties
+ src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties
+ src/share/classes/sun/util/resources/mt/CalendarData_mt.properties
+ src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties
+ src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties
+ src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties
+ src/share/classes/sun/util/resources/nl/CalendarData_nl.properties
+ src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties
+ src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties
+ src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties
+ src/share/classes/sun/util/resources/no/CalendarData_no.properties
+ src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties
+ src/share/classes/sun/util/resources/no/LocaleNames_no.properties
+ src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties
+ src/share/classes/sun/util/resources/pl/CalendarData_pl.properties
+ src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties
+ src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties
+ src/share/classes/sun/util/resources/pt/CalendarData_pt.properties
+ src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties
+ src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties
+ src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties
+ src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties
+ src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties
+ src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties
+ src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties
+ src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
+ src/share/classes/sun/util/resources/ro/CalendarData_ro.properties
+ src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties
+ src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties
+ src/share/classes/sun/util/resources/ru/CalendarData_ru.properties
+ src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties
+ src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties
+ src/share/classes/sun/util/resources/sk/CalendarData_sk.properties
+ src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties
+ src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties
+ src/share/classes/sun/util/resources/sl/CalendarData_sl.properties
+ src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties
+ src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties
+ src/share/classes/sun/util/resources/sq/CalendarData_sq.properties
+ src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties
+ src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties
+ src/share/classes/sun/util/resources/sr/CalendarData_sr.properties
+ src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties
+ src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties
+ src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties
+ src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties
+ src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties
+ src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties
+ src/share/classes/sun/util/resources/sv/CalendarData_sv.properties
+ src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties
+ src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties
+ src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties
+ src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
+ src/share/classes/sun/util/resources/th/CalendarData_th.properties
+ src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties
+ src/share/classes/sun/util/resources/th/LocaleNames_th.properties
+ src/share/classes/sun/util/resources/tr/CalendarData_tr.properties
+ src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties
+ src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties
+ src/share/classes/sun/util/resources/uk/CalendarData_uk.properties
+ src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties
+ src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties
+ src/share/classes/sun/util/resources/vi/CalendarData_vi.properties
+ src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties
+ src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties
+ src/share/classes/sun/util/resources/zh/CalendarData_zh.properties
+ src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties
+ src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java
+ src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java
+ src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties
+ src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties
+ src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java
+ src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties
+ src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties
+ src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
+ src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java
+ src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
+ src/solaris/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/solaris/native/java/lang/java_props_macosx.c
+ src/solaris/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
+ src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
+ src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
+ test/java/text/Format/DateFormat/ContextMonthNamesTest.java
+ test/java/text/Format/NumberFormat/MultipleNumberScriptTest.java
+ test/java/util/Calendar/CalendarTypeTest.java
! test/java/util/Locale/Bug6989440.java
+ test/java/util/Locale/ExtensionsTest.java
! test/java/util/Locale/LocaleCategory.sh
+ test/java/util/Locale/LocaleProviders.java
+ test/java/util/Locale/LocaleProviders.sh
! test/java/util/PluggableLocale/BreakIteratorProviderTest.java
+ test/java/util/PluggableLocale/CalendarDataProviderTest.java
+ test/java/util/PluggableLocale/CalendarDataProviderTest.sh
! test/java/util/PluggableLocale/CollatorProviderTest.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/DateFormatProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.java
! test/java/util/PluggableLocale/NumberFormatProviderTest.java
! test/java/util/PluggableLocale/ProviderTest.java
+ test/java/util/PluggableLocale/SupportedLocalesTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PluggableLocale/barprovider.jar
+ test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java
! test/java/util/PluggableLocale/providersrc/Makefile
+ test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider
! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: e7b53fe85540
Author:    dingxmin
Date:      2012-08-23 16:28 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e7b53fe85540

7193463: Improve registering signal handlers in java.lang.Terminator.setup()
Reviewed-by: dholmes, alanb

! src/solaris/classes/java/lang/Terminator.java
! src/windows/classes/java/lang/Terminator.java

Changeset: de5a85353f4d
Author:    alanb
Date:      2012-08-23 13:07 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/de5a85353f4d

7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx]
Reviewed-by: alanb
Contributed-by: Jason T Greene <jason.greene at redhat.com>

! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java

Changeset: faf4528aea4e
Author:    naoto
Date:      2012-08-24 10:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/faf4528aea4e

7193601: Build breakage with the fix to 6336885 (build-infra build)
Reviewed-by: mduigou

! makefiles/CompileJavaClasses.gmk

Changeset: a7cdfd16e36e
Author:    alanb
Date:      2012-08-24 19:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a7cdfd16e36e

7193933: More ProblemList.txt updates (8/2012)
Reviewed-by: darcy, chegar

! test/ProblemList.txt

Changeset: bd91a601265c
Author:    khazra
Date:      2012-08-24 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bd91a601265c

7168172: (fs) Files.isReadable slow on Windows
Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com
Reviewed-by: alanb

! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java

Changeset: d52081a08d11
Author:    mchung
Date:      2012-08-24 22:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d52081a08d11

7193339: Prepare system classes be defined by a non-null module loader
Reviewed-by: alanb, dholmes, dsamersoff, sspitsyn, psandoz

! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java
! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/management/ManagementFactory.java
! src/share/classes/java/lang/management/PlatformComponent.java
! src/share/classes/java/util/prefs/Preferences.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/sun/management/MappedMXBeanType.java
! src/share/classes/sun/misc/Unsafe.java
! src/share/classes/sun/misc/VM.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java

Changeset: 61ddc8ce7f3b
Author:    weijun
Date:      2012-08-27 10:23 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/61ddc8ce7f3b

7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
+ test/sun/security/krb5/auto/FileKeyTab.java

Changeset: 96990c9da294
Author:    lana
Date:      2012-08-27 10:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/96990c9da294

Merge

- src/share/classes/java/lang/invoke/AdapterMethodHandle.java
- src/share/classes/java/lang/invoke/CountingMethodHandle.java
! src/share/classes/sun/misc/Unsafe.java
! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: fe496675b5e7
Author:    weijun
Date:      2012-08-28 17:25 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fe496675b5e7

7194472: FileKeyTab.java test fails on Windows
Reviewed-by: alanb

! test/sun/security/krb5/auto/FileKeyTab.java

Changeset: 06d0478023ca
Author:    jjg
Date:      2012-08-28 10:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/06d0478023ca

7194032: update tests for upcoming changes for jtreg
Reviewed-by: alanb, iris

! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh
! test/java/rmi/registry/readTest/readTest.sh

Changeset: 997e0d6238b7
Author:    jjg
Date:      2012-08-28 10:31 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/997e0d6238b7

7194035: update tests for upcoming changes for jtreg
Reviewed-by: alanb, sspitsyn

! test/sun/tools/common/ApplicationSetup.sh
! test/sun/tools/jps/jps-Vvml_2.sh
! test/sun/tools/jps/jps-m_2.sh

Changeset: c5099c988cce
Author:    alanb
Date:      2012-08-28 11:12 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c5099c988cce

6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system
Reviewed-by: dholmes, alanb
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/ProblemList.txt
! test/java/io/File/MaxPathLength.java

Changeset: 8b90182f2b33
Author:    mullan
Date:      2012-08-28 08:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8b90182f2b33

7192896: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed
Reviewed-by: xuelei

! src/share/classes/sun/security/provider/certpath/OCSP.java

Changeset: ca7f914b5fea
Author:    mullan
Date:      2012-08-28 08:46 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ca7f914b5fea

Merge


Changeset: bfd5ecb1b4aa
Author:    dcubed
Date:      2012-08-28 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bfd5ecb1b4aa

7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 2bb076d17162
Author:    lana
Date:      2012-08-28 12:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2bb076d17162

Merge

! make/common/Program.gmk
- src/share/classes/java/lang/annotation/ContainerAnnotation.java
- src/share/classes/java/text/BreakDictionary.java
- src/share/classes/java/text/CollationRules.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
- src/share/classes/sun/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
- src/share/classes/sun/text/resources/thai_dict
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java

Changeset: d75666f36cfe
Author:    lana
Date:      2012-08-30 20:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d75666f36cfe

Merge

- src/share/classes/java/lang/annotation/ContainerAnnotation.java
- src/share/classes/java/text/BreakDictionary.java
- src/share/classes/java/text/CollationRules.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
- src/share/classes/sun/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
- src/share/classes/sun/text/resources/thai_dict
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: 1f37a6b26a6b
Author:    malenkov
Date:      2012-06-15 21:01 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1f37a6b26a6b

7162473: ConstructorFinder/FieldFinder/MethodFinder gives access to restricted classes
Reviewed-by: art, ahgross

! src/share/classes/com/sun/beans/finder/ConstructorFinder.java
! src/share/classes/com/sun/beans/finder/FieldFinder.java
! src/share/classes/com/sun/beans/finder/MethodFinder.java

Changeset: 35f97cef5c26
Author:    malenkov
Date:      2012-06-19 20:34 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/35f97cef5c26

7162476: XMLDecoder security issue via ClassFinder
Reviewed-by: art, ahgross

! make/sun/Makefile
- make/sun/beans/Makefile
+ src/share/classes/com/sun/beans/editors/BooleanEditor.java
+ src/share/classes/com/sun/beans/editors/ByteEditor.java
+ src/share/classes/com/sun/beans/editors/ColorEditor.java
+ src/share/classes/com/sun/beans/editors/DoubleEditor.java
+ src/share/classes/com/sun/beans/editors/EnumEditor.java
+ src/share/classes/com/sun/beans/editors/FloatEditor.java
+ src/share/classes/com/sun/beans/editors/FontEditor.java
+ src/share/classes/com/sun/beans/editors/IntegerEditor.java
+ src/share/classes/com/sun/beans/editors/LongEditor.java
+ src/share/classes/com/sun/beans/editors/NumberEditor.java
+ src/share/classes/com/sun/beans/editors/ShortEditor.java
+ src/share/classes/com/sun/beans/editors/StringEditor.java
! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java
! src/share/classes/com/sun/beans/finder/ClassFinder.java
! src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java
+ src/share/classes/com/sun/beans/infos/ComponentBeanInfo.java
- 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
! test/java/beans/Introspector/4520754/Test4520754.java
! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java
! test/java/beans/PropertyEditor/Test6963811.java

Changeset: bc84e7d15615
Author:    malenkov
Date:      2012-07-31 21:01 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc84e7d15615

7183701: [TEST] closed/java/beans/security/TestClassFinder.java - compilation failed
Reviewed-by: rupashka

! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java
! test/java/beans/PropertyEditor/Test6963811.java

Changeset: 82351952278f
Author:    bagiras
Date:      2012-08-30 13:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/82351952278f

7163201: Simplify toolkit internals references
Reviewed-by: art, anthony, ahgross

! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/CheckboxMenuItem.java
! src/share/classes/java/awt/Cursor.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/Menu.java
! src/share/classes/java/awt/MenuBar.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/MenuItem.java
! src/share/classes/java/awt/SystemTray.java
! src/share/classes/java/awt/TrayIcon.java
! src/share/classes/java/awt/event/KeyEvent.java
! src/share/classes/javax/swing/ClientPropertyKey.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/SunToolkit.java
! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java
! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XScrollPanePeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XlibWrapper.java
! src/windows/classes/sun/awt/windows/WCanvasPeer.java
! src/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java
! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: bc21b21d8387
Author:    bagiras
Date:      2012-07-23 15:51 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc21b21d8387

7180036: Build failure in Mac platform caused by fix # 7163201
Reviewed-by: art, kizune, ahgross

! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java

Changeset: 32ac225d85f1
Author:    bagiras
Date:      2012-07-25 19:46 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/32ac225d85f1

7185678: java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java failed with NPE
Reviewed-by: art, ahgross

! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java

Changeset: b195c7431fbc
Author:    lana
Date:      2012-08-30 20:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b195c7431fbc

Merge

! make/sun/Makefile
- make/sun/beans/Makefile
! src/share/classes/java/awt/EventQueue.java
- 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/solaris/classes/sun/awt/X11/XTextTransferHelper.java

Changeset: e946d8fcbd70
Author:    malenkov
Date:      2012-08-31 09:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e946d8fcbd70

7194567: Improve long term persistence of java.beans objects
Reviewed-by: ahgross, art

! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java

Changeset: 0c20f5dbede9
Author:    lana
Date:      2012-08-31 12:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0c20f5dbede9

Merge


Changeset: 6f41c7242a2e
Author:    jcoomes
Date:      2012-08-31 16:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6f41c7242a2e

Merge

- test/java/lang/invoke/MaxTest.java

Changeset: 1f3f4b333341
Author:    jcoomes
Date:      2012-09-05 12:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1f3f4b333341

Merge

- make/sun/beans/Makefile
- src/share/classes/java/lang/annotation/ContainerAnnotation.java
- src/share/classes/java/text/BreakDictionary.java
- src/share/classes/java/text/CollationRules.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
- 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/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
- src/share/classes/sun/text/resources/thai_dict
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: 1fb204840512
Author:    katleman
Date:      2012-09-06 17:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1fb204840512

Added tag jdk8-b55 for changeset 1f3f4b333341

! .hgtags



From john.coomes at oracle.com  Fri Sep  7 10:29:57 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Sep 2012 10:29:57 +0000
Subject: hg: hsx/hotspot-gc/langtools: 9 new changesets
Message-ID: <20120907103020.D41D14797D@hg.openjdk.java.net>

Changeset: c47742f53f99
Author:    katleman
Date:      2012-08-30 10:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c47742f53f99

Added tag jdk8-b54 for changeset 9cf72631baf5

! .hgtags

Changeset: 9d47f4850714
Author:    jjh
Date:      2012-08-15 13:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9d47f4850714

7191449: update copyright year to match last edit in jdk8 langtools repository
Reviewed-by: jjh
Contributed-by: steve.sides at oracle.com

! make/jprt.properties
! make/tools/anttasks/CompilePropertiesTask.java
! make/tools/anttasks/GenStubsTask.java
! make/tools/anttasks/SelectToolTask.java
! make/tools/compileproperties/CompileProperties.java
! make/tools/genstubs/GenStubs.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/AttrContext.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh
! test/tools/javac/api/7086261/T7086261.java
! test/tools/javac/api/T6397104.java
! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/RunExamples.java
! test/tools/javac/diags/examples/ApplicableMethodFound1.java
! test/tools/javac/diags/examples/IllegalDot.java
! test/tools/javac/diags/examples/InconvertibleTypes.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/NotApplicableMethodFound.java
! test/tools/javac/diags/examples/PossibleLossPrecision.java
! test/tools/javac/diags/examples/ResourceNotApplicableToType.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/WhereIntersection.java
! test/tools/javac/diags/examples/WhereTypeVar.java
! test/tools/javac/generics/typevars/T7148242.java
! test/tools/javac/newlines/Newlines.sh
! test/tools/javac/parser/T4881269.java
! test/tools/javac/processing/TestWarnErrorCount.java

Changeset: 5ac2e9ee969e
Author:    jjg
Date:      2012-08-17 17:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5ac2e9ee969e

7192449: fix up tests to accommodate jtreg spec change
Reviewed-by: darcy

! test/tools/javac/processing/6414633/T6414633.java
! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java

Changeset: 464f52f59f7d
Author:    sundar
Date:      2012-08-20 21:24 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/464f52f59f7d

7181320: javac NullPointerException for switch labels with cast to String expressions
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/StringsInSwitch/7181320/BinOpInCaseLabel.java
+ test/tools/javac/StringsInSwitch/7181320/CastInCaseLabel.java
+ test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel.java
+ test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel1.java
+ test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel2.java

Changeset: 37008b4cd97a
Author:    jjg
Date:      2012-08-20 13:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/37008b4cd97a

7192744: fix up tests to accommodate jtreg spec change
Reviewed-by: darcy

! test/tools/javac/processing/6348499/T6348499.java
! test/tools/javac/processing/T6920317.java

Changeset: c9749226cdde
Author:    ksrini
Date:      2012-08-27 07:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c9749226cdde

7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes.
Reviewed-by: jjg
Contributed-by: jan.lahoda at oracle.com

! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

Changeset: 542c87b8ce7f
Author:    lana
Date:      2012-08-27 10:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/542c87b8ce7f

Merge


Changeset: e48e7e1f026b
Author:    lana
Date:      2012-08-30 20:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e48e7e1f026b

Merge


Changeset: 0f8cf3d89a7c
Author:    katleman
Date:      2012-09-06 17:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0f8cf3d89a7c

Added tag jdk8-b55 for changeset e48e7e1f026b

! .hgtags



From dmytro_sheyko at hotmail.com  Fri Sep  7 15:17:23 2012
From: dmytro_sheyko at hotmail.com (Dmytro Sheyko)
Date: Fri, 7 Sep 2012 18:17:23 +0300
Subject: Parallel GC thread priority
Message-ID: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>


Hi,

I can see that Parallel GC works on threads with NormPriority, while CMS and G1 threads run with NearMaxPriority. This probably not an issue if java application works alone, but some time ago I observed GC log like this (it was Jenkins CI on Windows):

[Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen: 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen: 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41, real=30.26 secs]

Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time was 30.26 sec! It seems to me that the system was busy that time and GC threads was starving.

If we could raise priority of Parallel GC threads, other application would have less impact on GC duration.

What do you think?

Thanks,
Dmytro 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/414966de/attachment.htm>

From azeem.jiva at oracle.com  Fri Sep  7 15:20:57 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Fri, 07 Sep 2012 10:20:57 -0500
Subject: Parallel GC thread priority
In-Reply-To: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
Message-ID: <504A10D9.9090407@oracle.com>

The Parallel collector is a stop-the-world collector.  The Java threads 
are suspended until the GC finishes.  I think your survivor spaces maybe 
mis-configured, and that's why you're seeing such large GC times.


On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
> Hi,
>
> I can see that Parallel GC works on threads with NormPriority, while 
> CMS and G1 threads run with NearMaxPriority. This probably not an 
> issue if java application works alone, but some time ago I observed GC 
> log like this (it was Jenkins CI on Windows):
>
> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen: 
> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen: 
> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41, 
> real=30.26 secs]
>
> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real 
> time was 30.26 sec! It seems to me that the system was busy that time 
> and GC threads was starving.
>
> If we could raise priority of Parallel GC threads, other application 
> would have less impact on GC duration.
>
> What do you think?
>
> Thanks,
> Dmytro

-- 
Azeem Jiva
@javawithjiva

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/de1dc20a/attachment.htm>

From vitalyd at gmail.com  Fri Sep  7 15:35:02 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Sep 2012 11:35:02 -0400
Subject: Parallel GC thread priority
In-Reply-To: <504A10D9.9090407@oracle.com>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
	<504A10D9.9090407@oracle.com>
Message-ID: <CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>

You can have other threads from different processes in the system competing
though.

However, such a large wall time vs CPU time can also be caused by heavy
swapping on a slow disk.  The heap there doesn't look all that big though
...

Sent from my phone
On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:

>  The Parallel collector is a stop-the-world collector.  The Java threads
> are suspended until the GC finishes.  I think your survivor spaces maybe
> mis-configured, and that's why you're seeing such large GC times.
>
>
> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>
>  Hi,
>
> I can see that Parallel GC works on threads with NormPriority, while CMS
> and G1 threads run with NearMaxPriority. This probably not an issue if java
> application works alone, but some time ago I observed GC log like this (it
> was Jenkins CI on Windows):
>
> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
> real=30.26 secs]
>
> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
> was 30.26 sec! It seems to me that the system was busy that time and GC
> threads was starving.
>
> If we could raise priority of Parallel GC threads, other application would
> have less impact on GC duration.
>
> What do you think?
>
> Thanks,
> Dmytro
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/4c7a08cc/attachment.htm>

From azeem.jiva at oracle.com  Fri Sep  7 15:39:51 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Fri, 07 Sep 2012 10:39:51 -0500
Subject: Parallel GC thread priority
In-Reply-To: <CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
	<504A10D9.9090407@oracle.com>
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>
Message-ID: <504A1547.9080907@oracle.com>

I had not thought about other processes, which is a possibility. 
Although raising the priority of the GC threads won't help which I 
believe what Dmytro was suggestion.


On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>
> You can have other threads from different processes in the system 
> competing though.
>
> However, such a large wall time vs CPU time can also be caused by 
> heavy swapping on a slow disk.  The heap there doesn't look all that 
> big though ...
>
> Sent from my phone
>
> On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com 
> <mailto:azeem.jiva at oracle.com>> wrote:
>
>     The Parallel collector is a stop-the-world collector.  The Java
>     threads are suspended until the GC finishes.  I think your
>     survivor spaces maybe mis-configured, and that's why you're seeing
>     such large GC times.
>
>
>     On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>>     Hi,
>>
>>     I can see that Parallel GC works on threads with NormPriority,
>>     while CMS and G1 threads run with NearMaxPriority. This probably
>>     not an issue if java application works alone, but some time ago I
>>     observed GC log like this (it was Jenkins CI on Windows):
>>
>>     [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
>>     403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
>>     76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77
>>     sys=0.41, real=30.26 secs]
>>
>>     Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the
>>     real time was 30.26 sec! It seems to me that the system was busy
>>     that time and GC threads was starving.
>>
>>     If we could raise priority of Parallel GC threads, other
>>     application would have less impact on GC duration.
>>
>>     What do you think?
>>
>>     Thanks,
>>     Dmytro
>
>     -- 
>     Azeem Jiva
>     @javawithjiva
>

-- 
Azeem Jiva
@javawithjiva

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/612deceb/attachment.htm>

From vitalyd at gmail.com  Fri Sep  7 15:45:34 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Sep 2012 11:45:34 -0400
Subject: Parallel GC thread priority
In-Reply-To: <504A1547.9080907@oracle.com>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
	<504A10D9.9090407@oracle.com>
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>
	<504A1547.9080907@oracle.com>
Message-ID: <CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>

Whether it helps or not would depend on what priority the other threads are
running at.  If the server had several jvms running at the same time and
they all start a par new collection at about the same time, then yeah it
won't help if priority is boosted - at that point, the machine is simply
oversubscribed.

In Dmytro's case, the wall time is so out of whack with CPU time that I
wonder if it wasn't swapping that mostly contributed to this.  For such a
relatively small heap, I can't imagine how much other stuff would have to
run to inflate the time so much.

Dmytro, what hardware spec was this on, out of curiosity?

Sent from my phone
On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:

>  I had not thought about other processes, which is a possibility.
> Although raising the priority of the GC threads won't help which I believe
> what Dmytro was suggestion.
>
>
> On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>
> You can have other threads from different processes in the system
> competing though.
>
> However, such a large wall time vs CPU time can also be caused by heavy
> swapping on a slow disk.  The heap there doesn't look all that big though
> ...
>
> Sent from my phone
> On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>>  The Parallel collector is a stop-the-world collector.  The Java threads
>> are suspended until the GC finishes.  I think your survivor spaces maybe
>> mis-configured, and that's why you're seeing such large GC times.
>>
>>
>> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>>
>>  Hi,
>>
>> I can see that Parallel GC works on threads with NormPriority, while CMS
>> and G1 threads run with NearMaxPriority. This probably not an issue if java
>> application works alone, but some time ago I observed GC log like this (it
>> was Jenkins CI on Windows):
>>
>> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
>> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
>> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
>> real=30.26 secs]
>>
>> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
>> was 30.26 sec! It seems to me that the system was busy that time and GC
>> threads was starving.
>>
>> If we could raise priority of Parallel GC threads, other application
>> would have less impact on GC duration.
>>
>> What do you think?
>>
>> Thanks,
>> Dmytro
>>
>>
>> --
>> Azeem Jiva
>> @javawithjiva
>>
>>
> --
> Azeem Jiva
> @javawithjiva
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/9355549a/attachment.htm>

From dmytro_sheyko at hotmail.com  Fri Sep  7 16:31:27 2012
From: dmytro_sheyko at hotmail.com (Dmytro Sheyko)
Date: Fri, 7 Sep 2012 19:31:27 +0300
Subject: Parallel GC thread priority
In-Reply-To: <CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>,
	<504A10D9.9090407@oracle.com>,
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>,
	<504A1547.9080907@oracle.com>,
	<CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>
Message-ID: <SNT137-W46B2B2F303D227CE5FCBA8AAF0@phx.gbl>


Hi,

I can provide following info only:
===
System:
 Microsoft Windows Server 2003 R2
 Standard x64 Edition
 Service Pack 2
Computer:
 Intel(R) Xeon(R) CPU E5-2640
 2.50 GHz, 12.0 GB of RAM
===
JConsole output:

Operating System:       Windows 2003 5.2 
Architecture:           amd64 
Number of processors:   4 

Total physical memory:  12,582,100 kbytes 
Free physical memory:    6,184,012 kbytes 
Total swap space:       14,137,188 kbytes 
Free swap space:        11,189,520 kbytes 
===
But at time that this long GC pause happened it was 8 GB of RAM. And I don't know how much memory was used at that time.

Please note that it's continuous integration server. Some build tasks are executed on the same machine. The pause happened on web server, which serves UI.

BTW, isn't swapping counted as sys/kernel time?

Thanks,
Dmytro


Date: Fri, 7 Sep 2012 11:45:34 -0400
Subject: Re: Parallel GC thread priority
From: vitalyd at gmail.com
To: azeem.jiva at oracle.com
CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net

Whether it helps or not would depend on what priority the other threads are running at.  If the server had several jvms running at the same time and they all start a par new collection at about the same time, then yeah it won't help if priority is boosted - at that point, the machine is simply oversubscribed.

In Dmytro's case, the wall time is so out of whack with CPU time that I wonder if it wasn't swapping that mostly contributed to this.  For such a relatively small heap, I can't imagine how much other stuff would have to run to inflate the time so much.

Dmytro, what hardware spec was this on, out of curiosity? 
Sent from my phone
On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:


  
    
  
  
    I had not thought about other processes, which is a possibility. 
    Although raising the priority of the GC threads won't help which I
    believe what Dmytro was suggestion.

    

    

    On 09/07/2012 10:35 AM, Vitaly
      Davidovich wrote:

    
    
      You can have other threads from different processes in the
        system competing though.
      However, such a large wall time vs CPU time can also be caused
        by heavy swapping on a slow disk.  The heap there doesn't look
        all that big though ...
      Sent from my phone
      On Sep 7, 2012 11:21 AM, "Azeem Jiva"
        <azeem.jiva at oracle.com>
        wrote:

        
           The Parallel collector
            is a stop-the-world collector.  The Java threads are
            suspended until the GC finishes.  I think your survivor
            spaces maybe mis-configured, and that's why you're seeing
            such large GC times. 

            

             

            On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:

            
            
               Hi,

                

                I can see that Parallel GC works on threads with
                NormPriority, while CMS and G1 threads run with
                NearMaxPriority. This probably not an issue if java
                application works alone, but some time ago I observed GC
                log like this (it was Jenkins CI on Windows):

                

                [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
                403417K->114637K(415872K)]
                413769K->114637K(587776K) [PSPermGen:
                76315K->76315K(83968K)], 30.2595731 secs] [Times:
                user=0.77 sys=0.41, real=30.26 secs]

                

                Despite cpu time for GC was just 1.18 sec (= 0.77 +
                0.41), the real time was 30.26 sec! It seems to me that
                the system was busy that time and GC threads was
                starving.

                

                If we could raise priority of Parallel GC threads, other
                application would have less impact on GC duration.

                

                What do you think?

                

                Thanks,

                Dmytro 
            
            

            -- 
Azeem Jiva
@javawithjiva
          
        
      
    
    

    -- 
Azeem Jiva
@javawithjiva
  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/4b0e7b2a/attachment.htm>

From vitalyd at gmail.com  Fri Sep  7 16:53:55 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 7 Sep 2012 12:53:55 -0400
Subject: Parallel GC thread priority
In-Reply-To: <SNT137-W46B2B2F303D227CE5FCBA8AAF0@phx.gbl>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
	<504A10D9.9090407@oracle.com>
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>
	<504A1547.9080907@oracle.com>
	<CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>
	<SNT137-W46B2B2F303D227CE5FCBA8AAF0@phx.gbl>
Message-ID: <CAHjP37Ft669Aya-mTt2t1jpi8t3y8fP6AdRpjuebB44M9S0dBA@mail.gmail.com>

I see you're on windows, but on Linux I'm almost certain that time spent
waiting for i/o does not count in sys time (it's purely CPU time).  I
suspect, though, that windows does similar accounting but I'm not sure.

Sent from my phone
On Sep 7, 2012 12:31 PM, "Dmytro Sheyko" <dmytro_sheyko at hotmail.com> wrote:

>  Hi,
>
> I can provide following info only:
> ===
> System:
>  Microsoft Windows Server 2003 R2
>  Standard x64 Edition
>  Service Pack 2
> Computer:
>  Intel(R) Xeon(R) CPU E5-2640
>  2.50 GHz, 12.0 GB of RAM
> ===
> JConsole output:
>
> Operating System:       Windows 2003 5.2
> Architecture:           amd64
> Number of processors:   4
>
> Total physical memory:  12,582,100 kbytes
> Free physical memory:    6,184,012 kbytes
> Total swap space:       14,137,188 kbytes
> Free swap space:        11,189,520 kbytes
> ===
> But at time that this long GC pause happened it was 8 GB of RAM. And I
> don't know how much memory was used at that time.
>
> Please note that it's continuous integration server. Some build tasks are
> executed on the same machine. The pause happened on web server, which
> serves UI.
>
> BTW, isn't swapping counted as sys/kernel time?
>
> Thanks,
> Dmytro
>
>
> ------------------------------
> Date: Fri, 7 Sep 2012 11:45:34 -0400
> Subject: Re: Parallel GC thread priority
> From: vitalyd at gmail.com
> To: azeem.jiva at oracle.com
> CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net
>
> Whether it helps or not would depend on what priority the other threads
> are running at.  If the server had several jvms running at the same time
> and they all start a par new collection at about the same time, then yeah
> it won't help if priority is boosted - at that point, the machine is simply
> oversubscribed.
> In Dmytro's case, the wall time is so out of whack with CPU time that I
> wonder if it wasn't swapping that mostly contributed to this.  For such a
> relatively small heap, I can't imagine how much other stuff would have to
> run to inflate the time so much.
> Dmytro, what hardware spec was this on, out of curiosity?
> Sent from my phone
> On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>  I had not thought about other processes, which is a possibility.
> Although raising the priority of the GC threads won't help which I believe
> what Dmytro was suggestion.
>
>
> On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>
> You can have other threads from different processes in the system
> competing though.
> However, such a large wall time vs CPU time can also be caused by heavy
> swapping on a slow disk.  The heap there doesn't look all that big though
> ...
> Sent from my phone
> On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>  The Parallel collector is a stop-the-world collector.  The Java threads
> are suspended until the GC finishes.  I think your survivor spaces maybe
> mis-configured, and that's why you're seeing such large GC times.
>
>
> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>
>  Hi,
>
> I can see that Parallel GC works on threads with NormPriority, while CMS
> and G1 threads run with NearMaxPriority. This probably not an issue if java
> application works alone, but some time ago I observed GC log like this (it
> was Jenkins CI on Windows):
>
> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
> real=30.26 secs]
>
> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
> was 30.26 sec! It seems to me that the system was busy that time and GC
> threads was starving.
>
> If we could raise priority of Parallel GC threads, other application would
> have less impact on GC duration.
>
> What do you think?
>
> Thanks,
> Dmytro
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/78ac7c9e/attachment.htm>

From coleen.phillimore at oracle.com  Fri Sep  7 19:12:09 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 07 Sep 2012 19:12:09 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195833: NPG: Rename
	instanceClassLoaderKlass, instanceRefKlass and instanceMirrorKlass
Message-ID: <20120907191214.5250D47995@hg.openjdk.java.net>

Changeset: aed758eda82a
Author:    coleenp
Date:      2012-09-07 12:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aed758eda82a

7195833: NPG: Rename instanceClassLoaderKlass, instanceRefKlass and instanceMirrorKlass
Summary: Simple renaming to be consistent with instanceKlass->InstanceKlass renaming
Reviewed-by: stefank, jmasa

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceClassLoaderKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceRefKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/specialized_oop_closures.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/instanceClassLoaderKlass.cpp
! src/share/vm/oops/instanceClassLoaderKlass.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.cpp
! src/share/vm/oops/instanceMirrorKlass.hpp
! src/share/vm/oops/instanceRefKlass.cpp
! src/share/vm/oops/instanceRefKlass.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/opto/type.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/runtime/vmStructs.cpp



From coleen.phillimore at oracle.com  Sat Sep  8 00:05:03 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Sat, 08 Sep 2012 00:05:03 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7196103: NPG: Unable to allocate bit map
	for parallel garbage collection for the requested heap size
Message-ID: <20120908000508.677ED479A3@hg.openjdk.java.net>

Changeset: 11fb740ce98f
Author:    coleenp
Date:      2012-09-07 16:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/11fb740ce98f

7196103: NPG: Unable to allocate bit map for parallel garbage collection for the requested heap size
Summary: Don't allocate huge class metaspace size by default on x64
Reviewed-by: stefank, jmasa, kvn

! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp



From ysr1729 at gmail.com  Mon Sep 10 16:22:51 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Mon, 10 Sep 2012 17:22:51 +0100
Subject: Parallel GC thread priority
In-Reply-To: <CAHjP37Ft669Aya-mTt2t1jpi8t3y8fP6AdRpjuebB44M9S0dBA@mail.gmail.com>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
	<504A10D9.9090407@oracle.com>
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>
	<504A1547.9080907@oracle.com>
	<CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>
	<SNT137-W46B2B2F303D227CE5FCBA8AAF0@phx.gbl>
	<CAHjP37Ft669Aya-mTt2t1jpi8t3y8fP6AdRpjuebB44M9S0dBA@mail.gmail.com>
Message-ID: <CABzyjy=7e4v-Gb+Y=Sk9+TTMRaE3vONuv4isK7t_5y8KXO=T5A@mail.gmail.com>

I agree that eliminating paging as a suspect is a good idea. Although the
stats that Dmytro provided below seems to show plenty of free RAM, perhaps
that info was collected at a different time than when the long pause was
observed?

Like Vitaly, I am suspicious of paging in such extreme cases.

What's the version of JVM you are running? (In such cases running with
-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps would have been great as it
just might have provided a couple more clues -- or not.)
(There were some older versions of the JVM where there were issues with
thread suspension that would cause long pauses, but i believe the GC log
symptom of that was somewhat different.)

By the way, since this is a 4 core system, you should be running
-XX:+UseParallelOldGC.

Note, for that reason, that "parallel gc thread" priority is moot for this
case, it's really "(serial) GC thread", since there's a single GC thread
running your full collection below. (Although your minor collections are
indeed run multi-threaded.)

-- ramki

On Fri, Sep 7, 2012 at 5:53 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> I see you're on windows, but on Linux I'm almost certain that time spent
> waiting for i/o does not count in sys time (it's purely CPU time).  I
> suspect, though, that windows does similar accounting but I'm not sure.
>
> Sent from my phone
> On Sep 7, 2012 12:31 PM, "Dmytro Sheyko" <dmytro_sheyko at hotmail.com>
> wrote:
>
>>  Hi,
>>
>> I can provide following info only:
>> ===
>> System:
>>  Microsoft Windows Server 2003 R2
>>  Standard x64 Edition
>>  Service Pack 2
>> Computer:
>>  Intel(R) Xeon(R) CPU E5-2640
>>  2.50 GHz, 12.0 GB of RAM
>> ===
>> JConsole output:
>>
>> Operating System:       Windows 2003 5.2
>> Architecture:           amd64
>> Number of processors:   4
>>
>> Total physical memory:  12,582,100 kbytes
>> Free physical memory:    6,184,012 kbytes
>> Total swap space:       14,137,188 kbytes
>> Free swap space:        11,189,520 kbytes
>> ===
>> But at time that this long GC pause happened it was 8 GB of RAM. And I
>> don't know how much memory was used at that time.
>>
>> Please note that it's continuous integration server. Some build tasks are
>> executed on the same machine. The pause happened on web server, which
>> serves UI.
>>
>> BTW, isn't swapping counted as sys/kernel time?
>>
>> Thanks,
>> Dmytro
>>
>>
>> ------------------------------
>> Date: Fri, 7 Sep 2012 11:45:34 -0400
>> Subject: Re: Parallel GC thread priority
>> From: vitalyd at gmail.com
>> To: azeem.jiva at oracle.com
>> CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net
>>
>> Whether it helps or not would depend on what priority the other threads
>> are running at.  If the server had several jvms running at the same time
>> and they all start a par new collection at about the same time, then yeah
>> it won't help if priority is boosted - at that point, the machine is simply
>> oversubscribed.
>> In Dmytro's case, the wall time is so out of whack with CPU time that I
>> wonder if it wasn't swapping that mostly contributed to this.  For such a
>> relatively small heap, I can't imagine how much other stuff would have to
>> run to inflate the time so much.
>> Dmytro, what hardware spec was this on, out of curiosity?
>> Sent from my phone
>> On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>>
>>  I had not thought about other processes, which is a possibility.
>> Although raising the priority of the GC threads won't help which I believe
>> what Dmytro was suggestion.
>>
>>
>> On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>>
>> You can have other threads from different processes in the system
>> competing though.
>> However, such a large wall time vs CPU time can also be caused by heavy
>> swapping on a slow disk.  The heap there doesn't look all that big though
>> ...
>> Sent from my phone
>> On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>>
>>  The Parallel collector is a stop-the-world collector.  The Java threads
>> are suspended until the GC finishes.  I think your survivor spaces maybe
>> mis-configured, and that's why you're seeing such large GC times.
>>
>>
>> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>>
>>  Hi,
>>
>> I can see that Parallel GC works on threads with NormPriority, while CMS
>> and G1 threads run with NearMaxPriority. This probably not an issue if java
>> application works alone, but some time ago I observed GC log like this (it
>> was Jenkins CI on Windows):
>>
>> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
>> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
>> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
>> real=30.26 secs]
>>
>> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
>> was 30.26 sec! It seems to me that the system was busy that time and GC
>> threads was starving.
>>
>> If we could raise priority of Parallel GC threads, other application
>> would have less impact on GC duration.
>>
>> What do you think?
>>
>> Thanks,
>> Dmytro
>>
>>
>> --
>> Azeem Jiva
>> @javawithjiva
>>
>>
>> --
>> Azeem Jiva
>> @javawithjiva
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120910/c8cf9031/attachment.htm>

From christian.thalinger at oracle.com  Tue Sep 11 02:29:44 2012
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Tue, 11 Sep 2012 02:29:44 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7196242:
	vm/mlvm/indy/stress/java/loopsAndThreads crashed
Message-ID: <20120911022946.BF76F479EA@hg.openjdk.java.net>

Changeset: 4bfe8b33cf66
Author:    twisti
Date:      2012-09-10 16:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4bfe8b33cf66

7196242: vm/mlvm/indy/stress/java/loopsAndThreads crashed
Reviewed-by: jrose, coleenp, jmasa, kvn

! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp



From dmytro_sheyko at hotmail.com  Tue Sep 11 09:52:27 2012
From: dmytro_sheyko at hotmail.com (Dmytro Sheyko)
Date: Tue, 11 Sep 2012 12:52:27 +0300
Subject: Parallel GC thread priority
In-Reply-To: <CABzyjy=7e4v-Gb+Y=Sk9+TTMRaE3vONuv4isK7t_5y8KXO=T5A@mail.gmail.com>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>,
	<504A10D9.9090407@oracle.com>,
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>,
	<504A1547.9080907@oracle.com>,
	<CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>,
	<SNT137-W46B2B2F303D227CE5FCBA8AAF0@phx.gbl>,
	<CAHjP37Ft669Aya-mTt2t1jpi8t3y8fP6AdRpjuebB44M9S0dBA@mail.gmail.com>,
	<CABzyjy=7e4v-Gb+Y=Sk9+TTMRaE3vONuv4isK7t_5y8KXO=T5A@mail.gmail.com>
Message-ID: <SNT137-W62A8E92152F43B132E1BF58A930@phx.gbl>


Hi,

Here is a bit more details:

{Heap before GC invocations=1468 (full 6):
PSYoungGen      total 171904K, used 10352K [0x00000000eaab0000, 0x00000000f6940000, 0x0000000100000000)
  eden space 161536K, 0% used [0x00000000eaab0000,0x00000000eaab0000,0x00000000f4870000)
  from space 10368K, 99% used [0x00000000f5f20000,0x00000000f693c060,0x00000000f6940000)
  to   space 16640K, 0% used [0x00000000f48c0000,0x00000000f48c0000,0x00000000f5900000)
PSOldGen        total 408640K, used 403417K [0x00000000c0000000, 0x00000000d8f10000, 0x00000000eaab0000)
  object space 408640K, 98% used [0x00000000c0000000,0x00000000d89f6478,0x00000000d8f10000)
PSPermGen       total 83968K, used 76315K [0x00000000bae00000, 0x00000000c0000000, 0x00000000c0000000)
  object space 83968K, 90% used [0x00000000bae00000,0x00000000bf886db0,0x00000000c0000000)
2012-03-05T00:03:06.936-0600: 130338.132: [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen: 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen: 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41, real=30.26 secs]
Heap after GC invocations=1468 (full 6):
PSYoungGen      total 171904K, used 0K [0x00000000eaab0000, 0x00000000f6940000, 0x0000000100000000)
  eden space 161536K, 0% used [0x00000000eaab0000,0x00000000eaab0000,0x00000000f4870000)
  from space 10368K, 0% used [0x00000000f5f20000,0x00000000f5f20000,0x00000000f6940000)
  to   space 16640K, 0% used [0x00000000f48c0000,0x00000000f48c0000,0x00000000f5900000)
PSOldGen        total 415872K, used 114637K [0x00000000c0000000, 0x00000000d9620000, 0x00000000eaab0000)
  object space 415872K, 27% used [0x00000000c0000000,0x00000000c6ff3410,0x00000000d9620000)
PSPermGen       total 83968K, used 76315K [0x00000000bae00000, 0x00000000c0000000, 0x00000000c0000000)
  object space 83968K, 90% used [0x00000000bae00000,0x00000000bf886db0,0x00000000c0000000)
}

JVM is x64 Java 7u2.
JVM options are (printed by -XX:+PrintCommandLineFlags):
-XX:InitialHeapSize=536870912 -XX:MaxHeapSize=1073741824 -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintJNIGCStalls -XX:+ReduceSignalUsage -XX:+UseCompressedOops -XX:+UseLargePagesIndividualAllocation -XX:+UseParallelGC

This happened several months ago and many things were changed since that: we added 4G RAM (8G -> 12G), tried other collectors CMS and G1, tried 32 bit, tried other java 7 updates etc. And currently it works pretty well. I doubt I may experiment with our CI server in order to find the real cause of the long GC pause happened before, however please let me know what options are to be set, that would help us to prove that swapping is guilty of such discrepancy between CPU time and wall time if it happens again. I assume that the issue is not specific to PS and it can be observed with CMS and G1 also.

Well, I almost forgot about such issue, but I noticed recently (analyzing jstack output) that Parallel GC threads work with NORM, while G1 and CMS use MAX priority. This seemed to me suspect.
If it is intentional, what is the reason for this?

Recently I wrote simple test (attached) to find out how other cpu-intensive applications impact on GC pauses.
The test does following:
1. figures out Parallel GC threads and their native ids (using jstack)
2. raises their native priority from NORMAL(0) to HIGH(2) (using JNA) (optional)
3. starts java application (Disturber) that simply spins endless loop in several threads (100, configurable) just to consume cpu time.
4. generates garbage to provoke GC.

Used following options:
-Xmx1024m -Xms256m
-server
-showversion
-XX:+PrintGCDetails
-XX:+UseParallelGC
-XX:+UseParallelOldGC
-Ddisturber.java.priority=5
-Dduration.ms=100000
-Ddisturber.threads=100
-Dgc.native.priority=0


Got following results:

1. The test is run without any disturber threads (-Ddisturber.threads=0). Priority of GC threads does not matter. Typical GC log looks like this:
[GC [PSYoungGen: 312502K->0K(349440K)] 898885K->625445K(1048512K), 0.0858486 secs] [Times: user=0.19 sys=0.00, real=0.09 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 937947K->664508K(1048512K), 0.0855026 secs] [Times: user=0.19 sys=0.00, real=0.09 secs] 
[Full GC [PSYoungGen: 0K->0K(349440K)] [ParOldGen: 664508K->78570K(699072K)] 664508K->78570K(1048512K) [PSPermGen: 3065K->3065K(16384K)], 0.4356773 secs] [Times: user=0.80 sys=0.00, real=0.44 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 391072K->117633K(1048512K), 0.0829569 secs] [Times: user=0.13 sys=0.02, real=0.08 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 430135K->156695K(1048512K), 0.0831900 secs] [Times: user=0.19 sys=0.00, real=0.08 secs] 

2. The test is run with 100 disturber threads (-Ddisturber.threads=100). Priority of GC threads remains NORM(0) (-Dgc.native.priority=0). Typical GC log looks like this:
[GC [PSYoungGen: 312502K->0K(349440K)] 664510K->391070K(814976K), 1.9201232 secs] [Times: user=0.13 sys=0.02, real=1.92 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 703572K->430133K(814976K), 1.9581938 secs] [Times: user=0.16 sys=0.05, real=1.96 secs] 
[Full GC [PSYoungGen: 0K->0K(349440K)] [ParOldGen: 430133K->78570K(490368K)] 430133K->78570K(839808K) [PSPermGen: 3065K->3065K(16384K)], 8.0233189 secs] [Times: user=0.41 sys=0.00, real=8.02 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 391072K->117633K(839808K), 2.1210901 secs] [Times: user=0.13 sys=0.02, real=2.12 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 430135K->156695K(839808K), 2.1864928 secs] [Times: user=0.13 sys=0.02, real=2.19 secs] 

3. The test is run with 100 disturber threads (-Ddisturber.threads=100). Priority of GC threads is raisen to HIGH(2) (-Dgc.native.priority=2). Typical GC log looks like this:
[GC [PSYoungGen: 312502K->0K(349440K)] 898885K->625445K(1048512K), 0.0824847 secs] [Times: user=0.16 sys=0.00, real=0.08 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 937947K->664508K(1048512K), 0.0823295 secs] [Times: user=0.17 sys=0.00, real=0.08 secs] 
[Full GC [PSYoungGen: 0K->0K(349440K)] [ParOldGen: 664508K->78570K(699072K)] 664508K->78570K(1048512K) [PSPermGen: 3065K->3065K(16384K)], 0.5145061 secs] [Times: user=0.65 sys=0.00, real=0.51 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 391072K->117633K(1048512K), 0.0793123 secs] [Times: user=0.16 sys=0.00, real=0.08 secs] 
[GC [PSYoungGen: 312502K->0K(349440K)] 430135K->156695K(1048512K), 0.0809080 secs] [Times: user=0.16 sys=0.00, real=0.08 secs] 

Here I can see that there is a noticeable difference between cpu and wall time of GC pauses in case #2 (when GC threads work with NORM priority and there are cpu intensive applications).

I believe that Parallel GC threads are to be run with HIGH priority (or at least with highest priority of app threads they block), because otherwise there is some sort of priority inversion: GC threads block all application threads even those that run with HIGH priority, however they themself run with NORM priority and can be simply preempted with threads of other app that run with ABOVE_NORM and NORM priority.

Thanks,
Dmytro

Date: Mon, 10 Sep 2012 17:22:51 +0100
Subject: Re: Parallel GC thread priority
From: ysr1729 at gmail.com
To: vitalyd at gmail.com
CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net

I agree that eliminating paging as a suspect is a good idea. Although the stats that Dmytro provided below seems to show plenty of free RAM, perhaps that info was collected at a different time than when the long pause was observed?


Like Vitaly, I am suspicious of paging in such extreme cases.

What's the version of JVM you are running? (In such cases running with -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps would have been great as it just might have provided a couple more clues -- or not.)

(There were some older versions of the JVM where there were issues with thread suspension that would cause long pauses, but i believe the GC log symptom of that was somewhat different.)

By the way, since this is a 4 core system, you should be running -XX:+UseParallelOldGC.


Note, for that reason, that "parallel gc thread" priority is moot for this case, it's really "(serial) GC thread", since there's a single GC thread running your full collection below. (Although your minor collections are indeed run multi-threaded.)


-- ramki

On Fri, Sep 7, 2012 at 5:53 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

I see you're on windows, but on Linux I'm almost certain that time spent waiting for i/o does not count in sys time (it's purely CPU time).  I suspect, though, that windows does similar accounting but I'm not sure.


Sent from my phone
On Sep 7, 2012 12:31 PM, "Dmytro Sheyko" <dmytro_sheyko at hotmail.com> wrote:






Hi,

I can provide following info only:
===
System:
 Microsoft Windows Server 2003 R2
 Standard x64 Edition
 Service Pack 2
Computer:
 Intel(R) Xeon(R) CPU E5-2640
 2.50 GHz, 12.0 GB of RAM


===
JConsole output:

Operating System:       Windows 2003 5.2 
Architecture:           amd64 
Number of processors:   4 

Total physical memory:  12,582,100 kbytes 
Free physical memory:    6,184,012 kbytes 


Total swap space:       14,137,188 kbytes 
Free swap space:        11,189,520 kbytes 
===
But at time that this long GC pause happened it was 8 GB of RAM. And I don't know how much memory was used at that time.



Please note that it's continuous integration server. Some build tasks are executed on the same machine. The pause happened on web server, which serves UI.

BTW, isn't swapping counted as sys/kernel time?



Thanks,
Dmytro


Date: Fri, 7 Sep 2012 11:45:34 -0400
Subject: Re: Parallel GC thread priority
From: vitalyd at gmail.com
To: azeem.jiva at oracle.com


CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net

Whether it helps or not would depend on what priority the other threads are running at.  If the server had several jvms running at the same time and they all start a par new collection at about the same time, then yeah it won't help if priority is boosted - at that point, the machine is simply oversubscribed.




In Dmytro's case, the wall time is so out of whack with CPU time that I wonder if it wasn't swapping that mostly contributed to this.  For such a relatively small heap, I can't imagine how much other stuff would have to run to inflate the time so much.




Dmytro, what hardware spec was this on, out of curiosity? 

Sent from my phone

On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:


  
    
  
  
    I had not thought about other processes, which is a possibility. 
    Although raising the priority of the GC threads won't help which I
    believe what Dmytro was suggestion.

    

    

    On 09/07/2012 10:35 AM, Vitaly
      Davidovich wrote:

    
    
      You can have other threads from different processes in the
        system competing though.

      However, such a large wall time vs CPU time can also be caused
        by heavy swapping on a slow disk.  The heap there doesn't look
        all that big though ...

      Sent from my phone

      On Sep 7, 2012 11:21 AM, "Azeem Jiva"
        <azeem.jiva at oracle.com>
        wrote:

        
           The Parallel collector
            is a stop-the-world collector.  The Java threads are
            suspended until the GC finishes.  I think your survivor
            spaces maybe mis-configured, and that's why you're seeing
            such large GC times. 

            

             

            On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:

            
            
               Hi,

                

                I can see that Parallel GC works on threads with
                NormPriority, while CMS and G1 threads run with
                NearMaxPriority. This probably not an issue if java
                application works alone, but some time ago I observed GC
                log like this (it was Jenkins CI on Windows):

                

                [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
                403417K->114637K(415872K)]
                413769K->114637K(587776K) [PSPermGen:
                76315K->76315K(83968K)], 30.2595731 secs] [Times:
                user=0.77 sys=0.41, real=30.26 secs]

                

                Despite cpu time for GC was just 1.18 sec (= 0.77 +
                0.41), the real time was 30.26 sec! It seems to me that
                the system was busy that time and GC threads was
                starving.

                

                If we could raise priority of Parallel GC threads, other
                application would have less impact on GC duration.

                

                What do you think?

                

                Thanks,

                Dmytro 
            
            

            -- 
Azeem Jiva
@javawithjiva
          
        
      
    
    

    -- 
Azeem Jiva
@javawithjiva
  

 		 	   		  


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120911/1edf9364/attachment.htm>
-------------- next part --------------
package test;

import java.io.IOException;

public class Disturber implements Runnable {
	public static void main(String[] args) throws IOException {
		int n = Integer.getInteger("threads", 100);
		int p = Integer.getInteger("priority", Thread.NORM_PRIORITY);
		Disturber d = new Disturber();
		for (int i = 0; i < n; ++i) {
			Thread t = new Thread(d, "T" + i);
			t.setDaemon(true);
			t.setPriority(p);
			t.start();
		}
		Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
		System.in.read();
	}
	public void run() {
		while (true);
	}
}
-------------- next part --------------
package test;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.lang.ref.SoftReference;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

import com.sun.jna.Native;
import com.sun.jna.Pointer;
import com.sun.jna.win32.StdCallLibrary;

public class Main {
	public interface Kernel32 extends StdCallLibrary {
		Kernel32 INSTANCE = (Kernel32) Native.loadLibrary("kernel32", Kernel32.class);

		int GetCurrentProcessId();
		int GetThreadPriority(Pointer hThread);
		int SetThreadPriority(Pointer hThread, int nPriority);
		Pointer OpenThread(int dwDesiredAccess, int bInheritHandle, int dwThreadId);
		int CloseHandle(Pointer hObject);
	}

	public static void main(String[] args) throws IOException, InterruptedException {
		List<Integer> ids = getGcThreadIds(new ArrayList<Integer>());
		System.out.println(ids);
		setNativeThreadPriority(ids, Integer.getInteger("gc.native.priority", 2));
		Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
		Process disturber = new ProcessBuilder(System.getProperty("java.home") + "/bin/java",
				"-Dthreads=" + System.getProperty("disturber.threads", "100"),
				"-Dpriority=" + System.getProperty("disturber.java.priority", "" + Thread.NORM_PRIORITY),
				"-classpath", System.getProperty("java.class.path"), "test.Disturber").start();
		generateGarbage(Long.getLong("duration.ms", 100_000));
		System.out.println("done");
		disturber.destroy();
	}

	static void generateGarbage(long duration) {
		long deadline = System.currentTimeMillis() + duration;
		SoftReference<Object[]> ref = new SoftReference<Object[]>(null);
		while (System.currentTimeMillis() < deadline) {
			Object[] obj = new Object[10000000];
			Object[] prv = ref.get();
			if (prv == null) {
				ref = new SoftReference<Object[]>(obj);
			} else {
				Arrays.fill(prv, obj);
			}
		}
	}

	static <C extends Collection<Integer>> C getGcThreadIds(C col) throws IOException {
		Pattern pattern = Pattern
				.compile("\\\".*\\(ParallelGC\\)\\\".* nid=(\\w+).*");
		String jstack = System.getProperty("java.home") + "/../bin/jstack";
		Process process = new ProcessBuilder(jstack, String.valueOf(Kernel32.INSTANCE.GetCurrentProcessId())).redirectErrorStream(true).start();
		BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
		try {
			String line;
			while((line = reader.readLine()) != null) {
				Matcher matcher = pattern.matcher(line);
				if (matcher.matches()) {
					System.out.println(line);
					col.add(Integer.decode(matcher.group(1)));
				}
			}
		} finally {
			reader.close();
		}
		return col;
	}

	static void setNativeThreadPriority(Collection<Integer> ids, int native_prio) {
		for (Integer id : ids) {
			Pointer hThread = Kernel32.INSTANCE.OpenThread(96, 0, id);
			if (hThread != null) {
				try {
					System.out.printf("%x: %d", id, Kernel32.INSTANCE.GetThreadPriority(hThread));
					if (Kernel32.INSTANCE.SetThreadPriority(hThread, native_prio) == 0) {
						throw new RuntimeException("SetThreadPriority(" + id + "," + native_prio + ")");
					}
					System.out.printf(" -> %d\n", Kernel32.INSTANCE.GetThreadPriority(hThread));
				} finally {
					Kernel32.INSTANCE.CloseHandle(hThread);
				}
			} else {
				throw new RuntimeException("OpenThread(" + id + ")");
			}
		}
	}
}

From vitalyd at gmail.com  Tue Sep 11 11:29:09 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 11 Sep 2012 07:29:09 -0400
Subject: Parallel GC thread priority
In-Reply-To: <SNT137-W62A8E92152F43B132E1BF58A930@phx.gbl>
References: <SNT137-W1FAD76A99BBBD6A05D9028AAF0@phx.gbl>
	<504A10D9.9090407@oracle.com>
	<CAHjP37FdfK=0DPOzyRS-FzzOS_JmthzMZWOEjCH3bFJXqOeo0g@mail.gmail.com>
	<504A1547.9080907@oracle.com>
	<CAHjP37Gc18k9HJpb1zqkhWttMP1eMPQaVki7kXvYTioa14zK+A@mail.gmail.com>
	<SNT137-W46B2B2F303D227CE5FCBA8AAF0@phx.gbl>
	<CAHjP37Ft669Aya-mTt2t1jpi8t3y8fP6AdRpjuebB44M9S0dBA@mail.gmail.com>
	<CABzyjy=7e4v-Gb+Y=Sk9+TTMRaE3vONuv4isK7t_5y8KXO=T5A@mail.gmail.com>
	<SNT137-W62A8E92152F43B132E1BF58A930@phx.gbl>
Message-ID: <CAHjP37GcQ_pCVB_Oj7R1U4Vxy2Vpcg8BmKRYsEmCMtXwaOj24Q@mail.gmail.com>

Hi Dmytro,

Thanks for experimenting with priorities.  So it's not surprising that
there would be scheduler interference when running lots of cpu hungry
processes/threads.  The time discrepancy in that case seems
reasonable/plausible.  But 1.2s of user + sys vs 30s of real just seems,
intuitively, like a bit too much to place blame on just the scheduler
interference.

I think your experiment does highlight that boosting gc thread priority
seems like a good thing (and it makes sense to me conceptually).  At the
very least I think there should be an XX option to control this behavior.

Thanks

Sent from my phone
On Sep 11, 2012 5:54 AM, "Dmytro Sheyko" <dmytro_sheyko at hotmail.com> wrote:

>  Hi,
>
> Here is a bit more details:
>
> {Heap before GC invocations=1468 (full 6):
> PSYoungGen      total 171904K, used 10352K [0x00000000eaab0000,
> 0x00000000f6940000, 0x0000000100000000)
>   eden space 161536K, 0% used
> [0x00000000eaab0000,0x00000000eaab0000,0x00000000f4870000)
>   from space 10368K, 99% used
> [0x00000000f5f20000,0x00000000f693c060,0x00000000f6940000)
>   to   space 16640K, 0% used
> [0x00000000f48c0000,0x00000000f48c0000,0x00000000f5900000)
> PSOldGen        total 408640K, used 403417K [0x00000000c0000000,
> 0x00000000d8f10000, 0x00000000eaab0000)
>   object space 408640K, 98% used
> [0x00000000c0000000,0x00000000d89f6478,0x00000000d8f10000)
> PSPermGen       total 83968K, used 76315K [0x00000000bae00000,
> 0x00000000c0000000, 0x00000000c0000000)
>   object space 83968K, 90% used
> [0x00000000bae00000,0x00000000bf886db0,0x00000000c0000000)
> 2012-03-05T00:03:06.936-0600: 130338.132: [Full GC [PSYoungGen:
> 10352K->0K(171904K)] [PSOldGen: 403417K->114637K(415872K)]
> 413769K->114637K(587776K) [PSPermGen: 76315K->76315K(83968K)], 30.2595731
> secs] [Times: user=0.77 sys=0.41, real=30.26 secs]
> Heap after GC invocations=1468 (full 6):
> PSYoungGen      total 171904K, used 0K [0x00000000eaab0000,
> 0x00000000f6940000, 0x0000000100000000)
>   eden space 161536K, 0% used
> [0x00000000eaab0000,0x00000000eaab0000,0x00000000f4870000)
>   from space 10368K, 0% used
> [0x00000000f5f20000,0x00000000f5f20000,0x00000000f6940000)
>   to   space 16640K, 0% used
> [0x00000000f48c0000,0x00000000f48c0000,0x00000000f5900000)
> PSOldGen        total 415872K, used 114637K [0x00000000c0000000,
> 0x00000000d9620000, 0x00000000eaab0000)
>   object space 415872K, 27% used
> [0x00000000c0000000,0x00000000c6ff3410,0x00000000d9620000)
> PSPermGen       total 83968K, used 76315K [0x00000000bae00000,
> 0x00000000c0000000, 0x00000000c0000000)
>   object space 83968K, 90% used
> [0x00000000bae00000,0x00000000bf886db0,0x00000000c0000000)
> }
>
> JVM is x64 Java 7u2.
> JVM options are (printed by -XX:+PrintCommandLineFlags):
> -XX:InitialHeapSize=536870912 -XX:MaxHeapSize=1073741824
> -XX:ParallelGCThreads=4 -XX:+PrintGC -XX:+PrintGCDateStamps
> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
> -XX:+PrintJNIGCStalls -XX:+ReduceSignalUsage -XX:+UseCompressedOops
> -XX:+UseLargePagesIndividualAllocation -XX:+UseParallelGC
>
> This happened several months ago and many things were changed since that:
> we added 4G RAM (8G -> 12G), tried other collectors CMS and G1, tried 32
> bit, tried other java 7 updates etc. And currently it works pretty well. I
> doubt I may experiment with our CI server in order to find the real cause
> of the long GC pause happened before, however please let me know what
> options are to be set, that would help us to prove that swapping is guilty
> of such discrepancy between CPU time and wall time if it happens again. I
> assume that the issue is not specific to PS and it can be observed with CMS
> and G1 also.
>
> Well, I almost forgot about such issue, but I noticed recently (analyzing
> jstack output) that Parallel GC threads work with NORM, while G1 and CMS
> use MAX priority. This seemed to me suspect.
> If it is intentional, what is the reason for this?
>
> Recently I wrote simple test (attached) to find out how other
> cpu-intensive applications impact on GC pauses.
> The test does following:
> 1. figures out Parallel GC threads and their native ids (using jstack)
> 2. raises their native priority from NORMAL(0) to HIGH(2) (using JNA)
> (optional)
> 3. starts java application (Disturber) that simply spins endless loop in
> several threads (100, configurable) just to consume cpu time.
> 4. generates garbage to provoke GC.
>
> Used following options:
> -Xmx1024m -Xms256m
> -server
> -showversion
> -XX:+PrintGCDetails
> -XX:+UseParallelGC
> -XX:+UseParallelOldGC
> -Ddisturber.java.priority=5
> -Dduration.ms=100000
> -Ddisturber.threads=100
> -Dgc.native.priority=0
>
>
> Got following results:
>
> 1. The test is run without any disturber threads (-Ddisturber.threads=0).
> Priority of GC threads does not matter. Typical GC log looks like this:
> [GC [PSYoungGen: 312502K->0K(349440K)] 898885K->625445K(1048512K),
> 0.0858486 secs] [Times: user=0.19 sys=0.00, real=0.09 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 937947K->664508K(1048512K),
> 0.0855026 secs] [Times: user=0.19 sys=0.00, real=0.09 secs]
> [Full GC [PSYoungGen: 0K->0K(349440K)] [ParOldGen:
> 664508K->78570K(699072K)] 664508K->78570K(1048512K) [PSPermGen:
> 3065K->3065K(16384K)], 0.4356773 secs] [Times: user=0.80 sys=0.00,
> real=0.44 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 391072K->117633K(1048512K),
> 0.0829569 secs] [Times: user=0.13 sys=0.02, real=0.08 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 430135K->156695K(1048512K),
> 0.0831900 secs] [Times: user=0.19 sys=0.00, real=0.08 secs]
>
> 2. The test is run with 100 disturber threads (-Ddisturber.threads=100).
> Priority of GC threads remains NORM(0) (-Dgc.native.priority=0). Typical GC
> log looks like this:
> [GC [PSYoungGen: 312502K->0K(349440K)] 664510K->391070K(814976K),
> 1.9201232 secs] [Times: user=0.13 sys=0.02, real=1.92 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 703572K->430133K(814976K),
> 1.9581938 secs] [Times: user=0.16 sys=0.05, real=1.96 secs]
> [Full GC [PSYoungGen: 0K->0K(349440K)] [ParOldGen:
> 430133K->78570K(490368K)] 430133K->78570K(839808K) [PSPermGen:
> 3065K->3065K(16384K)], 8.0233189 secs] [Times: user=0.41 sys=0.00,
> real=8.02 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 391072K->117633K(839808K),
> 2.1210901 secs] [Times: user=0.13 sys=0.02, real=2.12 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 430135K->156695K(839808K),
> 2.1864928 secs] [Times: user=0.13 sys=0.02, real=2.19 secs]
>
> 3. The test is run with 100 disturber threads (-Ddisturber.threads=100).
> Priority of GC threads is raisen to HIGH(2) (-Dgc.native.priority=2).
> Typical GC log looks like this:
> [GC [PSYoungGen: 312502K->0K(349440K)] 898885K->625445K(1048512K),
> 0.0824847 secs] [Times: user=0.16 sys=0.00, real=0.08 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 937947K->664508K(1048512K),
> 0.0823295 secs] [Times: user=0.17 sys=0.00, real=0.08 secs]
> [Full GC [PSYoungGen: 0K->0K(349440K)] [ParOldGen:
> 664508K->78570K(699072K)] 664508K->78570K(1048512K) [PSPermGen:
> 3065K->3065K(16384K)], 0.5145061 secs] [Times: user=0.65 sys=0.00,
> real=0.51 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 391072K->117633K(1048512K),
> 0.0793123 secs] [Times: user=0.16 sys=0.00, real=0.08 secs]
> [GC [PSYoungGen: 312502K->0K(349440K)] 430135K->156695K(1048512K),
> 0.0809080 secs] [Times: user=0.16 sys=0.00, real=0.08 secs]
>
> Here I can see that there is a noticeable difference between cpu and wall
> time of GC pauses in case #2 (when GC threads work with NORM priority and
> there are cpu intensive applications).
>
> I believe that Parallel GC threads are to be run with HIGH priority (or at
> least with highest priority of app threads they block), because otherwise
> there is some sort of priority inversion: GC threads block all application
> threads even those that run with HIGH priority, however they themself run
> with NORM priority and can be simply preempted with threads of other app
> that run with ABOVE_NORM and NORM priority.
>
> Thanks,
> Dmytro
>
> ------------------------------
> Date: Mon, 10 Sep 2012 17:22:51 +0100
> Subject: Re: Parallel GC thread priority
> From: ysr1729 at gmail.com
> To: vitalyd at gmail.com
> CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net
>
> I agree that eliminating paging as a suspect is a good idea. Although the
> stats that Dmytro provided below seems to show plenty of free RAM, perhaps
> that info was collected at a different time than when the long pause was
> observed?
>
> Like Vitaly, I am suspicious of paging in such extreme cases.
>
> What's the version of JVM you are running? (In such cases running with
> -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps would have been great as it
> just might have provided a couple more clues -- or not.)
> (There were some older versions of the JVM where there were issues with
> thread suspension that would cause long pauses, but i believe the GC log
> symptom of that was somewhat different.)
>
> By the way, since this is a 4 core system, you should be running
> -XX:+UseParallelOldGC.
>
> Note, for that reason, that "parallel gc thread" priority is moot for this
> case, it's really "(serial) GC thread", since there's a single GC thread
> running your full collection below. (Although your minor collections are
> indeed run multi-threaded.)
>
> -- ramki
>
> On Fri, Sep 7, 2012 at 5:53 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
>
> I see you're on windows, but on Linux I'm almost certain that time spent
> waiting for i/o does not count in sys time (it's purely CPU time).  I
> suspect, though, that windows does similar accounting but I'm not sure.
> Sent from my phone
> On Sep 7, 2012 12:31 PM, "Dmytro Sheyko" <dmytro_sheyko at hotmail.com>
> wrote:
>
>  Hi,
>
> I can provide following info only:
> ===
> System:
>  Microsoft Windows Server 2003 R2
>  Standard x64 Edition
>  Service Pack 2
> Computer:
>  Intel(R) Xeon(R) CPU E5-2640
>  2.50 GHz, 12.0 GB of RAM
> ===
> JConsole output:
>
> Operating System:       Windows 2003 5.2
> Architecture:           amd64
> Number of processors:   4
>
> Total physical memory:  12,582,100 kbytes
> Free physical memory:    6,184,012 kbytes
> Total swap space:       14,137,188 kbytes
> Free swap space:        11,189,520 kbytes
> ===
> But at time that this long GC pause happened it was 8 GB of RAM. And I
> don't know how much memory was used at that time.
>
> Please note that it's continuous integration server. Some build tasks are
> executed on the same machine. The pause happened on web server, which
> serves UI.
>
> BTW, isn't swapping counted as sys/kernel time?
>
> Thanks,
> Dmytro
>
>
> ------------------------------
> Date: Fri, 7 Sep 2012 11:45:34 -0400
> Subject: Re: Parallel GC thread priority
> From: vitalyd at gmail.com
> To: azeem.jiva at oracle.com
> CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net
>
> Whether it helps or not would depend on what priority the other threads
> are running at.  If the server had several jvms running at the same time
> and they all start a par new collection at about the same time, then yeah
> it won't help if priority is boosted - at that point, the machine is simply
> oversubscribed.
> In Dmytro's case, the wall time is so out of whack with CPU time that I
> wonder if it wasn't swapping that mostly contributed to this.  For such a
> relatively small heap, I can't imagine how much other stuff would have to
> run to inflate the time so much.
> Dmytro, what hardware spec was this on, out of curiosity?
> Sent from my phone
> On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>  I had not thought about other processes, which is a possibility.
> Although raising the priority of the GC threads won't help which I believe
> what Dmytro was suggestion.
>
>
> On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>
> You can have other threads from different processes in the system
> competing though.
> However, such a large wall time vs CPU time can also be caused by heavy
> swapping on a slow disk.  The heap there doesn't look all that big though
> ...
> Sent from my phone
> On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>  The Parallel collector is a stop-the-world collector.  The Java threads
> are suspended until the GC finishes.  I think your survivor spaces maybe
> mis-configured, and that's why you're seeing such large GC times.
>
>
> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>
>  Hi,
>
> I can see that Parallel GC works on threads with NormPriority, while CMS
> and G1 threads run with NearMaxPriority. This probably not an issue if java
> application works alone, but some time ago I observed GC log like this (it
> was Jenkins CI on Windows):
>
> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
> real=30.26 secs]
>
> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
> was 30.26 sec! It seems to me that the system was busy that time and GC
> threads was starving.
>
> If we could raise priority of Parallel GC threads, other application would
> have less impact on GC duration.
>
> What do you think?
>
> Thanks,
> Dmytro
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120911/683ea791/attachment.htm>

From stefan.karlsson at oracle.com  Tue Sep 11 19:28:38 2012
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Tue, 11 Sep 2012 19:28:38 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7197350: NPG: jvmtiHeapReferenceCallback
	receives incorrect reference_kind for system class roots
Message-ID: <20120911192843.339EC47A1C@hg.openjdk.java.net>

Changeset: ec98e58952b2
Author:    stefank
Date:      2012-09-11 14:59 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ec98e58952b2

7197350: NPG: jvmtiHeapReferenceCallback receives incorrect reference_kind for system class roots
Summary: Fix the iteration over the system classes and report the correct reference kind.
Reviewed-by: coleenp, rbackman

! src/share/vm/memory/iterator.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/prims/jvmtiTagMap.cpp



From mojianhao at gmail.com  Wed Sep 12 01:22:25 2012
From: mojianhao at gmail.com (Jianhao Mo)
Date: Wed, 12 Sep 2012 09:22:25 +0800
Subject: Crash on super large heap size using CMS and it's fix
In-Reply-To: <64D92A6C5C276D4295B6E763B63A698149149759@CNHZ-EXMAIL-03.ali.com>
References: <64D92A6C5C276D4295B6E763B63A6981491496BF@CNHZ-EXMAIL-03.ali.com>
	<64D92A6C5C276D4295B6E763B63A698149149759@CNHZ-EXMAIL-03.ali.com>
Message-ID: <CAKz_je4nJUcCFtV+24DtR3s7Xu4eiJ0=fyaHLhUX1-=OQmWV8Q@mail.gmail.com>

Hi all,

This is Hal Mo<kungu.mjh at taobao.com> from Alibaba Group(with OCA).

Our hadoop namenode crashed, when we set the heap size to 135G using CMS GC.
Attached please find the crash log(hs_err_pid.log).

I can steadily reproduce the crash on a test machine with 190G physical
memory, by a simple command:
$ java -Xmx135g -XX:+UseConcMarkSweepGC

Then I build a debug jvm and use gdb to debug the problem.

call stack

C  [libc.so.6+0x7a9b0]  memset+0x40
V  [libjvm.so+0x2b6c42]
 BlockOffsetArray::set_remainder_to_point_to_start_incl(unsigned long,
unsigned long, bool)+0xce
V  [libjvm.so+0x2b7043]
 BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, HeapWord*,
bool)+0x71
V  [libjvm.so+0x2b728d]
 BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, MemRegion,
bool)+0x9f
V  [libjvm.so+0x3c089f]
 BlockOffsetArrayNonContigSpace::BlockOffsetArrayNonContigSpace(BlockOffsetSharedArray*,
MemRegion)+0x37
V  [libjvm.so+0x3be56f]
 CompactibleFreeListSpace::CompactibleFreeListSpace(BlockOffsetSharedArray*,
MemRegion, bool, FreeBlockDictionary::DictionaryChoice)+0x9b
V  [libjvm.so+0x3fd2e1]
 ConcurrentMarkSweepGeneration::ConcurrentMarkSweepGeneration(ReservedSpace,
unsigned long, int, CardTableRS*, bool,
FreeBlockDictionary::DictionaryChoice)+0x1df
V  [libjvm.so+0x4dc03e]  GenerationSpec::init(ReservedSpace, int,
GenRemSet*)+0x37c
V  [libjvm.so+0x4ced40]  GenCollectedHeap::initialize()+0x510
V  [libjvm.so+0x7c23c3]  Universe::initialize_heap()+0x31d
V  [libjvm.so+0x7c27ec]  universe_init()+0xa6
V  [libjvm.so+0x5056e2]  init_globals()+0x34
V  [libjvm.so+0x7ac926]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x23a
V  [libjvm.so+0x53f3d4]  JNI_CreateJavaVM+0x7a

in function BlockOffsetArray::set_remainder_to_point_to_start_inc, inside
the for loop:
    size_t reach = start_card - 1 + (power_to_cards_back(i+1) - 1);
when i = 7, the value of reach was 0. then the loop could not break, and
    _array->set_offset_array(start_card_for_region, reach, offset,
reducing);
accessed the wrong address, and crashed.

the root cause was
static size_t power_to_cards_back(uint i) {
    return (size_t)(1 << (LogBase * i));
}
the literal 1 is a 32bit int, and 1<<32 overflow.


Here was my fix(has been tested), also found in attached file
cms_large_heap_crash.patch

+++ b/src/share/vm/memory/blockOffsetTable.hpp
@@ -289,7 +289,7 @@
};

static size_t power_to_cards_back(uint i) {
- return (size_t)(1 << (LogBase * i));
+ return (size_t)1 << (LogBase * i);
}
static size_t power_to_words_back(uint i) {
return power_to_cards_back(i) * N_words;

Contributed-by: Hal Mo <kungu.mjh at taobao.com>

Similar situation also found in G1, but the size is mega(2^20) based.
2^(32+20) is too large to overflow.

Krystal remind me, this changeset cover the same code,
http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82  .
I do not  build it on visual studio, someone please help to review the
compatibility with VS.

Regards,

Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/fc522952/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid.log
Type: application/octet-stream
Size: 27650 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/fc522952/hs_err_pid.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cms_large_heap_crash.patch
Type: application/octet-stream
Size: 446 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/fc522952/cms_large_heap_crash.patch>

From coleen.phillimore at oracle.com  Wed Sep 12 03:08:48 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 12 Sep 2012 03:08:48 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7196681: NPG: Some JSR 292 tests crash in
	Windows exception handler
Message-ID: <20120912030853.7A4F147A2E@hg.openjdk.java.net>

Changeset: 75f33eecc1b3
Author:    coleenp
Date:      2012-09-11 20:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/75f33eecc1b3

7196681: NPG: Some JSR 292 tests crash in Windows exception handler
Summary: There was a rogue os::breakpoint() call in log_dependency left over from the jsr292 merge.  Also changed verify_oop() calls for metadata to verify_{method,klass}_ptr.
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/code/dependencies.cpp



From roland.westrelin at oracle.com  Tue Sep 11 22:40:02 2012
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Tue, 11 Sep 2012 22:40:02 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7195816: NPG: Crash in c1_ValueType -
	ShouldNotReachHere
Message-ID: <20120911224006.2A86B47A28@hg.openjdk.java.net>

Changeset: 8a02ca5e5576
Author:    roland
Date:      2012-09-11 16:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8a02ca5e5576

7195816: NPG: Crash in c1_ValueType - ShouldNotReachHere
Summary: C1 needs knowledge of T_METADATA at the LIR level.
Reviewed-by: kvn, coleenp

! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! 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/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_ValueType.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/utilities/globalDefinitions.cpp



From mo_jianhao at hotmail.com  Wed Sep 12 01:00:15 2012
From: mo_jianhao at hotmail.com (=?gb2312?B?TbrAo6hIYWyjqQ==?=)
Date: Wed, 12 Sep 2012 09:00:15 +0800
Subject: Crash on super large heap size using CMS and it's fix
In-Reply-To: <64D92A6C5C276D4295B6E763B63A69814914974C@CNHZ-EXMAIL-03.ali.com>
References: <64D92A6C5C276D4295B6E763B63A6981491496BF@CNHZ-EXMAIL-03.ali.com>,
	<64D92A6C5C276D4295B6E763B63A69814914974C@CNHZ-EXMAIL-03.ali.com>
Message-ID: <SNT107-W10CBC9569AF0AB08BE47F1F8920@phx.gbl>


Hi all,


This is Hal Mo<kungu.mjh at taobao.com> from Alibaba Group(with OCA).



Our hadoop namenode crashed, when we set the heap size to 135G using CMS GC.
Attached please find the crash log(hs_err_pid.log).



I can steadily reproduce the crash on a test machine with 190G physical memory, by a simple command:
$ java -Xmx135g -XX:+UseConcMarkSweepGC



Then I build a debug jvm and use gdb to debug the problem.




call stack




C  [libc.so.6+0x7a9b0]  memset+0x40
V  [libjvm.so+0x2b6c42]  BlockOffsetArray::set_remainder_to_point_to_start_incl(unsigned long, unsigned long, bool)+0xce
V  [libjvm.so+0x2b7043]  BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, HeapWord*, bool)+0x71
V  [libjvm.so+0x2b728d]  BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, MemRegion, bool)+0x9f
V  [libjvm.so+0x3c089f]  BlockOffsetArrayNonContigSpace::BlockOffsetArrayNonContigSpace(BlockOffsetSharedArray*, MemRegion)+0x37
V  [libjvm.so+0x3be56f]  CompactibleFreeListSpace::CompactibleFreeListSpace(BlockOffsetSharedArray*, MemRegion, bool, FreeBlockDictionary::DictionaryChoice)+0x9b
V  [libjvm.so+0x3fd2e1]  ConcurrentMarkSweepGeneration::ConcurrentMarkSweepGeneration(ReservedSpace, unsigned long, int, CardTableRS*, bool, FreeBlockDictionary::DictionaryChoice)+0x1df
V  [libjvm.so+0x4dc03e]  GenerationSpec::init(ReservedSpace, int, GenRemSet*)+0x37c
V  [libjvm.so+0x4ced40]  GenCollectedHeap::initialize()+0x510
V  [libjvm.so+0x7c23c3]  Universe::initialize_heap()+0x31d
V  [libjvm.so+0x7c27ec]  universe_init()+0xa6
V  [libjvm.so+0x5056e2]  init_globals()+0x34
V  [libjvm.so+0x7ac926]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x23a
V  [libjvm.so+0x53f3d4]  JNI_CreateJavaVM+0x7a





in function BlockOffsetArray::set_remainder_to_point_to_start_inc, inside the for loop:

    size_t reach = start_card - 1 + (power_to_cards_back(i+1) - 1);

when i = 7, the value of reach was 0. then the loop could not break, and 

    _array->set_offset_array(start_card_for_region, reach, offset, reducing);

accessed the wrong address, and crashed.



the root cause was 
static size_t power_to_cards_back(uint i) {
    return (size_t)(1 << (LogBase * i));
}
the literal 1 is a 32bit int, and 1<<32 overflow. 






Here was my fix(has been tested), also found in attached file cms_large_heap_crash.patch



+++ b/src/share/vm/memory/blockOffsetTable.hpp

@@ -289,7 +289,7 @@

};



static size_t power_to_cards_back(uint i) {

- return (size_t)(1 << (LogBase * i));

+ return (size_t)1 << (LogBase * i);

}

static size_t power_to_words_back(uint i) {

return power_to_cards_back(i) * N_words;



Contributed-by: Hal Mo <kungu.mjh at taobao.com> 




Similar situation also found in G1, but the size is mega(2^20) based. 2^(32+20) is too large to overflow.



Krystal remind me, this changeset cover the same code, http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82 
 .
I do not  build it on visual studio, someone please help to review the compatibility with VS.



Regards,



Hal 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/865fe7fa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_err_pid.log
Type: application/octet-stream
Size: 27650 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/865fe7fa/hs_err_pid.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cms_large_heap_crash.patch
Type: application/octet-stream
Size: 446 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/865fe7fa/cms_large_heap_crash.patch>

From zhengyu.gu at oracle.com  Wed Sep 12 05:35:35 2012
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Wed, 12 Sep 2012 05:35:35 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 3 new changesets
Message-ID: <20120912053543.D7CA647A39@hg.openjdk.java.net>

Changeset: 33143ee07800
Author:    zgu
Date:      2012-09-11 20:53 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/33143ee07800

7181995: NMT ON: NMT assertion failure assert(cur_vm->is_uncommit_record() || cur_vm->is_deallocation_record
Summary: Fixed virtual memory records merge and promotion logic, should be based on sequence number vs. base address order
Reviewed-by: coleenp, acorn

! src/share/vm/runtime/thread.cpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtrArray.hpp
! src/share/vm/services/memSnapshot.cpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTrackWorker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: 3f18d439b402
Author:    zgu
Date:      2012-09-11 18:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3f18d439b402

Merge


Changeset: 43d524adb671
Author:    zgu
Date:      2012-09-11 20:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/43d524adb671

Merge




From bengt.rutisson at oracle.com  Wed Sep 12 07:50:02 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 12 Sep 2012 09:50:02 +0200
Subject: Crash on super large heap size using CMS and it's fix
In-Reply-To: <CAKz_je4nJUcCFtV+24DtR3s7Xu4eiJ0=fyaHLhUX1-=OQmWV8Q@mail.gmail.com>
References: <64D92A6C5C276D4295B6E763B63A6981491496BF@CNHZ-EXMAIL-03.ali.com>
	<64D92A6C5C276D4295B6E763B63A698149149759@CNHZ-EXMAIL-03.ali.com>
	<CAKz_je4nJUcCFtV+24DtR3s7Xu4eiJ0=fyaHLhUX1-=OQmWV8Q@mail.gmail.com>
Message-ID: <50503EAA.30206@oracle.com>


Hi Hal Mo,

Nice catch!

I filed "7197906:BlockOffsetArray::power_to_cards_back() needs to handle 
 > 32 bit shifts" to track this issue. I can help you shepherd this fix in.

Thanks,
Bengt


On 2012-09-12 03:22, Jianhao Mo wrote:
> Hi all,
>
> This is Hal Mo<kungu.mjh at taobao.com <mailto:kungu.mjh at taobao.com>> 
> from Alibaba Group(with OCA).
>
> Our hadoop namenode crashed, when we set the heap size to 135G using 
> CMS GC.
> Attached please find the crash log(hs_err_pid.log).
>
> I can steadily reproduce the crash on a test machine with 190G 
> physical memory, by a simple command:
> $ java -Xmx135g -XX:+UseConcMarkSweepGC
>
> Then I build a debug jvm and use gdb to debug the problem.
>
> call stack
>
> C  [libc.so.6+0x7a9b0]  memset+0x40
> V  [libjvm.so+0x2b6c42] 
>  BlockOffsetArray::set_remainder_to_point_to_start_incl(unsigned long, 
> unsigned long, bool)+0xce
> V  [libjvm.so+0x2b7043] 
>  BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, 
> HeapWord*, bool)+0x71
> V  [libjvm.so+0x2b728d] 
>  BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, 
> MemRegion, bool)+0x9f
> V  [libjvm.so+0x3c089f] 
>  BlockOffsetArrayNonContigSpace::BlockOffsetArrayNonContigSpace(BlockOffsetSharedArray*, 
> MemRegion)+0x37
> V  [libjvm.so+0x3be56f] 
>  CompactibleFreeListSpace::CompactibleFreeListSpace(BlockOffsetSharedArray*, 
> MemRegion, bool, FreeBlockDictionary::DictionaryChoice)+0x9b
> V  [libjvm.so+0x3fd2e1] 
>  ConcurrentMarkSweepGeneration::ConcurrentMarkSweepGeneration(ReservedSpace, 
> unsigned long, int, CardTableRS*, bool, 
> FreeBlockDictionary::DictionaryChoice)+0x1df
> V  [libjvm.so+0x4dc03e]  GenerationSpec::init(ReservedSpace, int, 
> GenRemSet*)+0x37c
> V  [libjvm.so+0x4ced40]  GenCollectedHeap::initialize()+0x510
> V  [libjvm.so+0x7c23c3]  Universe::initialize_heap()+0x31d
> V  [libjvm.so+0x7c27ec]  universe_init()+0xa6
> V  [libjvm.so+0x5056e2]  init_globals()+0x34
> V  [libjvm.so+0x7ac926]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x23a
> V  [libjvm.so+0x53f3d4]  JNI_CreateJavaVM+0x7a
>
> in function BlockOffsetArray::set_remainder_to_point_to_start_inc, 
> inside the for loop:
>     size_t reach = start_card - 1 + (power_to_cards_back(i+1) - 1);
> when i = 7, the value of reach was 0. then the loop could not break, and
>     _array->set_offset_array(start_card_for_region, reach, offset, 
> reducing);
> accessed the wrong address, and crashed.
>
> the root cause was
> static size_t power_to_cards_back(uint i) {
>     return (size_t)(1 << (LogBase * i));
> }
> the literal 1 is a 32bit int, and 1<<32 overflow.
>
>
> Here was my fix(has been tested), also found in attached file 
> cms_large_heap_crash.patch
>
> +++ b/src/share/vm/memory/blockOffsetTable.hpp
> @@ -289,7 +289,7 @@
> };
>
> static size_t power_to_cards_back(uint i) {
> - return (size_t)(1 << (LogBase * i));
> + return (size_t)1 << (LogBase * i);
> }
> static size_t power_to_words_back(uint i) {
> return power_to_cards_back(i) * N_words;
>
> Contributed-by: Hal Mo <kungu.mjh at taobao.com 
> <mailto:kungu.mjh at taobao.com>>
>
> Similar situation also found in G1, but the size is mega(2^20) based. 
> 2^(32+20) is too large to overflow.
>
> Krystal remind me, this changeset cover the same code, 
> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82  .
> I do not  build it on visual studio, someone please help to review the 
> compatibility with VS.
>
> Regards,
>
> Hal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/60781e61/attachment.htm>

From mojianhao at gmail.com  Wed Sep 12 10:12:11 2012
From: mojianhao at gmail.com (Jianhao Mo)
Date: Wed, 12 Sep 2012 18:12:11 +0800
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
Message-ID: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>

Hi all,

Could I get a couple of reviews for this small patch, please?

7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32 bit
shifts

CR link:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
Webrev:
http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
Contributed-by:
Hal Mo <kungu.mjh at taobao.com> from Alibaba Group(with OCA)

It may take a while before the CR link is publicly accessible.

In blockOffsetTable.hpp, there is an unexpected data truncation in
power_to_cards_back(uint i), which may lead to crashing the VM on very
large GC heaps.
The problem could be reproduced easily on machines, that have enough
memory, with:
$ java -Xmx135g -XX:+UseConcMarkSweepGC

The proposed patch fixes this problem, and builds on all OpenJDK supported
platforms.

I'd like to thank Bengt Rutisson for the initial review and help preparing
the CR and Webrev.

Regards,
Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/050cf4c4/attachment.htm>

From john.cuthbertson at oracle.com  Wed Sep 12 18:39:06 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 12 Sep 2012 11:39:06 -0700
Subject: Crash on super large heap size using CMS and it's fix
In-Reply-To: <50503EAA.30206@oracle.com>
References: <64D92A6C5C276D4295B6E763B63A6981491496BF@CNHZ-EXMAIL-03.ali.com>	<64D92A6C5C276D4295B6E763B63A698149149759@CNHZ-EXMAIL-03.ali.com>	<CAKz_je4nJUcCFtV+24DtR3s7Xu4eiJ0=fyaHLhUX1-=OQmWV8Q@mail.gmail.com>
	<50503EAA.30206@oracle.com>
Message-ID: <5050D6CA.6020200@oracle.com>

Hi Bengt,

Thanks for volunteering. I was until I saw your message.

Hal: Great catch.

We should probably change the other casts/shifts  in 
heapRegionRemSet.cpp and concurrentMark.cpp at the same time

./share/vm/gc_implementation/g1/heapRegionRemSet.cpp
     _max_fine_entries = (size_t)(1 << max_entries_log);

./share/vm/gc_implementation/g1/concurrentMark.cpp
   assert(((size_t)_bm.size() * (size_t)(1 << _shifter)) == _bmWordSize,

even though they shouldn't overflow.

JohnC

On 9/12/2012 12:50 AM, Bengt Rutisson wrote:
>
> Hi Hal Mo,
>
> Nice catch!
>
> I filed "7197906:BlockOffsetArray::power_to_cards_back() needs to 
> handle > 32 bit shifts" to track this issue. I can help you shepherd 
> this fix in.
>
> Thanks,
> Bengt
>
>
> On 2012-09-12 03:22, Jianhao Mo wrote:
>> Hi all,
>>
>> This is Hal Mo<kungu.mjh at taobao.com <mailto:kungu.mjh at taobao.com>> 
>> from Alibaba Group(with OCA).
>>
>> Our hadoop namenode crashed, when we set the heap size to 135G using 
>> CMS GC.
>> Attached please find the crash log(hs_err_pid.log).
>>
>> I can steadily reproduce the crash on a test machine with 190G 
>> physical memory, by a simple command:
>> $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>
>> Then I build a debug jvm and use gdb to debug the problem.
>>
>> call stack
>>
>> C  [libc.so.6+0x7a9b0]  memset+0x40
>> V  [libjvm.so+0x2b6c42] 
>>  BlockOffsetArray::set_remainder_to_point_to_start_incl(unsigned 
>> long, unsigned long, bool)+0xce
>> V  [libjvm.so+0x2b7043] 
>>  BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, 
>> HeapWord*, bool)+0x71
>> V  [libjvm.so+0x2b728d] 
>>  BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, 
>> MemRegion, bool)+0x9f
>> V  [libjvm.so+0x3c089f] 
>>  BlockOffsetArrayNonContigSpace::BlockOffsetArrayNonContigSpace(BlockOffsetSharedArray*, 
>> MemRegion)+0x37
>> V  [libjvm.so+0x3be56f] 
>>  CompactibleFreeListSpace::CompactibleFreeListSpace(BlockOffsetSharedArray*, 
>> MemRegion, bool, FreeBlockDictionary::DictionaryChoice)+0x9b
>> V  [libjvm.so+0x3fd2e1] 
>>  ConcurrentMarkSweepGeneration::ConcurrentMarkSweepGeneration(ReservedSpace, 
>> unsigned long, int, CardTableRS*, bool, 
>> FreeBlockDictionary::DictionaryChoice)+0x1df
>> V  [libjvm.so+0x4dc03e]  GenerationSpec::init(ReservedSpace, int, 
>> GenRemSet*)+0x37c
>> V  [libjvm.so+0x4ced40]  GenCollectedHeap::initialize()+0x510
>> V  [libjvm.so+0x7c23c3]  Universe::initialize_heap()+0x31d
>> V  [libjvm.so+0x7c27ec]  universe_init()+0xa6
>> V  [libjvm.so+0x5056e2]  init_globals()+0x34
>> V  [libjvm.so+0x7ac926]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x23a
>> V  [libjvm.so+0x53f3d4]  JNI_CreateJavaVM+0x7a
>>
>> in function BlockOffsetArray::set_remainder_to_point_to_start_inc, 
>> inside the for loop:
>>     size_t reach = start_card - 1 + (power_to_cards_back(i+1) - 1);
>> when i = 7, the value of reach was 0. then the loop could not break, and
>>     _array->set_offset_array(start_card_for_region, reach, offset, 
>> reducing);
>> accessed the wrong address, and crashed.
>>
>> the root cause was
>> static size_t power_to_cards_back(uint i) {
>>     return (size_t)(1 << (LogBase * i));
>> }
>> the literal 1 is a 32bit int, and 1<<32 overflow.
>>
>>
>> Here was my fix(has been tested), also found in attached file 
>> cms_large_heap_crash.patch
>>
>> +++ b/src/share/vm/memory/blockOffsetTable.hpp
>> @@ -289,7 +289,7 @@
>> };
>>
>> static size_t power_to_cards_back(uint i) {
>> - return (size_t)(1 << (LogBase * i));
>> + return (size_t)1 << (LogBase * i);
>> }
>> static size_t power_to_words_back(uint i) {
>> return power_to_cards_back(i) * N_words;
>>
>> Contributed-by: Hal Mo <kungu.mjh at taobao.com 
>> <mailto:kungu.mjh at taobao.com>>
>>
>> Similar situation also found in G1, but the size is mega(2^20) based. 
>> 2^(32+20) is too large to overflow.
>>
>> Krystal remind me, this changeset cover the same code, 
>> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82  .
>> I do not  build it on visual studio, someone please help to review 
>> the compatibility with VS.
>>
>> Regards,
>>
>> Hal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120912/8d016e99/attachment.htm>

From bengt.rutisson at oracle.com  Thu Sep 13 08:07:32 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 13 Sep 2012 10:07:32 +0200
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output comes
	out of order
Message-ID: <50519444.4020403@oracle.com>


Hi all,

Can I have some reviews for this change?
http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/

This fixes two issues that were introduced by a previous change I made 
to the G1 logging. Most importantly the time stamp for the GC log entry 
is now the start of the GC. Secondly, any interleaved logging that is 
done by other modules will be seen within the GC log entry. This is the 
way it used to be.

As an example using these switches on the command line "-XX:+UseG1GC 
-XX:+PrintGCDetails -XX:+PrintReferenceGC" currently produce output like:

3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: [WeakReference, 207 
refs, 0.0000440 secs]3.648: [FinalReference, 14473 refs, 0.0499260 
secs]3.698: [PhantomReference, 0 refs, 0.0000050 secs]3.698: [JNI Weak 
Reference, 0.0000120 secs]3.700: [GC pause (G1 Evacuation Pause) 
(young), 0.0853910 secs]
    [Parallel Time: 31.9 ms, GC Workers: 8]

But with my suggested fix it will be:

5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924 
secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: 
[FinalReference, 6 refs, 0.0000924 secs]6.032: [PhantomReference, 0 
refs, 0.0000893 secs]6.032: [JNI Weak Reference, 0 refs, 0.0001699 
secs], 0.2200814 secs]
    [Parallel Time: 214.3 ms, GC Workers: 4]


This is consistent with the way it looked before my previous change to 
the G1 logging:

3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090 
secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802: 
[FinalReference, 13020 refs, 0.0462290 secs]3.848: [PhantomReference, 7 
refs, 0.0000110 secs]3.848: [JNI Weak Reference, 0.0000150 secs], 
0.10515900 secs]
    [Parallel Time:  52.2 ms]


Thanks,
Bengt


From bengt.rutisson at oracle.com  Thu Sep 13 13:00:06 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 13 Sep 2012 15:00:06 +0200
Subject: Crash on super large heap size using CMS and it's fix
In-Reply-To: <5050D6CA.6020200@oracle.com>
References: <64D92A6C5C276D4295B6E763B63A6981491496BF@CNHZ-EXMAIL-03.ali.com>	<64D92A6C5C276D4295B6E763B63A698149149759@CNHZ-EXMAIL-03.ali.com>	<CAKz_je4nJUcCFtV+24DtR3s7Xu4eiJ0=fyaHLhUX1-=OQmWV8Q@mail.gmail.com>
	<50503EAA.30206@oracle.com> <5050D6CA.6020200@oracle.com>
Message-ID: <5051D8D6.1030402@oracle.com>



Hi John,

On 2012-09-12 20:39, John Cuthbertson wrote:
> Hi Bengt,
>
> Thanks for volunteering. I was until I saw your message.

I'm 9 hours ahead of you :-)

>
> Hal: Great catch.
>
> We should probably change the other casts/shifts  in 
> heapRegionRemSet.cpp and concurrentMark.cpp at the same time
>
> ./share/vm/gc_implementation/g1/heapRegionRemSet.cpp
>     _max_fine_entries = (size_t)(1 << max_entries_log);
>
> ./share/vm/gc_implementation/g1/concurrentMark.cpp
>   assert(((size_t)_bm.size() * (size_t)(1 << _shifter)) == _bmWordSize,
>
> even though they shouldn't overflow.

Good point. Hal sent out a review request on the mailing list. Maybe we 
should try to keep this conversation in that thread.

Hal, if you can prepare a patch that addresses John's comments I can 
help you with preparing an updated webrev that we can send out. If John 
thinks that looks good we will be all set to push the change.

Thanks,
Bengt

>
> JohnC
>
> On 9/12/2012 12:50 AM, Bengt Rutisson wrote:
>>
>> Hi Hal Mo,
>>
>> Nice catch!
>>
>> I filed "7197906:BlockOffsetArray::power_to_cards_back() needs to 
>> handle > 32 bit shifts" to track this issue. I can help you shepherd 
>> this fix in.
>>
>> Thanks,
>> Bengt
>>
>>
>> On 2012-09-12 03:22, Jianhao Mo wrote:
>>> Hi all,
>>>
>>> This is Hal Mo<kungu.mjh at taobao.com <mailto:kungu.mjh at taobao.com>> 
>>> from Alibaba Group(with OCA).
>>>
>>> Our hadoop namenode crashed, when we set the heap size to 135G using 
>>> CMS GC.
>>> Attached please find the crash log(hs_err_pid.log).
>>>
>>> I can steadily reproduce the crash on a test machine with 190G 
>>> physical memory, by a simple command:
>>> $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>>
>>> Then I build a debug jvm and use gdb to debug the problem.
>>>
>>> call stack
>>>
>>> C  [libc.so.6+0x7a9b0]  memset+0x40
>>> V  [libjvm.so+0x2b6c42] 
>>>  BlockOffsetArray::set_remainder_to_point_to_start_incl(unsigned 
>>> long, unsigned long, bool)+0xce
>>> V  [libjvm.so+0x2b7043] 
>>>  BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, 
>>> HeapWord*, bool)+0x71
>>> V  [libjvm.so+0x2b728d] 
>>>  BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, 
>>> MemRegion, bool)+0x9f
>>> V  [libjvm.so+0x3c089f] 
>>>  BlockOffsetArrayNonContigSpace::BlockOffsetArrayNonContigSpace(BlockOffsetSharedArray*, 
>>> MemRegion)+0x37
>>> V  [libjvm.so+0x3be56f] 
>>>  CompactibleFreeListSpace::CompactibleFreeListSpace(BlockOffsetSharedArray*, 
>>> MemRegion, bool, FreeBlockDictionary::DictionaryChoice)+0x9b
>>> V  [libjvm.so+0x3fd2e1] 
>>>  ConcurrentMarkSweepGeneration::ConcurrentMarkSweepGeneration(ReservedSpace, 
>>> unsigned long, int, CardTableRS*, bool, 
>>> FreeBlockDictionary::DictionaryChoice)+0x1df
>>> V  [libjvm.so+0x4dc03e]  GenerationSpec::init(ReservedSpace, int, 
>>> GenRemSet*)+0x37c
>>> V  [libjvm.so+0x4ced40]  GenCollectedHeap::initialize()+0x510
>>> V  [libjvm.so+0x7c23c3]  Universe::initialize_heap()+0x31d
>>> V  [libjvm.so+0x7c27ec]  universe_init()+0xa6
>>> V  [libjvm.so+0x5056e2]  init_globals()+0x34
>>> V  [libjvm.so+0x7ac926]  Threads::create_vm(JavaVMInitArgs*, 
>>> bool*)+0x23a
>>> V  [libjvm.so+0x53f3d4]  JNI_CreateJavaVM+0x7a
>>>
>>> in function BlockOffsetArray::set_remainder_to_point_to_start_inc, 
>>> inside the for loop:
>>>     size_t reach = start_card - 1 + (power_to_cards_back(i+1) - 1);
>>> when i = 7, the value of reach was 0. then the loop could not break, 
>>> and
>>>     _array->set_offset_array(start_card_for_region, reach, offset, 
>>> reducing);
>>> accessed the wrong address, and crashed.
>>>
>>> the root cause was
>>> static size_t power_to_cards_back(uint i) {
>>>     return (size_t)(1 << (LogBase * i));
>>> }
>>> the literal 1 is a 32bit int, and 1<<32 overflow.
>>>
>>>
>>> Here was my fix(has been tested), also found in attached file 
>>> cms_large_heap_crash.patch
>>>
>>> +++ b/src/share/vm/memory/blockOffsetTable.hpp
>>> @@ -289,7 +289,7 @@
>>> };
>>>
>>> static size_t power_to_cards_back(uint i) {
>>> - return (size_t)(1 << (LogBase * i));
>>> + return (size_t)1 << (LogBase * i);
>>> }
>>> static size_t power_to_words_back(uint i) {
>>> return power_to_cards_back(i) * N_words;
>>>
>>> Contributed-by: Hal Mo <kungu.mjh at taobao.com 
>>> <mailto:kungu.mjh at taobao.com>>
>>>
>>> Similar situation also found in G1, but the size is mega(2^20) 
>>> based. 2^(32+20) is too large to overflow.
>>>
>>> Krystal remind me, this changeset cover the same code, 
>>> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82  .
>>> I do not  build it on visual studio, someone please help to review 
>>> the compatibility with VS.
>>>
>>> Regards,
>>>
>>> Hal
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/d5cee77f/attachment.htm>

From mojianhao at gmail.com  Thu Sep 13 15:55:49 2012
From: mojianhao at gmail.com (Jianhao Mo)
Date: Thu, 13 Sep 2012 23:55:49 +0800
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
Message-ID: <CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>

Hi all,

Attached please find the new patch, modified according to John's advice.

Thanks Bengt again for the help :)

Regards,

Hal

2012/9/12 Jianhao Mo <mojianhao at gmail.com>

> Hi all,
>
> Could I get a couple of reviews for this small patch, please?
>
> 7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32 bit
> shifts
>
> CR link:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
> Webrev:
> http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
> Contributed-by:
> Hal Mo <kungu.mjh at taobao.com> from Alibaba Group(with OCA)
>
> It may take a while before the CR link is publicly accessible.
>
> In blockOffsetTable.hpp, there is an unexpected data truncation in
> power_to_cards_back(uint i), which may lead to crashing the VM on very
> large GC heaps.
> The problem could be reproduced easily on machines, that have enough
> memory, with:
> $ java -Xmx135g -XX:+UseConcMarkSweepGC
>
> The proposed patch fixes this problem, and builds on all OpenJDK supported
> platforms.
>
> I'd like to thank Bengt Rutisson for the initial review and help preparing
> the CR and Webrev.
>
> Regards,
> Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/ea04ef15/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs-gc-hal-mo-cms-fix-v2.patch
Type: application/octet-stream
Size: 1806 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/ea04ef15/hs-gc-hal-mo-cms-fix-v2.patch>

From ysr1729 at gmail.com  Thu Sep 13 16:12:49 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 13 Sep 2012 17:12:49 +0100
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
Message-ID: <CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>

Hal, thanks for the catch and the fix!

Bengt, might it be possible to host this as a traditional webrev in the
usual place, to simplify review logistics?

thanks!
-- ramki

On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo <mojianhao at gmail.com> wrote:

> Hi all,
>
> Attached please find the new patch, modified according to John's advice.
>
> Thanks Bengt again for the help :)
>
> Regards,
>
> Hal
>
> 2012/9/12 Jianhao Mo <mojianhao at gmail.com>
>
>> Hi all,
>>
>> Could I get a couple of reviews for this small patch, please?
>>
>> 7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32 bit
>> shifts
>>
>> CR link:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>> Webrev:
>> http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>> Contributed-by:
>> Hal Mo <kungu.mjh at taobao.com> from Alibaba Group(with OCA)
>>
>> It may take a while before the CR link is publicly accessible.
>>
>> In blockOffsetTable.hpp, there is an unexpected data truncation in
>> power_to_cards_back(uint i), which may lead to crashing the VM on very
>> large GC heaps.
>> The problem could be reproduced easily on machines, that have enough
>> memory, with:
>> $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>
>> The proposed patch fixes this problem, and builds on all OpenJDK
>> supported platforms.
>>
>> I'd like to thank Bengt Rutisson for the initial review and help
>> preparing the CR and Webrev.
>>
>> Regards,
>> Hal
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/303a3283/attachment.htm>

From john.cuthbertson at oracle.com  Thu Sep 13 16:58:12 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 13 Sep 2012 09:58:12 -0700
Subject: RFR(XS): 7193946: Move warnings associated with UseMemSetInBOT flag
Message-ID: <505210A4.2060202@oracle.com>

Hi Everyone,

Can I have a couple of volunteers review the changes for this CR? They 
are fairly small. The webrev can be found at: 
http://cr.openjdk.java.net/~johnc/7193946/webrev.0/

Summary:
In the review comments for the fix for 7192128, Bengt suggested to move 
the individual warnings from concurrentMarkSweepGeneration.cpp and 
g1Collectedheap.cpp and place a single warning in a common piece of 
code. These changes address that review comment. The suggested location 
(vm_version_sparc.cpp) was unsuitable as the routine which would be the 
natural choice is called twice and the warning would be issued twice. A 
better place is when we check the other GC flags for consistency in 
arguments.cpp.

Testing:
* command line testing
* GC basher and GCOld on sun4v with and without UseMemSetInBOT set

Thanks,

JohnC


From john.cuthbertson at oracle.com  Thu Sep 13 17:08:16 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 13 Sep 2012 10:08:16 -0700
Subject: RFR(S): 7016955: G1: remove the is_zeroed parameter from the
	HeapRegion constructor
Message-ID: <50521300.4030306@oracle.com>

Hi Everyone,

Can I have a volunteer to review the changes, which were contributed by 
Brandon Mitchell at Twitter, for this CR? The webrev can be found at: 
http://cr.openjdk.java.net/~johnc/7016955/webrev.0/

Summary:
When Tony removed the zero filling thread, the is_zeroed parameter in 
the HeapRegion constructor became unused. These changes remove that 
unused parameter and clean up the HeapRegion initialization code.

Testing:
SPECjvm98 and SPECjbb2005 on Linux (Brandon); GC test suite on solaris 
(x86 and sparc) and jprt (JohnC)

Thanks,

JohnC


From john.cuthbertson at oracle.com  Thu Sep 13 17:43:21 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 13 Sep 2012 10:43:21 -0700
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
Message-ID: <50521B39.5060601@oracle.com>

Hi Hal,

The changes look good to me.

JohnC

On 09/13/12 08:55, Jianhao Mo wrote:
> Hi all,
>
> Attached please find the new patch, modified according to John's advice.
>
> Thanks Bengt again for the help :)
>
> Regards,
>
> Hal
>
> 2012/9/12 Jianhao Mo <mojianhao at gmail.com <mailto:mojianhao at gmail.com>>
>
>     Hi all,
>
>     Could I get a couple of reviews for this small patch, please?
>
>     7197906: BlockOffsetArray::power_to_cards_back() needs to handle >
>     32 bit shifts
>
>     CR link:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>     Webrev:
>     http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>     <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.01/>
>     Contributed-by: 
>     Hal Mo <kungu.mjh at taobao.com <mailto:kungu.mjh at taobao.com>> from
>     Alibaba Group(with OCA) 
>
>     It may take a while before the CR link is publicly accessible.
>
>     In blockOffsetTable.hpp, there is an unexpected data truncation in
>     power_to_cards_back(uint i), which may lead to crashing the VM on
>     very large GC heaps.
>     The problem could be reproduced easily on machines, that have
>     enough memory, with:
>     $ java -Xmx135g -XX:+UseConcMarkSweepGC
>
>     The proposed patch fixes this problem, and builds on all OpenJDK
>     supported platforms.
>
>     I'd like to thank Bengt Rutisson for the initial review and help
>     preparing the CR and Webrev.
>
>     Regards,
>     Hal 
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/ba9df63d/attachment.htm>

From chunt at salesforce.com  Thu Sep 13 18:26:13 2012
From: chunt at salesforce.com (Charlie Hunt)
Date: Thu, 13 Sep 2012 11:26:13 -0700
Subject: [JDK 6u21]: does CMS report concurrent mode failure on perm gen
	expansion ?
Message-ID: <B248AC72-26B5-4BDF-B2C8-7C9CCAF67CB1@salesforce.com>

I'm looking at a GC log and surprised by the "concurrent mode failure" messages.

I'm seeing the following GC log entries as the first 8 GCs:

3.398: [Full GC 3.398: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.489: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1308660 secs] 594957K->594957K(8178944K), [CMS Perm : 21247K->21247K(21248K)], 0.1310260 secs] [Times: user=0.13 sys=0.03, real=0.14 secs]

3.529: [Full GC 3.529: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.617: [weak refs processing, 0.0000110 secs]: 0K->0K(6291456K), 0.1010290 secs] 594957K->594957K(8178944K), [CMS Perm : 21248K->21248K(42496K)], 0.1011530 secs] [Times: user=0.12 sys=0.00, real=0.10 secs]

3.638: [Full GC 3.638: [CMS (concurrent mode failure)[YG occupancy: 662071 K (1887488 K)]3.730: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1068710 secs] 662071K->662071K(8178944K), [CMS Perm : 21319K->21319K(42688K)], 0.1069610 secs] [Times: user=0.15 sys=0.00, real=0.11 secs]

3.772: [Full GC 3.772: [CMS (concurrent mode failure)[YG occupancy: 729184 K (1887488 K)]3.915: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1582170 secs] 729184K->729184K(8178944K), [CMS Perm : 21499K->21499K(42880K)], 0.1583500 secs] [Times: user=0.20 sys=0.00, real=0.16 secs]

3.962: [Full GC 3.962: [CMS (concurrent mode failure)[YG occupancy: 804686 K (1887488 K)]4.107: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1598050 secs] 804686K->804686K(8178944K), [CMS Perm : 21702K->21702K(43072K)], 0.1599420 secs] [Times: user=0.21 sys=0.00, real=0.16 secs]

4.497: [Full GC 4.497: [CMS (concurrent mode failure)[YG occupancy: 939150 K (1887488 K)]4.672: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1895350 secs] 939150K->939150K(8178944K), [CMS Perm : 22202K->22202K(43408K)], 0.1896680 secs] [Times: user=0.23 sys=0.00, real=0.19 secs]

5.054: [Full GC 5.054: [CMS (concurrent mode failure)[YG occupancy: 992483 K (1887488 K)]5.274: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.2347170 secs] 992483K->992483K(8178944K), [CMS Perm : 24058K->24058K(44408K)], 0.2348700 secs] [Times: user=0.28 sys=0.00, real=0.23 secs]

6.662: [Full GC 6.662: [CMS (concurrent mode failure)[YG occupancy: 1292895 K (1887488 K)]6.953: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.3063690 secs] 1292895K->1292895K(8178944K), [CMS Perm : 30692K->30692K(48120K)], 0.3065860 secs] [Times: user=0.66 sys=0.01, real=0.30 secs]

After these 8 GCs, the GC log is much inline with what I'd expect, i.e. ParNew GCs, initial-marks, remarks, etc.

In each of the above GCs:
- young gen is increasing in occupancy
- old gen remains empty
- perm gen space size is expanding

I can understand the Full GC being reported since perm gen is expanding, but I don't understand the reporting of "concurrent mode failure".  Am I missing something?  Is it possible HotSpot is reporting concurrent mode failure when perm gen is expanding?

Here's the set of command line options in use:
-Xmx8G -Xms8G -Xmn1500m -XX:+UseCompressedOops -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:MaxDirectMemorySize=5000m

thanks,

charlie ...

PS:  I didn't go look at / investigate OpenJDK HotSpot source code since this is JDK 6u21 and thought it might be possible something may have changed between 6u21 and what's in OpenJDK.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/9da1c0ad/attachment.htm>

From jon.masamitsu at oracle.com  Thu Sep 13 18:39:31 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 13 Sep 2012 11:39:31 -0700
Subject: RFR(S): 7016955: G1: remove the is_zeroed parameter from the
	HeapRegion constructor
In-Reply-To: <50521300.4030306@oracle.com>
References: <50521300.4030306@oracle.com>
Message-ID: <50522863.7090506@oracle.com>

Basically, it's deleting the G1OffsetTableContigSpace
version of initialize(), using the ContiguousSpace initialize()
and doing the little bit of extra work the constructor.
And, of course, dumping the is_zeroed parameter.

Looks good.


On 09/13/12 10:08, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a volunteer to review the changes, which were contributed 
> by Brandon Mitchell at Twitter, for this CR? The webrev can be found 
> at: http://cr.openjdk.java.net/~johnc/7016955/webrev.0/
>
> Summary:
> When Tony removed the zero filling thread, the is_zeroed parameter in 
> the HeapRegion constructor became unused. These changes remove that 
> unused parameter and clean up the HeapRegion initialization code.
>
> Testing:
> SPECjvm98 and SPECjbb2005 on Linux (Brandon); GC test suite on solaris 
> (x86 and sparc) and jprt (JohnC)
>
> Thanks,
>
> JohnC


From bengt.rutisson at oracle.com  Thu Sep 13 19:27:55 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 13 Sep 2012 21:27:55 +0200
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
	<CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>
Message-ID: <505233BB.4070909@oracle.com>


Hi Ramki,

Thanks for looking at this!

Here's a webrev based on the second patch that Hal sent out:
http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/

Bengt

On 2012-09-13 18:12, Srinivas Ramakrishna wrote:
> Hal, thanks for the catch and the fix!
>
> Bengt, might it be possible to host this as a traditional webrev in 
> the usual place, to simplify review logistics?
>
> thanks!
> -- ramki
>
> On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo <mojianhao at gmail.com 
> <mailto:mojianhao at gmail.com>> wrote:
>
>     Hi all,
>
>     Attached please find the new patch, modified according to John's
>     advice.
>
>     Thanks Bengt again for the help :)
>
>     Regards,
>
>     Hal
>
>     2012/9/12 Jianhao Mo <mojianhao at gmail.com
>     <mailto:mojianhao at gmail.com>>
>
>         Hi all,
>
>         Could I get a couple of reviews for this small patch, please?
>
>         7197906: BlockOffsetArray::power_to_cards_back() needs to
>         handle > 32 bit shifts
>
>         CR link:
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>         Webrev:
>         http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>         <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.01/>
>         Contributed-by:
>         Hal Mo <kungu.mjh at taobao.com <mailto:kungu.mjh at taobao.com>>
>         from Alibaba Group(with OCA)
>
>         It may take a while before the CR link is publicly accessible.
>
>         In blockOffsetTable.hpp, there is an unexpected data
>         truncation in power_to_cards_back(uint i), which may lead to
>         crashing the VM on very large GC heaps.
>         The problem could be reproduced easily on machines, that have
>         enough memory, with:
>         $ java -Xmx135g -XX:+UseConcMarkSweepGC
>
>         The proposed patch fixes this problem, and builds on all
>         OpenJDK supported platforms.
>
>         I'd like to thank Bengt Rutisson for the initial review and
>         help preparing the CR and Webrev.
>
>         Regards,
>         Hal 
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/6cb09d85/attachment.htm>

From jon.masamitsu at oracle.com  Thu Sep 13 19:37:15 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 13 Sep 2012 12:37:15 -0700
Subject: [JDK 6u21]: does CMS report concurrent mode failure on perm gen
	expansion ?
In-Reply-To: <B248AC72-26B5-4BDF-B2C8-7C9CCAF67CB1@salesforce.com>
References: <B248AC72-26B5-4BDF-B2C8-7C9CCAF67CB1@salesforce.com>
Message-ID: <505235EB.8020905@oracle.com>

Charlie,

It is probably a case of mislabeling.   I think in earlier
releases we were just dumbly labeling any full GC as
a concurrent mode failure.  But it is a concurrent mode
failure if the perm gen fills up.  Ramki had done some
work to start a concurrent collection for perm gen with
a different trigger.

Increase your PermSize so that we don't have to look
at it :-).

Jon


On 09/13/12 11:26, Charlie Hunt wrote:
> I'm looking at a GC log and surprised by the "concurrent mode failure" 
> messages.
>
> I'm seeing the following GC log entries as the first 8 GCs:
>
> 3.398: [Full GC 3.398: [CMS (concurrent mode failure)[YG occupancy: 
> 594957 K (1887488 K)]3.489: [weak refs processing, 0.0000140 secs]: 
> 0K->0K(6291456K), 0.1308660 secs] 594957K->594957K(8178944K), [CMS 
> Perm : 21247K->21247K(21248K)], 0.1310260 secs] [Times: user=0.13 
> sys=0.03, real=0.14 secs]
>
> 3.529: [Full GC 3.529: [CMS (concurrent mode failure)[YG occupancy: 
> 594957 K (1887488 K)]3.617: [weak refs processing, 0.0000110 secs]: 
> 0K->0K(6291456K), 0.1010290 secs] 594957K->594957K(8178944K), [CMS 
> Perm : 21248K->21248K(42496K)], 0.1011530 secs] [Times: user=0.12 
> sys=0.00, real=0.10 secs]
>
> 3.638: [Full GC 3.638: [CMS (concurrent mode failure)[YG occupancy: 
> 662071 K (1887488 K)]3.730: [weak refs processing, 0.0000140 secs]: 
> 0K->0K(6291456K), 0.1068710 secs] 662071K->662071K(8178944K), [CMS 
> Perm : 21319K->21319K(42688K)], 0.1069610 secs] [Times: user=0.15 
> sys=0.00, real=0.11 secs]
>
> 3.772: [Full GC 3.772: [CMS (concurrent mode failure)[YG occupancy: 
> 729184 K (1887488 K)]3.915: [weak refs processing, 0.0000140 secs]: 
> 0K->0K(6291456K), 0.1582170 secs] 729184K->729184K(8178944K), [CMS 
> Perm : 21499K->21499K(42880K)], 0.1583500 secs] [Times: user=0.20 
> sys=0.00, real=0.16 secs]
>
> 3.962: [Full GC 3.962: [CMS (concurrent mode failure)[YG occupancy: 
> 804686 K (1887488 K)]4.107: [weak refs processing, 0.0000130 secs]: 
> 0K->0K(6291456K), 0.1598050 secs] 804686K->804686K(8178944K), [CMS 
> Perm : 21702K->21702K(43072K)], 0.1599420 secs] [Times: user=0.21 
> sys=0.00, real=0.16 secs]
>
> 4.497: [Full GC 4.497: [CMS (concurrent mode failure)[YG occupancy: 
> 939150 K (1887488 K)]4.672: [weak refs processing, 0.0000130 secs]: 
> 0K->0K(6291456K), 0.1895350 secs] 939150K->939150K(8178944K), [CMS 
> Perm : 22202K->22202K(43408K)], 0.1896680 secs] [Times: user=0.23 
> sys=0.00, real=0.19 secs]
>
> 5.054: [Full GC 5.054: [CMS (concurrent mode failure)[YG occupancy: 
> 992483 K (1887488 K)]5.274: [weak refs processing, 0.0000130 secs]: 
> 0K->0K(6291456K), 0.2347170 secs] 992483K->992483K(8178944K), [CMS 
> Perm : 24058K->24058K(44408K)], 0.2348700 secs] [Times: user=0.28 
> sys=0.00, real=0.23 secs]
>
> 6.662: [Full GC 6.662: [CMS (concurrent mode failure)[YG occupancy: 
> 1292895 K (1887488 K)]6.953: [weak refs processing, 0.0000140 secs]: 
> 0K->0K(6291456K), 0.3063690 secs] 1292895K->1292895K(8178944K), [CMS 
> Perm : 30692K->30692K(48120K)], 0.3065860 secs] [Times: user=0.66 
> sys=0.01, real=0.30 secs]
>
> After these 8 GCs, the GC log is much inline with what I'd expect, 
> i.e. ParNew GCs, initial-marks, remarks, etc.
>
> In each of the above GCs:
> - young gen is increasing in occupancy
> - old gen remains empty
> - perm gen space size is expanding
>
> I can understand the Full GC being reported since perm gen is 
> expanding, but I don't understand the reporting of "concurrent mode 
> failure".  Am I missing something?  Is it possible HotSpot is 
> reporting concurrent mode failure when perm gen is expanding?
>
> Here's the set of command line options in use:
> -Xmx8G -Xms8G -Xmn1500m -XX:+UseCompressedOops -XX:-UseGCOverheadLimit 
> -XX:+UseConcMarkSweepGC -XX:MaxDirectMemorySize=5000m
>
> thanks,
>
> charlie ...
>
> PS:  I didn't go look at / investigate OpenJDK HotSpot source code 
> since this is JDK 6u21 and thought it might be possible something may 
> have changed between 6u21 and what's in OpenJDK.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/50b221b8/attachment.htm>

From chunt at salesforce.com  Thu Sep 13 21:09:18 2012
From: chunt at salesforce.com (Charlie Hunt)
Date: Thu, 13 Sep 2012 14:09:18 -0700
Subject: [JDK 6u21]: does CMS report concurrent mode failure on perm gen
	expansion ?
In-Reply-To: <505235EB.8020905@oracle.com>
References: <B248AC72-26B5-4BDF-B2C8-7C9CCAF67CB1@salesforce.com>
	<505235EB.8020905@oracle.com>
Message-ID: <8AE43E82-7EE8-4D92-9066-95F8DE807635@salesforce.com>

Hi Jon,

As often is the case, thanks for confirming my suspicions!

Increasing PermSize is definitely in order. :-)

thanks again,

charlie ...

On Sep 13, 2012, at 2:37 PM, Jon Masamitsu wrote:

Charlie,

It is probably a case of mislabeling.   I think in earlier
releases we were just dumbly labeling any full GC as
a concurrent mode failure.  But it is a concurrent mode
failure if the perm gen fills up.  Ramki had done some
work to start a concurrent collection for perm gen with
a different trigger.

Increase your PermSize so that we don't have to look
at it :-).

Jon


On 09/13/12 11:26, Charlie Hunt wrote:
I'm looking at a GC log and surprised by the "concurrent mode failure" messages.

I'm seeing the following GC log entries as the first 8 GCs:

3.398: [Full GC 3.398: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.489: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1308660 secs] 594957K->594957K(8178944K), [CMS Perm : 21247K->21247K(21248K)], 0.1310260 secs] [Times: user=0.13 sys=0.03, real=0.14 secs]

3.529: [Full GC 3.529: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.617: [weak refs processing, 0.0000110 secs]: 0K->0K(6291456K), 0.1010290 secs] 594957K->594957K(8178944K), [CMS Perm : 21248K->21248K(42496K)], 0.1011530 secs] [Times: user=0.12 sys=0.00, real=0.10 secs]

3.638: [Full GC 3.638: [CMS (concurrent mode failure)[YG occupancy: 662071 K (1887488 K)]3.730: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1068710 secs] 662071K->662071K(8178944K), [CMS Perm : 21319K->21319K(42688K)], 0.1069610 secs] [Times: user=0.15 sys=0.00, real=0.11 secs]

3.772: [Full GC 3.772: [CMS (concurrent mode failure)[YG occupancy: 729184 K (1887488 K)]3.915: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1582170 secs] 729184K->729184K(8178944K), [CMS Perm : 21499K->21499K(42880K)], 0.1583500 secs] [Times: user=0.20 sys=0.00, real=0.16 secs]

3.962: [Full GC 3.962: [CMS (concurrent mode failure)[YG occupancy: 804686 K (1887488 K)]4.107: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1598050 secs] 804686K->804686K(8178944K), [CMS Perm : 21702K->21702K(43072K)], 0.1599420 secs] [Times: user=0.21 sys=0.00, real=0.16 secs]

4.497: [Full GC 4.497: [CMS (concurrent mode failure)[YG occupancy: 939150 K (1887488 K)]4.672: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1895350 secs] 939150K->939150K(8178944K), [CMS Perm : 22202K->22202K(43408K)], 0.1896680 secs] [Times: user=0.23 sys=0.00, real=0.19 secs]

5.054: [Full GC 5.054: [CMS (concurrent mode failure)[YG occupancy: 992483 K (1887488 K)]5.274: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.2347170 secs] 992483K->992483K(8178944K), [CMS Perm : 24058K->24058K(44408K)], 0.2348700 secs] [Times: user=0.28 sys=0.00, real=0.23 secs]

6.662: [Full GC 6.662: [CMS (concurrent mode failure)[YG occupancy: 1292895 K (1887488 K)]6.953: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.3063690 secs] 1292895K->1292895K(8178944K), [CMS Perm : 30692K->30692K(48120K)], 0.3065860 secs] [Times: user=0.66 sys=0.01, real=0.30 secs]

After these 8 GCs, the GC log is much inline with what I'd expect, i.e. ParNew GCs, initial-marks, remarks, etc.

In each of the above GCs:
- young gen is increasing in occupancy
- old gen remains empty
- perm gen space size is expanding

I can understand the Full GC being reported since perm gen is expanding, but I don't understand the reporting of "concurrent mode failure".  Am I missing something?  Is it possible HotSpot is reporting concurrent mode failure when perm gen is expanding?

Here's the set of command line options in use:
-Xmx8G -Xms8G -Xmn1500m -XX:+UseCompressedOops -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:MaxDirectMemorySize=5000m

thanks,

charlie ...

PS:  I didn't go look at / investigate OpenJDK HotSpot source code since this is JDK 6u21 and thought it might be possible something may have changed between 6u21 and what's in OpenJDK.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/47ff90e9/attachment.htm>

From ysr1729 at gmail.com  Thu Sep 13 22:15:12 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 13 Sep 2012 23:15:12 +0100
Subject: [JDK 6u21]: does CMS report concurrent mode failure on perm gen
	expansion ?
In-Reply-To: <8AE43E82-7EE8-4D92-9066-95F8DE807635@salesforce.com>
References: <B248AC72-26B5-4BDF-B2C8-7C9CCAF67CB1@salesforce.com>
	<505235EB.8020905@oracle.com>
	<8AE43E82-7EE8-4D92-9066-95F8DE807635@salesforce.com>
Message-ID: <CABzyjykzpxGB+msn2LcZkSN28K=MV6Rt277CeLcCVTcES7kpVw@mail.gmail.com>

Right, it's a bug for CMS to cause a full gc for perm gen expansion. There
were a couple of releases in 6uXX (for a suitable value of hsXX)
where this regression had crept in unnoticed until it was noticed and
fixed. Try the more recent 7uXX (pre-perm gen removal changes) where you
should
find the perm gen expand without a stop-world full gc (and may be trigger a
CMS concurrent cycle instead, memory is hazy and
the source code not close at hand). As you guys noted the workaround is to
max-size the perm gen and enable class unloading.

-- ramki

On Thu, Sep 13, 2012 at 10:09 PM, Charlie Hunt <chunt at salesforce.com> wrote:

> Hi Jon,
>
> As often is the case, thanks for confirming my suspicions!
>
> Increasing PermSize is definitely in order. :-)
>
> thanks again,
>
> charlie ...
>
> On Sep 13, 2012, at 2:37 PM, Jon Masamitsu wrote:
>
>  Charlie,
>
> It is probably a case of mislabeling.   I think in earlier
> releases we were just dumbly labeling any full GC as
> a concurrent mode failure.  But it is a concurrent mode
> failure if the perm gen fills up.  Ramki had done some
> work to start a concurrent collection for perm gen with
> a different trigger.
>
> Increase your PermSize so that we don't have to look
> at it :-).
>
> Jon
>
>
> On 09/13/12 11:26, Charlie Hunt wrote:
>
> I'm looking at a GC log and surprised by the "concurrent mode failure"
> messages.
>
>  I'm seeing the following GC log entries as the first 8 GCs:
>
>  3.398: [Full GC 3.398: [CMS (concurrent mode failure)[YG occupancy:
> 594957 K (1887488 K)]3.489: [weak refs processing, 0.0000140 secs]:
> 0K->0K(6291456K), 0.1308660 secs] 594957K->594957K(8178944K), [CMS Perm :
> 21247K->21247K(21248K)], 0.1310260 secs] [Times: user=0.13 sys=0.03,
> real=0.14 secs]
>
>  3.529: [Full GC 3.529: [CMS (concurrent mode failure)[YG occupancy:
> 594957 K (1887488 K)]3.617: [weak refs processing, 0.0000110 secs]:
> 0K->0K(6291456K), 0.1010290 secs] 594957K->594957K(8178944K), [CMS Perm :
> 21248K->21248K(42496K)], 0.1011530 secs] [Times: user=0.12 sys=0.00,
> real=0.10 secs]
>
>  3.638: [Full GC 3.638: [CMS (concurrent mode failure)[YG occupancy:
> 662071 K (1887488 K)]3.730: [weak refs processing, 0.0000140 secs]:
> 0K->0K(6291456K), 0.1068710 secs] 662071K->662071K(8178944K), [CMS Perm :
> 21319K->21319K(42688K)], 0.1069610 secs] [Times: user=0.15 sys=0.00,
> real=0.11 secs]
>
>  3.772: [Full GC 3.772: [CMS (concurrent mode failure)[YG occupancy:
> 729184 K (1887488 K)]3.915: [weak refs processing, 0.0000140 secs]:
> 0K->0K(6291456K), 0.1582170 secs] 729184K->729184K(8178944K), [CMS Perm :
> 21499K->21499K(42880K)], 0.1583500 secs] [Times: user=0.20 sys=0.00,
> real=0.16 secs]
>
>  3.962: [Full GC 3.962: [CMS (concurrent mode failure)[YG occupancy:
> 804686 K (1887488 K)]4.107: [weak refs processing, 0.0000130 secs]:
> 0K->0K(6291456K), 0.1598050 secs] 804686K->804686K(8178944K), [CMS Perm :
> 21702K->21702K(43072K)], 0.1599420 secs] [Times: user=0.21 sys=0.00,
> real=0.16 secs]
>
>  4.497: [Full GC 4.497: [CMS (concurrent mode failure)[YG occupancy:
> 939150 K (1887488 K)]4.672: [weak refs processing, 0.0000130 secs]:
> 0K->0K(6291456K), 0.1895350 secs] 939150K->939150K(8178944K), [CMS Perm :
> 22202K->22202K(43408K)], 0.1896680 secs] [Times: user=0.23 sys=0.00,
> real=0.19 secs]
>
>  5.054: [Full GC 5.054: [CMS (concurrent mode failure)[YG occupancy:
> 992483 K (1887488 K)]5.274: [weak refs processing, 0.0000130 secs]:
> 0K->0K(6291456K), 0.2347170 secs] 992483K->992483K(8178944K), [CMS Perm :
> 24058K->24058K(44408K)], 0.2348700 secs] [Times: user=0.28 sys=0.00,
> real=0.23 secs]
>
>  6.662: [Full GC 6.662: [CMS (concurrent mode failure)[YG occupancy:
> 1292895 K (1887488 K)]6.953: [weak refs processing, 0.0000140 secs]:
> 0K->0K(6291456K), 0.3063690 secs] 1292895K->1292895K(8178944K), [CMS Perm :
> 30692K->30692K(48120K)], 0.3065860 secs] [Times: user=0.66 sys=0.01,
> real=0.30 secs]
>
>  After these 8 GCs, the GC log is much inline with what I'd expect, i.e.
> ParNew GCs, initial-marks, remarks, etc.
>
>  In each of the above GCs:
> - young gen is increasing in occupancy
> - old gen remains empty
> - perm gen space size is expanding
>
>  I can understand the Full GC being reported since perm gen is expanding,
> but I don't understand the reporting of "concurrent mode failure".  Am I
> missing something?  Is it possible HotSpot is reporting concurrent mode
> failure when perm gen is expanding?
>
>  Here's the set of command line options in use:
> -Xmx8G -Xms8G -Xmn1500m -XX:+UseCompressedOops -XX:-UseGCOverheadLimit
> -XX:+UseConcMarkSweepGC -XX:MaxDirectMemorySize=5000m
>
>  thanks,
>
>  charlie ...
>
>  PS:  I didn't go look at / investigate OpenJDK HotSpot source code since
> this is JDK 6u21 and thought it might be possible something may have
> changed between 6u21 and what's in OpenJDK.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/6772a7fd/attachment.htm>

From ysr1729 at gmail.com  Thu Sep 13 22:21:43 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 13 Sep 2012 23:21:43 +0100
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <505233BB.4070909@oracle.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
	<CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>
	<505233BB.4070909@oracle.com>
Message-ID: <CABzyjynm8mPN=TvFAmDStiXyPONkj=Y_QuZzeUD_GN17nOeT6A@mail.gmail.com>

Thanks Bengt; changes look good to me too, Hal, although i just looked at
the changes, and did not
check the code to see if there might be more instances of the fingered
anti-pattern. (I am pretty sure
you and John and other reviewers have covered that front well :-)

Bengt, any chance that the fix will get bkported also to 7uXX soon, for
some suitable value of XX?

thanks!
-- ramki

On Thu, Sep 13, 2012 at 8:27 PM, Bengt Rutisson
<bengt.rutisson at oracle.com>wrote:

>
> Hi Ramki,
>
> Thanks for looking at this!
>
> Here's a webrev based on the second patch that Hal sent out:
> http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/
>
> Bengt
>
>
> On 2012-09-13 18:12, Srinivas Ramakrishna wrote:
>
> Hal, thanks for the catch and the fix!
>
> Bengt, might it be possible to host this as a traditional webrev in the
> usual place, to simplify review logistics?
>
> thanks!
> -- ramki
>
> On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo <mojianhao at gmail.com> wrote:
>
>> Hi all,
>>
>>  Attached please find the new patch, modified according to John's advice.
>>
>>  Thanks Bengt again for the help :)
>>
>>  Regards,
>>
>>  Hal
>>
>> 2012/9/12 Jianhao Mo <mojianhao at gmail.com>
>>
>>> Hi all,
>>>
>>>  Could I get a couple of reviews for this small patch, please?
>>>
>>>  7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32
>>> bit shifts
>>>
>>>  CR link:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>>> Webrev:
>>> http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>>> Contributed-by:
>>>  Hal Mo <kungu.mjh at taobao.com> from Alibaba Group(with OCA)
>>>
>>>  It may take a while before the CR link is publicly accessible.
>>>
>>>  In blockOffsetTable.hpp, there is an unexpected data truncation in
>>> power_to_cards_back(uint i), which may lead to crashing the VM on very
>>> large GC heaps.
>>> The problem could be reproduced easily on machines, that have enough
>>> memory, with:
>>>  $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>>
>>>   The proposed patch fixes this problem, and builds on all OpenJDK
>>> supported platforms.
>>>
>>>  I'd like to thank Bengt Rutisson for the initial review and help
>>> preparing the CR and Webrev.
>>>
>>>  Regards,
>>> Hal
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/ceac9c54/attachment.htm>

From john.cuthbertson at oracle.com  Thu Sep 13 23:19:00 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 13 Sep 2012 16:19:00 -0700
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <CABzyjynm8mPN=TvFAmDStiXyPONkj=Y_QuZzeUD_GN17nOeT6A@mail.gmail.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>	<CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>	<505233BB.4070909@oracle.com>
	<CABzyjynm8mPN=TvFAmDStiXyPONkj=Y_QuZzeUD_GN17nOeT6A@mail.gmail.com>
Message-ID: <505269E4.9040301@oracle.com>

Hi Ramki,

I don't think there will be an issue with back porting this to hs24 
(which I think is going into 7u12). I just have to check the dates. 
There's a couple of other CRs that we're probably going to want to back 
port as well.

I searched the sources for the offending pattern (with and without 
whitespace) and only found the instances fixed by Hal. I think we're OK 
in that respect. But thanks for making sure. :)

JohnC

On 09/13/12 15:21, Srinivas Ramakrishna wrote:
>
> Thanks Bengt; changes look good to me too, Hal, although i just looked 
> at the changes, and did not
> check the code to see if there might be more instances of the fingered 
> anti-pattern. (I am pretty sure
> you and John and other reviewers have covered that front well :-)
>
> Bengt, any chance that the fix will get bkported also to 7uXX soon, 
> for some suitable value of XX?
>
> thanks!
> -- ramki
>
> On Thu, Sep 13, 2012 at 8:27 PM, Bengt Rutisson 
> <bengt.rutisson at oracle.com <mailto:bengt.rutisson at oracle.com>> wrote:
>
>
>     Hi Ramki,
>
>     Thanks for looking at this!
>
>     Here's a webrev based on the second patch that Hal sent out:
>     http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/
>     <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.02/>
>
>     Bengt
>
>
>     On 2012-09-13 18:12, Srinivas Ramakrishna wrote:
>>     Hal, thanks for the catch and the fix!
>>
>>     Bengt, might it be possible to host this as a traditional webrev
>>     in the usual place, to simplify review logistics?
>>
>>     thanks!
>>     -- ramki
>>
>>     On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo <mojianhao at gmail.com
>>     <mailto:mojianhao at gmail.com>> wrote:
>>
>>         Hi all,
>>
>>         Attached please find the new patch, modified according
>>         to John's advice.
>>
>>         Thanks Bengt again for the help :)
>>
>>         Regards,
>>
>>         Hal
>>
>>         2012/9/12 Jianhao Mo <mojianhao at gmail.com
>>         <mailto:mojianhao at gmail.com>>
>>
>>             Hi all,
>>
>>             Could I get a couple of reviews for this small patch, please?
>>
>>             7197906: BlockOffsetArray::power_to_cards_back() needs to
>>             handle > 32 bit shifts
>>
>>             CR link:
>>             http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>>             Webrev:
>>             http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>>             <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.01/>
>>             Contributed-by: 
>>             Hal Mo <kungu.mjh at taobao.com
>>             <mailto:kungu.mjh at taobao.com>> from Alibaba Group(with OCA) 
>>
>>             It may take a while before the CR link is publicly
>>             accessible.
>>
>>             In blockOffsetTable.hpp, there is an unexpected data
>>             truncation in power_to_cards_back(uint i), which may lead
>>             to crashing the VM on very large GC heaps.
>>             The problem could be reproduced easily on machines, that
>>             have enough memory, with:
>>             $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>
>>             The proposed patch fixes this problem, and builds on all
>>             OpenJDK supported platforms.
>>
>>             I'd like to thank Bengt Rutisson for the initial review
>>             and help preparing the CR and Webrev.
>>
>>             Regards,
>>             Hal 
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120913/a8d9da2f/attachment.htm>

From ysr1729 at gmail.com  Thu Sep 13 23:26:57 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Fri, 14 Sep 2012 00:26:57 +0100
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <505269E4.9040301@oracle.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
	<CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>
	<505233BB.4070909@oracle.com>
	<CABzyjynm8mPN=TvFAmDStiXyPONkj=Y_QuZzeUD_GN17nOeT6A@mail.gmail.com>
	<505269E4.9040301@oracle.com>
Message-ID: <CABzyjynqngYEETuJNERZUta8L4OLAQjWWbipp77a0u5OSGAE+g@mail.gmail.com>

Great, thanks John, all!

-- ramki

On Fri, Sep 14, 2012 at 12:19 AM, John Cuthbertson <
john.cuthbertson at oracle.com> wrote:

> **
> Hi Ramki,
>
> I don't think there will be an issue with back porting this to hs24 (which
> I think is going into 7u12). I just have to check the dates. There's a
> couple of other CRs that we're probably going to want to back port as well.
>
> I searched the sources for the offending pattern (with and without
> whitespace) and only found the instances fixed by Hal. I think we're OK in
> that respect. But thanks for making sure. :)
>
> JohnC
>
>
> On 09/13/12 15:21, Srinivas Ramakrishna wrote:
>
>
> Thanks Bengt; changes look good to me too, Hal, although i just looked at
> the changes, and did not
> check the code to see if there might be more instances of the fingered
> anti-pattern. (I am pretty sure
> you and John and other reviewers have covered that front well :-)
>
> Bengt, any chance that the fix will get bkported also to 7uXX soon, for
> some suitable value of XX?
>
> thanks!
> -- ramki
>
> On Thu, Sep 13, 2012 at 8:27 PM, Bengt Rutisson <bengt.rutisson at oracle.com
> > wrote:
>
>>
>> Hi Ramki,
>>
>> Thanks for looking at this!
>>
>> Here's a webrev based on the second patch that Hal sent out:
>> http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/
>>
>> Bengt
>>
>>
>> On 2012-09-13 18:12, Srinivas Ramakrishna wrote:
>>
>> Hal, thanks for the catch and the fix!
>>
>> Bengt, might it be possible to host this as a traditional webrev in the
>> usual place, to simplify review logistics?
>>
>> thanks!
>> -- ramki
>>
>> On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo <mojianhao at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>  Attached please find the new patch, modified according to John's
>>> advice.
>>>
>>>  Thanks Bengt again for the help :)
>>>
>>>  Regards,
>>>
>>>  Hal
>>>
>>> 2012/9/12 Jianhao Mo <mojianhao at gmail.com>
>>>
>>>> Hi all,
>>>>
>>>>  Could I get a couple of reviews for this small patch, please?
>>>>
>>>>  7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32
>>>> bit shifts
>>>>
>>>>  CR link:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>>>> Contributed-by:
>>>>  Hal Mo <kungu.mjh at taobao.com> from Alibaba Group(with OCA)
>>>>
>>>>  It may take a while before the CR link is publicly accessible.
>>>>
>>>>  In blockOffsetTable.hpp, there is an unexpected data truncation in
>>>> power_to_cards_back(uint i), which may lead to crashing the VM on very
>>>> large GC heaps.
>>>> The problem could be reproduced easily on machines, that have enough
>>>> memory, with:
>>>>  $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>>>
>>>>   The proposed patch fixes this problem, and builds on all OpenJDK
>>>> supported platforms.
>>>>
>>>>  I'd like to thank Bengt Rutisson for the initial review and help
>>>> preparing the CR and Webrev.
>>>>
>>>>  Regards,
>>>> Hal
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120914/8365a37f/attachment.htm>

From roland.westrelin at oracle.com  Fri Sep 14 01:33:45 2012
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Fri, 14 Sep 2012 01:33:45 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7198074: NPG:
	assert(((Metadata*)obj)->is_valid()) failed: obj is valid
Message-ID: <20120914013350.6EC0E47AA5@hg.openjdk.java.net>

Changeset: 7edbe32b9802
Author:    roland
Date:      2012-09-13 22:09 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7edbe32b9802

7198074: NPG: assert(((Metadata*)obj)->is_valid()) failed: obj is valid
Summary: missing test for T_METADATA leads to incorrect register allocation.
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp



From bengt.rutisson at oracle.com  Fri Sep 14 06:39:21 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 14 Sep 2012 08:39:21 +0200
Subject: RFR(XS): 7193946: Move warnings associated with UseMemSetInBOT
	flag
In-Reply-To: <505210A4.2060202@oracle.com>
References: <505210A4.2060202@oracle.com>
Message-ID: <5052D119.1080100@oracle.com>


Hi John,

Thanks for fixing this!

It looks good to me. I'm not really sure about how the work in 
arguments.cpp is supposed to be divided. You added the new check to 
Arguments::parse() but I guess it would be possible to put the code into 
Snippet Arguments::check_vm_args_consistency() instead. It looks to me 
like it might fit better there, but I am fine with leaving it in 
Arguments::parse() as well. Just glad to get rid of the duplicated code.

Thanks,
Bengt


On 2012-09-13 18:58, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review the changes for this CR? They 
> are fairly small. The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7193946/webrev.0/
>
> Summary:
> In the review comments for the fix for 7192128, Bengt suggested to 
> move the individual warnings from concurrentMarkSweepGeneration.cpp 
> and g1Collectedheap.cpp and place a single warning in a common piece 
> of code. These changes address that review comment. The suggested 
> location (vm_version_sparc.cpp) was unsuitable as the routine which 
> would be the natural choice is called twice and the warning would be 
> issued twice. A better place is when we check the other GC flags for 
> consistency in arguments.cpp.
>
> Testing:
> * command line testing
> * GC basher and GCOld on sun4v with and without UseMemSetInBOT set
>
> Thanks,
>
> JohnC



From bengt.rutisson at oracle.com  Fri Sep 14 08:41:12 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 14 Sep 2012 10:41:12 +0200
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output
	comes out of order
In-Reply-To: <50519444.4020403@oracle.com>
References: <50519444.4020403@oracle.com>
Message-ID: <5052EDA8.4010106@oracle.com>


Hi again,

Updated webrev based on merging a similar patch from John Cuthbertson:
http://cr.openjdk.java.net/~brutisso/7198130/webrev.02/

Bengt


On 2012-09-13 10:07, Bengt Rutisson wrote:
>
> Hi all,
>
> Can I have some reviews for this change?
> http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/
>
> This fixes two issues that were introduced by a previous change I made 
> to the G1 logging. Most importantly the time stamp for the GC log 
> entry is now the start of the GC. Secondly, any interleaved logging 
> that is done by other modules will be seen within the GC log entry. 
> This is the way it used to be.
>
> As an example using these switches on the command line "-XX:+UseG1GC 
> -XX:+PrintGCDetails -XX:+PrintReferenceGC" currently produce output like:
>
> 3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: [WeakReference, 
> 207 refs, 0.0000440 secs]3.648: [FinalReference, 14473 refs, 0.0499260 
> secs]3.698: [PhantomReference, 0 refs, 0.0000050 secs]3.698: [JNI Weak 
> Reference, 0.0000120 secs]3.700: [GC pause (G1 Evacuation Pause) 
> (young), 0.0853910 secs]
>    [Parallel Time: 31.9 ms, GC Workers: 8]
>
> But with my suggested fix it will be:
>
> 5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924 
> secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: 
> [FinalReference, 6 refs, 0.0000924 secs]6.032: [PhantomReference, 0 
> refs, 0.0000893 secs]6.032: [JNI Weak Reference, 0 refs, 0.0001699 
> secs], 0.2200814 secs]
>    [Parallel Time: 214.3 ms, GC Workers: 4]
>
>
> This is consistent with the way it looked before my previous change to 
> the G1 logging:
>
> 3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090 
> secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802: 
> [FinalReference, 13020 refs, 0.0462290 secs]3.848: [PhantomReference, 
> 7 refs, 0.0000110 secs]3.848: [JNI Weak Reference, 0.0000150 secs], 
> 0.10515900 secs]
>    [Parallel Time:  52.2 ms]
>
>
> Thanks,
> Bengt



From john.coomes at oracle.com  Fri Sep 14 09:30:06 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 09:30:06 +0000
Subject: hg: hsx/hotspot-gc: Added tag jdk8-b56 for changeset 76844579fa4b
Message-ID: <20120914093006.C658D47ACA@hg.openjdk.java.net>

Changeset: 56264ff5e1d5
Author:    katleman
Date:      2012-09-13 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/56264ff5e1d5

Added tag jdk8-b56 for changeset 76844579fa4b

! .hgtags



From john.coomes at oracle.com  Fri Sep 14 09:30:13 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 09:30:13 +0000
Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b56 for changeset
	bf1bb47414e1
Message-ID: <20120914093027.5E96747ACB@hg.openjdk.java.net>

Changeset: 1500fe4849e8
Author:    katleman
Date:      2012-09-13 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/1500fe4849e8

Added tag jdk8-b56 for changeset bf1bb47414e1

! .hgtags



From john.coomes at oracle.com  Fri Sep 14 09:30:41 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 09:30:41 +0000
Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b56 for changeset f19d63b2119a
Message-ID: <20120914093107.6B1E947ACC@hg.openjdk.java.net>

Changeset: 40bbed6d2173
Author:    katleman
Date:      2012-09-13 13:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/40bbed6d2173

Added tag jdk8-b56 for changeset f19d63b2119a

! .hgtags



From john.coomes at oracle.com  Fri Sep 14 09:31:15 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 09:31:15 +0000
Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b56 for changeset
	7813455ccdb0
Message-ID: <20120914093129.C193847ACD@hg.openjdk.java.net>

Changeset: e099c1eea1ed
Author:    katleman
Date:      2012-09-13 13:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/e099c1eea1ed

Added tag jdk8-b56 for changeset 7813455ccdb0

! .hgtags



From john.coomes at oracle.com  Fri Sep 14 09:35:10 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 09:35:10 +0000
Subject: hg: hsx/hotspot-gc/jdk: 37 new changesets
Message-ID: <20120914094416.61CFD47ACF@hg.openjdk.java.net>

Changeset: b4f7ef73dfe8
Author:    skovatch
Date:      2012-09-05 09:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b4f7ef73dfe8

7187834: [macosx] Usage of private API in macosx 2D implementation causes Apple Store rejection
Reviewed-by: prr, igor

! src/macosx/native/sun/awt/ImageSurfaceData.h
! src/macosx/native/sun/awt/ImageSurfaceData.m
! src/macosx/native/sun/awt/QuartzRenderer.m
! src/macosx/native/sun/awt/QuartzSurfaceData.m

Changeset: 2f0385880af9
Author:    lana
Date:      2012-09-05 13:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2f0385880af9

Merge

- make/sun/beans/Makefile
- src/share/classes/java/lang/annotation/ContainerAnnotation.java
- src/share/classes/java/text/BreakDictionary.java
- src/share/classes/java/text/CollationRules.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
- 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/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
- src/share/classes/sun/text/resources/thai_dict
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
- test/java/lang/invoke/MaxTest.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: e23311e924b1
Author:    alexsch
Date:      2012-08-29 15:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e23311e924b1

7171045: [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/PlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTView.h
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: 9201b1df64e6
Author:    leonidr
Date:      2012-08-29 19:53 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9201b1df64e6

7124375: [macosx] Focus isn't transfered as expected between components
Reviewed-by: art, ant, serb

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java
! src/share/classes/sun/awt/HToolkit.java
! src/share/classes/sun/awt/HeadlessToolkit.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerProvider.java
! src/share/classes/sun/awt/SunToolkit.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XDialogPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java

Changeset: 63d52eb20ce2
Author:    denis
Date:      2012-08-30 01:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/63d52eb20ce2

7192887: java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068)
Reviewed-by: ant, serb

! src/solaris/classes/sun/awt/X11/XWindowPeer.java

Changeset: 973693566c46
Author:    malenkov
Date:      2012-08-31 14:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/973693566c46

7192955: Introspector overide PropertyDescriptor for generic type field defined in super class
Reviewed-by: rupashka

! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/Test7192955.java

Changeset: b291b6d220c7
Author:    malenkov
Date:      2012-08-31 14:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b291b6d220c7

7186794: Setter not found. PropertyDescriptor(PropertyDescriptor,PropertyDescriptor)
Reviewed-by: rupashka

! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/Test7186794.java
! test/java/beans/Introspector/Test7189112.java

Changeset: 0e007aa6f9db
Author:    ant
Date:      2012-08-31 16:31 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0e007aa6f9db

6981400: Tabbing between textfield do not work properly when ALT+TAB
7157015: [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing.
7121442: Regression : Reopen CR 6458497 still reproducible using JDK 7.
Reviewed-by: art, leonidr

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/SequencedEvent.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/SunToolkit.java
+ src/share/classes/sun/awt/TimedWindowEvent.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/windows/native/sun/windows/awt_Window.cpp
+ test/java/awt/Focus/6981400/Test1.java
+ test/java/awt/Focus/6981400/Test2.java
+ test/java/awt/Focus/6981400/Test3.java

Changeset: 2e21ec4be419
Author:    malenkov
Date:      2012-09-04 13:12 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2e21ec4be419

7169395: Exception throws due to the changes in JDK 7 object tranversal and break backward compatibility
Reviewed-by: art

! src/share/classes/java/beans/XMLEncoder.java
+ test/java/beans/XMLEncoder/Test7169395.java

Changeset: 8cd13c3a78e6
Author:    malenkov
Date:      2012-09-04 20:50 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8cd13c3a78e6

7195106: REGRESSION : There is no way to get Icon inf, once Softreference is released
Reviewed-by: rupashka

! src/share/classes/java/beans/Introspector.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
+ test/java/beans/Introspector/Test7195106.java

Changeset: 8ce89b1bc0a1
Author:    serb
Date:      2012-09-05 21:40 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8ce89b1bc0a1

7124523: [macosx] b216: Mising part of applet UI
Reviewed-by: denis, alexsch

! src/share/demo/applets/CardTest/example1.html
! src/share/demo/applets/DitherTest/example1.html

Changeset: 7cbbaf670b57
Author:    lana
Date:      2012-09-05 17:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7cbbaf670b57

Merge

- make/sun/beans/Makefile
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/KeyboardFocusManager.java
- src/share/classes/java/lang/annotation/ContainerAnnotation.java
- src/share/classes/java/text/BreakDictionary.java
- src/share/classes/java/text/CollationRules.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/SunToolkit.java
- 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/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
- src/share/classes/sun/text/resources/thai_dict
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
- test/java/lang/invoke/MaxTest.java

Changeset: 640e8e1eb0d8
Author:    lana
Date:      2012-09-05 20:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/640e8e1eb0d8

Merge


Changeset: c4c69b4d9ace
Author:    weijun
Date:      2012-08-29 11:03 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c4c69b4d9ace

7184815: [macosx] Need to read Kerberos config in files
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/Config.java

Changeset: cf492d1199dc
Author:    dxu
Date:      2012-08-30 12:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cf492d1199dc

7193710: ByteArrayOutputStream Javadoc contains unclosed <code> element
Reviewed-by: dholmes, alanb, ulfzibis

! src/share/classes/java/io/ByteArrayOutputStream.java
! src/share/classes/java/io/InputStreamReader.java

Changeset: 11bfec75d333
Author:    lancea
Date:      2012-08-30 13:38 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/11bfec75d333

7193683: DriverManager Iterator Warning cleanup
Reviewed-by: lancea
Contributed-by: Dan Xu <dan.xu at oracle.com>

! src/share/classes/java/sql/DriverManager.java

Changeset: 0a2565113920
Author:    mullan
Date:      2012-08-30 14:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0a2565113920

6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory
Reviewed-by: mullan, vinnie
Contributed-by: stephen.flores at oracle.com

! make/sun/security/ec/Makefile
! make/sun/security/other/Makefile
! src/share/classes/sun/security/ec/ECKeyFactory.java
! src/share/classes/sun/security/ec/ECParameters.java
! src/share/classes/sun/security/ec/ECPublicKeyImpl.java
! src/share/classes/sun/security/ec/SunECEntries.java
! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! src/share/classes/sun/security/x509/AlgorithmId.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/ec/ReadCertificates.java
! test/sun/security/pkcs11/ec/ReadPKCS12.java
! test/sun/security/pkcs11/ec/TestECDH.java
! test/sun/security/pkcs11/ec/TestECDSA.java

Changeset: 47f8ba39265c
Author:    mullan
Date:      2012-08-30 14:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/47f8ba39265c

Merge


Changeset: 334b6f0c547f
Author:    lana
Date:      2012-08-30 16:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/334b6f0c547f

Merge


Changeset: f9b11772c4b2
Author:    smarks
Date:      2012-08-30 18:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f9b11772c4b2

7195099: update problem list with RMI test failures
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: bdfcc13ddeb4
Author:    jfranck
Date:      2012-08-31 10:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bdfcc13ddeb4

7151010: Add compiler support for repeating annotations
Reviewed-by: darcy, jjg

+ src/share/classes/java/lang/annotation/ContainerFor.java

Changeset: da1436b21bc2
Author:    coffeys
Date:      2012-08-31 12:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/da1436b21bc2

7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure.
Reviewed-by: chegar

! test/com/sun/corba/cachedSocket/7056731.sh

Changeset: 33f8ca2b4ba3
Author:    alanb
Date:      2012-08-31 12:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/33f8ca2b4ba3

7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently
Reviewed-by: chegar

! test/java/nio/file/Files/CopyAndMove.java

Changeset: 3338019fda8a
Author:    sla
Date:      2009-06-19 16:50 +0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3338019fda8a

6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value
Reviewed-by: alanb, dholmes, sla
Contributed-by: Dmytro Sheyko <dmytro_sheyko at hotmail.com>

! src/windows/native/com/sun/management/OperatingSystem_md.c
+ test/com/sun/management/OperatingSystemMXBean/MemoryStatusOverflow.java

Changeset: b7b33a3c9df0
Author:    xuelei
Date:      2012-09-04 02:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b7b33a3c9df0

7195733: TEST_BUG: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java failing
Reviewed-by: chegar, alanb, xuelei
Contributed-by: Eric Wang <yiming.wang at oracle.com>

! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java

Changeset: 7dda50fe8e1c
Author:    jjg
Date:      2012-09-04 12:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7dda50fe8e1c

7195519: OutOfMemoryError in docs build after 7151010
Reviewed-by: darcy

! make/docs/Makefile

Changeset: 5ca450af2a9e
Author:    sla
Date:      2012-09-05 14:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5ca450af2a9e

6963102: Testcase failures sun/tools/jstatd/jstatdExternalRegistry.sh and sun/tools/jstatd/jstatdDefaults.sh
Summary: Make tests more resilient by allowing for more error messages from jps
Reviewed-by: alanb, rbackman, dsamersoff

! test/sun/tools/jstatd/jpsOutput1.awk

Changeset: e129833555f6
Author:    valeriep
Date:      2012-09-04 18:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e129833555f6

7044060: Need to support NSA Suite B Cryptography algorithms
Summary: Add support for DSA parameter generation and OIDs for NSA Suite B algorithms.
Reviewed-by: vinnie

! src/share/classes/com/sun/crypto/provider/AESCipher.java
! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java
+ src/share/classes/java/security/spec/DSAGenParameterSpec.java
! src/share/classes/sun/security/ec/SunECEntries.java
! src/share/classes/sun/security/pkcs11/P11Cipher.java
! src/share/classes/sun/security/pkcs11/SunPKCS11.java
! src/share/classes/sun/security/provider/DSA.java
! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java
! src/share/classes/sun/security/provider/DSAParameterGenerator.java
! src/share/classes/sun/security/provider/ParameterCache.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/classes/sun/security/x509/AlgorithmId.java
! test/com/sun/crypto/provider/KeyAgreement/TestExponentSize.java
+ test/sun/security/pkcs11/ec/TestECDH2.java
+ test/sun/security/pkcs11/ec/TestECDSA2.java
+ test/sun/security/provider/DSA/TestAlgParameterGenerator.java
+ test/sun/security/provider/DSA/TestDSA2.java
! test/sun/security/provider/DSA/TestKeyPairGenerator.java

Changeset: cc5a6c4d600e
Author:    valeriep
Date:      2012-09-05 10:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cc5a6c4d600e

Merge


Changeset: c39370c75d63
Author:    lana
Date:      2012-09-05 11:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c39370c75d63

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/solaris/classes/sun/awt/X11/XTextTransferHelper.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: f1838d040cc7
Author:    ksrini
Date:      2012-09-05 11:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f1838d040cc7

7194005: (launcher) needs to be enhanced for 64-bit jar file handling
Reviewed-by: darcy, sherman

! src/share/bin/jli_util.h
! src/share/bin/manifest_info.h
! src/share/bin/parse_manifest.c
! src/solaris/bin/jexec.c
+ test/tools/launcher/BigJar.java
! test/tools/launcher/TestHelper.java

Changeset: 6b7d23a2ba72
Author:    lana
Date:      2012-09-05 20:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6b7d23a2ba72

Merge


Changeset: 06094fdc1f4d
Author:    lana
Date:      2012-09-10 17:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/06094fdc1f4d

Merge


Changeset: 9c434431d013
Author:    ohair
Date:      2012-09-11 13:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9c434431d013

7197771: Adjust jdk sources to avoid use of implementation defined value of __FILE__
7180608: Sort the order of object files when building shared libraries
Reviewed-by: ohrstrom, erikj, tbell

! make/common/Defs.gmk
! make/common/Demo.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! src/macosx/native/com/apple/laf/ScreenMenu.m
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiOut.c
! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_MidiUtils.c
! src/macosx/native/sun/awt/CSystemColors.m
! src/macosx/native/sun/awt/CTextPipe.m
! src/macosx/native/sun/font/AWTStrike.m
! src/share/back/error_messages.h
! src/share/back/log_messages.h
! src/share/demo/jvmti/hprof/debug_malloc.h
! src/share/demo/jvmti/hprof/hprof_error.h
! src/share/demo/jvmti/hprof/hprof_util.h
! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c
! src/share/instrument/JPLISAssert.h
! src/share/native/sun/awt/debug/debug_assert.h
! src/share/native/sun/awt/debug/debug_mem.c
! src/share/native/sun/awt/debug/debug_trace.h
! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
! src/share/npt/utf.h
! src/share/transport/shmem/shmemBase.h
! src/solaris/instrument/EncodingSupport_md.c
! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiIn.cpp
! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_MidiOut.c
! src/windows/native/sun/java2d/d3d/D3DPipeline.h
! src/windows/native/sun/windows/alloc.h
! src/windows/native/sun/windows/awt_Debug.h
! src/windows/native/sun/windows/awt_Toolkit.h
! src/windows/transport/shmem/shmem_md.c

Changeset: 7ecc3a7cbe36
Author:    ohair
Date:      2012-09-11 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7ecc3a7cbe36

Merge

! make/common/Program.gmk
- make/sun/beans/Makefile
- src/share/classes/java/lang/annotation/ContainerAnnotation.java
- src/share/classes/java/text/BreakDictionary.java
- src/share/classes/java/text/CollationRules.java
- src/share/classes/java/text/DictionaryBasedBreakIterator.java
- src/share/classes/java/text/RuleBasedBreakIterator.java
- 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/text/resources/BreakIteratorInfo_th.java
- src/share/classes/sun/text/resources/BreakIteratorRules_th.java
- src/share/classes/sun/text/resources/CollationData_ar.java
- src/share/classes/sun/text/resources/CollationData_be.java
- src/share/classes/sun/text/resources/CollationData_bg.java
- src/share/classes/sun/text/resources/CollationData_ca.java
- src/share/classes/sun/text/resources/CollationData_cs.java
- src/share/classes/sun/text/resources/CollationData_da.java
- src/share/classes/sun/text/resources/CollationData_de.java
- src/share/classes/sun/text/resources/CollationData_el.java
- src/share/classes/sun/text/resources/CollationData_en.java
- src/share/classes/sun/text/resources/CollationData_es.java
- src/share/classes/sun/text/resources/CollationData_et.java
- src/share/classes/sun/text/resources/CollationData_fi.java
- src/share/classes/sun/text/resources/CollationData_fr.java
- src/share/classes/sun/text/resources/CollationData_hi.java
- src/share/classes/sun/text/resources/CollationData_hr.java
- src/share/classes/sun/text/resources/CollationData_hu.java
- src/share/classes/sun/text/resources/CollationData_is.java
- src/share/classes/sun/text/resources/CollationData_it.java
- src/share/classes/sun/text/resources/CollationData_iw.java
- src/share/classes/sun/text/resources/CollationData_ja.java
- src/share/classes/sun/text/resources/CollationData_ko.java
- src/share/classes/sun/text/resources/CollationData_lt.java
- src/share/classes/sun/text/resources/CollationData_lv.java
- src/share/classes/sun/text/resources/CollationData_mk.java
- src/share/classes/sun/text/resources/CollationData_nl.java
- src/share/classes/sun/text/resources/CollationData_no.java
- src/share/classes/sun/text/resources/CollationData_pl.java
- src/share/classes/sun/text/resources/CollationData_pt.java
- src/share/classes/sun/text/resources/CollationData_ro.java
- src/share/classes/sun/text/resources/CollationData_ru.java
- src/share/classes/sun/text/resources/CollationData_sk.java
- src/share/classes/sun/text/resources/CollationData_sl.java
- src/share/classes/sun/text/resources/CollationData_sq.java
- src/share/classes/sun/text/resources/CollationData_sr.java
- src/share/classes/sun/text/resources/CollationData_sr_Latn.java
- src/share/classes/sun/text/resources/CollationData_sv.java
- src/share/classes/sun/text/resources/CollationData_th.java
- src/share/classes/sun/text/resources/CollationData_tr.java
- src/share/classes/sun/text/resources/CollationData_uk.java
- src/share/classes/sun/text/resources/CollationData_vi.java
- src/share/classes/sun/text/resources/CollationData_zh.java
- src/share/classes/sun/text/resources/CollationData_zh_HK.java
- src/share/classes/sun/text/resources/CollationData_zh_TW.java
- src/share/classes/sun/text/resources/FormatData_ar.java
- src/share/classes/sun/text/resources/FormatData_ar_AE.java
- src/share/classes/sun/text/resources/FormatData_ar_BH.java
- src/share/classes/sun/text/resources/FormatData_ar_DZ.java
- src/share/classes/sun/text/resources/FormatData_ar_EG.java
- src/share/classes/sun/text/resources/FormatData_ar_IQ.java
- src/share/classes/sun/text/resources/FormatData_ar_JO.java
- src/share/classes/sun/text/resources/FormatData_ar_KW.java
- src/share/classes/sun/text/resources/FormatData_ar_LB.java
- src/share/classes/sun/text/resources/FormatData_ar_LY.java
- src/share/classes/sun/text/resources/FormatData_ar_MA.java
- src/share/classes/sun/text/resources/FormatData_ar_OM.java
- src/share/classes/sun/text/resources/FormatData_ar_QA.java
- src/share/classes/sun/text/resources/FormatData_ar_SA.java
- src/share/classes/sun/text/resources/FormatData_ar_SD.java
- src/share/classes/sun/text/resources/FormatData_ar_SY.java
- src/share/classes/sun/text/resources/FormatData_ar_TN.java
- src/share/classes/sun/text/resources/FormatData_ar_YE.java
- src/share/classes/sun/text/resources/FormatData_be.java
- src/share/classes/sun/text/resources/FormatData_be_BY.java
- src/share/classes/sun/text/resources/FormatData_bg.java
- src/share/classes/sun/text/resources/FormatData_bg_BG.java
- src/share/classes/sun/text/resources/FormatData_ca.java
- src/share/classes/sun/text/resources/FormatData_ca_ES.java
- src/share/classes/sun/text/resources/FormatData_cs.java
- src/share/classes/sun/text/resources/FormatData_cs_CZ.java
- src/share/classes/sun/text/resources/FormatData_da.java
- src/share/classes/sun/text/resources/FormatData_da_DK.java
- src/share/classes/sun/text/resources/FormatData_de.java
- src/share/classes/sun/text/resources/FormatData_de_AT.java
- src/share/classes/sun/text/resources/FormatData_de_CH.java
- src/share/classes/sun/text/resources/FormatData_de_DE.java
- src/share/classes/sun/text/resources/FormatData_de_LU.java
- src/share/classes/sun/text/resources/FormatData_el.java
- src/share/classes/sun/text/resources/FormatData_el_CY.java
- src/share/classes/sun/text/resources/FormatData_el_GR.java
- src/share/classes/sun/text/resources/FormatData_en.java
- src/share/classes/sun/text/resources/FormatData_en_AU.java
- src/share/classes/sun/text/resources/FormatData_en_CA.java
- src/share/classes/sun/text/resources/FormatData_en_GB.java
- src/share/classes/sun/text/resources/FormatData_en_IE.java
- src/share/classes/sun/text/resources/FormatData_en_IN.java
- src/share/classes/sun/text/resources/FormatData_en_MT.java
- src/share/classes/sun/text/resources/FormatData_en_NZ.java
- src/share/classes/sun/text/resources/FormatData_en_PH.java
- src/share/classes/sun/text/resources/FormatData_en_SG.java
- src/share/classes/sun/text/resources/FormatData_en_US.java
- src/share/classes/sun/text/resources/FormatData_en_ZA.java
- src/share/classes/sun/text/resources/FormatData_es.java
- src/share/classes/sun/text/resources/FormatData_es_AR.java
- src/share/classes/sun/text/resources/FormatData_es_BO.java
- src/share/classes/sun/text/resources/FormatData_es_CL.java
- src/share/classes/sun/text/resources/FormatData_es_CO.java
- src/share/classes/sun/text/resources/FormatData_es_CR.java
- src/share/classes/sun/text/resources/FormatData_es_DO.java
- src/share/classes/sun/text/resources/FormatData_es_EC.java
- src/share/classes/sun/text/resources/FormatData_es_ES.java
- src/share/classes/sun/text/resources/FormatData_es_GT.java
- src/share/classes/sun/text/resources/FormatData_es_HN.java
- src/share/classes/sun/text/resources/FormatData_es_MX.java
- src/share/classes/sun/text/resources/FormatData_es_NI.java
- src/share/classes/sun/text/resources/FormatData_es_PA.java
- src/share/classes/sun/text/resources/FormatData_es_PE.java
- src/share/classes/sun/text/resources/FormatData_es_PR.java
- src/share/classes/sun/text/resources/FormatData_es_PY.java
- src/share/classes/sun/text/resources/FormatData_es_SV.java
- src/share/classes/sun/text/resources/FormatData_es_US.java
- src/share/classes/sun/text/resources/FormatData_es_UY.java
- src/share/classes/sun/text/resources/FormatData_es_VE.java
- src/share/classes/sun/text/resources/FormatData_et.java
- src/share/classes/sun/text/resources/FormatData_et_EE.java
- src/share/classes/sun/text/resources/FormatData_fi.java
- src/share/classes/sun/text/resources/FormatData_fi_FI.java
- src/share/classes/sun/text/resources/FormatData_fr.java
- src/share/classes/sun/text/resources/FormatData_fr_BE.java
- src/share/classes/sun/text/resources/FormatData_fr_CA.java
- src/share/classes/sun/text/resources/FormatData_fr_CH.java
- src/share/classes/sun/text/resources/FormatData_fr_FR.java
- src/share/classes/sun/text/resources/FormatData_fr_LU.java
- src/share/classes/sun/text/resources/FormatData_ga.java
- src/share/classes/sun/text/resources/FormatData_ga_IE.java
- src/share/classes/sun/text/resources/FormatData_hi_IN.java
- src/share/classes/sun/text/resources/FormatData_hr.java
- src/share/classes/sun/text/resources/FormatData_hr_HR.java
- src/share/classes/sun/text/resources/FormatData_hu.java
- src/share/classes/sun/text/resources/FormatData_hu_HU.java
- src/share/classes/sun/text/resources/FormatData_in.java
- src/share/classes/sun/text/resources/FormatData_in_ID.java
- src/share/classes/sun/text/resources/FormatData_is.java
- src/share/classes/sun/text/resources/FormatData_is_IS.java
- src/share/classes/sun/text/resources/FormatData_it.java
- src/share/classes/sun/text/resources/FormatData_it_CH.java
- src/share/classes/sun/text/resources/FormatData_it_IT.java
- src/share/classes/sun/text/resources/FormatData_iw.java
- src/share/classes/sun/text/resources/FormatData_iw_IL.java
- src/share/classes/sun/text/resources/FormatData_ja.java
- src/share/classes/sun/text/resources/FormatData_ja_JP.java
- src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java
- src/share/classes/sun/text/resources/FormatData_ko.java
- src/share/classes/sun/text/resources/FormatData_ko_KR.java
- src/share/classes/sun/text/resources/FormatData_lt.java
- src/share/classes/sun/text/resources/FormatData_lt_LT.java
- src/share/classes/sun/text/resources/FormatData_lv.java
- src/share/classes/sun/text/resources/FormatData_lv_LV.java
- src/share/classes/sun/text/resources/FormatData_mk.java
- src/share/classes/sun/text/resources/FormatData_mk_MK.java
- src/share/classes/sun/text/resources/FormatData_ms.java
- src/share/classes/sun/text/resources/FormatData_ms_MY.java
- src/share/classes/sun/text/resources/FormatData_mt.java
- src/share/classes/sun/text/resources/FormatData_mt_MT.java
- src/share/classes/sun/text/resources/FormatData_nl.java
- src/share/classes/sun/text/resources/FormatData_nl_BE.java
- src/share/classes/sun/text/resources/FormatData_nl_NL.java
- src/share/classes/sun/text/resources/FormatData_no.java
- src/share/classes/sun/text/resources/FormatData_no_NO.java
- src/share/classes/sun/text/resources/FormatData_no_NO_NY.java
- src/share/classes/sun/text/resources/FormatData_pl.java
- src/share/classes/sun/text/resources/FormatData_pl_PL.java
- src/share/classes/sun/text/resources/FormatData_pt.java
- src/share/classes/sun/text/resources/FormatData_pt_BR.java
- src/share/classes/sun/text/resources/FormatData_pt_PT.java
- src/share/classes/sun/text/resources/FormatData_ro.java
- src/share/classes/sun/text/resources/FormatData_ro_RO.java
- src/share/classes/sun/text/resources/FormatData_ru.java
- src/share/classes/sun/text/resources/FormatData_ru_RU.java
- src/share/classes/sun/text/resources/FormatData_sk.java
- src/share/classes/sun/text/resources/FormatData_sk_SK.java
- src/share/classes/sun/text/resources/FormatData_sl.java
- src/share/classes/sun/text/resources/FormatData_sl_SI.java
- src/share/classes/sun/text/resources/FormatData_sq.java
- src/share/classes/sun/text/resources/FormatData_sq_AL.java
- src/share/classes/sun/text/resources/FormatData_sr.java
- src/share/classes/sun/text/resources/FormatData_sr_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_CS.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java
- src/share/classes/sun/text/resources/FormatData_sr_ME.java
- src/share/classes/sun/text/resources/FormatData_sr_RS.java
- src/share/classes/sun/text/resources/FormatData_sv.java
- src/share/classes/sun/text/resources/FormatData_sv_SE.java
- src/share/classes/sun/text/resources/FormatData_th.java
- src/share/classes/sun/text/resources/FormatData_th_TH.java
- src/share/classes/sun/text/resources/FormatData_th_TH_TH.java
- src/share/classes/sun/text/resources/FormatData_tr.java
- src/share/classes/sun/text/resources/FormatData_tr_TR.java
- src/share/classes/sun/text/resources/FormatData_uk.java
- src/share/classes/sun/text/resources/FormatData_uk_UA.java
- src/share/classes/sun/text/resources/FormatData_vi.java
- src/share/classes/sun/text/resources/FormatData_vi_VN.java
- src/share/classes/sun/text/resources/FormatData_zh.java
- src/share/classes/sun/text/resources/FormatData_zh_CN.java
- src/share/classes/sun/text/resources/FormatData_zh_HK.java
- src/share/classes/sun/text/resources/FormatData_zh_SG.java
- src/share/classes/sun/text/resources/FormatData_zh_TW.java
- src/share/classes/sun/text/resources/thai_dict
- src/share/classes/sun/util/EmptyListResourceBundle.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
- src/share/classes/sun/util/LocaleServiceProviderPool.java
- src/share/classes/sun/util/TimeZoneNameUtility.java
- src/share/classes/sun/util/resources/CalendarData_ar.properties
- src/share/classes/sun/util/resources/CalendarData_be.properties
- src/share/classes/sun/util/resources/CalendarData_bg.properties
- src/share/classes/sun/util/resources/CalendarData_ca.properties
- src/share/classes/sun/util/resources/CalendarData_cs.properties
- src/share/classes/sun/util/resources/CalendarData_da.properties
- src/share/classes/sun/util/resources/CalendarData_de.properties
- src/share/classes/sun/util/resources/CalendarData_el.properties
- src/share/classes/sun/util/resources/CalendarData_el_CY.properties
- src/share/classes/sun/util/resources/CalendarData_en.properties
- src/share/classes/sun/util/resources/CalendarData_en_GB.properties
- src/share/classes/sun/util/resources/CalendarData_en_IE.properties
- src/share/classes/sun/util/resources/CalendarData_en_MT.properties
- src/share/classes/sun/util/resources/CalendarData_es.properties
- src/share/classes/sun/util/resources/CalendarData_es_ES.properties
- src/share/classes/sun/util/resources/CalendarData_es_US.properties
- src/share/classes/sun/util/resources/CalendarData_et.properties
- src/share/classes/sun/util/resources/CalendarData_fi.properties
- src/share/classes/sun/util/resources/CalendarData_fr.properties
- src/share/classes/sun/util/resources/CalendarData_fr_CA.properties
- src/share/classes/sun/util/resources/CalendarData_hi.properties
- src/share/classes/sun/util/resources/CalendarData_hr.properties
- src/share/classes/sun/util/resources/CalendarData_hu.properties
- src/share/classes/sun/util/resources/CalendarData_in_ID.properties
- src/share/classes/sun/util/resources/CalendarData_is.properties
- src/share/classes/sun/util/resources/CalendarData_it.properties
- src/share/classes/sun/util/resources/CalendarData_iw.properties
- src/share/classes/sun/util/resources/CalendarData_ja.properties
- src/share/classes/sun/util/resources/CalendarData_ko.properties
- src/share/classes/sun/util/resources/CalendarData_lt.properties
- src/share/classes/sun/util/resources/CalendarData_lv.properties
- src/share/classes/sun/util/resources/CalendarData_mk.properties
- src/share/classes/sun/util/resources/CalendarData_ms_MY.properties
- src/share/classes/sun/util/resources/CalendarData_mt.properties
- src/share/classes/sun/util/resources/CalendarData_mt_MT.properties
- src/share/classes/sun/util/resources/CalendarData_nl.properties
- src/share/classes/sun/util/resources/CalendarData_no.properties
- src/share/classes/sun/util/resources/CalendarData_pl.properties
- src/share/classes/sun/util/resources/CalendarData_pt.properties
- src/share/classes/sun/util/resources/CalendarData_pt_PT.properties
- src/share/classes/sun/util/resources/CalendarData_ro.properties
- src/share/classes/sun/util/resources/CalendarData_ru.properties
- src/share/classes/sun/util/resources/CalendarData_sk.properties
- src/share/classes/sun/util/resources/CalendarData_sl.properties
- src/share/classes/sun/util/resources/CalendarData_sq.properties
- src/share/classes/sun/util/resources/CalendarData_sr.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CalendarData_sv.properties
- src/share/classes/sun/util/resources/CalendarData_th.properties
- src/share/classes/sun/util/resources/CalendarData_tr.properties
- src/share/classes/sun/util/resources/CalendarData_uk.properties
- src/share/classes/sun/util/resources/CalendarData_vi.properties
- src/share/classes/sun/util/resources/CalendarData_zh.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties
- src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties
- src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties
- src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties
- src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties
- src/share/classes/sun/util/resources/CurrencyNames_de.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties
- src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_US.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties
- src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties
- src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties
- src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties
- src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties
- src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties
- src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties
- src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties
- src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties
- src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties
- src/share/classes/sun/util/resources/CurrencyNames_it.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties
- src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties
- src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja.properties
- src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko.properties
- src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties
- src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties
- src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties
- src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties
- src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties
- src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties
- src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties
- src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties
- src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties
- src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties
- src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties
- src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties
- src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties
- src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties
- src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties
- src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv.properties
- src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties
- src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties
- src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties
- src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties
- src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties
- src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java
- src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties
- src/share/classes/sun/util/resources/LocaleNames_ar.properties
- src/share/classes/sun/util/resources/LocaleNames_be.properties
- src/share/classes/sun/util/resources/LocaleNames_bg.properties
- src/share/classes/sun/util/resources/LocaleNames_ca.properties
- src/share/classes/sun/util/resources/LocaleNames_cs.properties
- src/share/classes/sun/util/resources/LocaleNames_da.properties
- src/share/classes/sun/util/resources/LocaleNames_de.properties
- src/share/classes/sun/util/resources/LocaleNames_el.properties
- src/share/classes/sun/util/resources/LocaleNames_el_CY.properties
- src/share/classes/sun/util/resources/LocaleNames_en.properties
- src/share/classes/sun/util/resources/LocaleNames_en_MT.properties
- src/share/classes/sun/util/resources/LocaleNames_en_PH.properties
- src/share/classes/sun/util/resources/LocaleNames_en_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_es.properties
- src/share/classes/sun/util/resources/LocaleNames_es_US.properties
- src/share/classes/sun/util/resources/LocaleNames_et.properties
- src/share/classes/sun/util/resources/LocaleNames_fi.properties
- src/share/classes/sun/util/resources/LocaleNames_fr.properties
- src/share/classes/sun/util/resources/LocaleNames_ga.properties
- src/share/classes/sun/util/resources/LocaleNames_hi.properties
- src/share/classes/sun/util/resources/LocaleNames_hr.properties
- src/share/classes/sun/util/resources/LocaleNames_hu.properties
- src/share/classes/sun/util/resources/LocaleNames_in.properties
- src/share/classes/sun/util/resources/LocaleNames_is.properties
- src/share/classes/sun/util/resources/LocaleNames_it.properties
- src/share/classes/sun/util/resources/LocaleNames_iw.properties
- src/share/classes/sun/util/resources/LocaleNames_ja.properties
- src/share/classes/sun/util/resources/LocaleNames_ko.properties
- src/share/classes/sun/util/resources/LocaleNames_lt.properties
- src/share/classes/sun/util/resources/LocaleNames_lv.properties
- src/share/classes/sun/util/resources/LocaleNames_mk.properties
- src/share/classes/sun/util/resources/LocaleNames_ms.properties
- src/share/classes/sun/util/resources/LocaleNames_mt.properties
- src/share/classes/sun/util/resources/LocaleNames_nl.properties
- src/share/classes/sun/util/resources/LocaleNames_no.properties
- src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties
- src/share/classes/sun/util/resources/LocaleNames_pl.properties
- src/share/classes/sun/util/resources/LocaleNames_pt.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties
- src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties
- src/share/classes/sun/util/resources/LocaleNames_ro.properties
- src/share/classes/sun/util/resources/LocaleNames_ru.properties
- src/share/classes/sun/util/resources/LocaleNames_sk.properties
- src/share/classes/sun/util/resources/LocaleNames_sl.properties
- src/share/classes/sun/util/resources/LocaleNames_sq.properties
- src/share/classes/sun/util/resources/LocaleNames_sr.properties
- src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties
- src/share/classes/sun/util/resources/LocaleNames_sv.properties
- src/share/classes/sun/util/resources/LocaleNames_th.properties
- src/share/classes/sun/util/resources/LocaleNames_tr.properties
- src/share/classes/sun/util/resources/LocaleNames_uk.properties
- src/share/classes/sun/util/resources/LocaleNames_vi.properties
- src/share/classes/sun/util/resources/LocaleNames_zh.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_HK.java
- src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties
- src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties
- src/share/classes/sun/util/resources/TimeZoneNames_de.java
- src/share/classes/sun/util/resources/TimeZoneNames_en.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java
- src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java
- src/share/classes/sun/util/resources/TimeZoneNames_es.java
- src/share/classes/sun/util/resources/TimeZoneNames_fr.java
- src/share/classes/sun/util/resources/TimeZoneNames_hi.java
- src/share/classes/sun/util/resources/TimeZoneNames_it.java
- src/share/classes/sun/util/resources/TimeZoneNames_ja.java
- src/share/classes/sun/util/resources/TimeZoneNames_ko.java
- src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java
- src/share/classes/sun/util/resources/TimeZoneNames_sv.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java
- src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java
- src/solaris/classes/sun/awt/X11/XTextTransferHelper.java
- test/java/lang/invoke/MaxTest.java
- test/javax/swing/JColorChooser/Test4380468.html
- test/javax/swing/JColorChooser/Test4380468.java

Changeset: 2e9eeef2909b
Author:    katleman
Date:      2012-09-12 15:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2e9eeef2909b

Merge


Changeset: 472145010fcc
Author:    katleman
Date:      2012-09-13 13:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/472145010fcc

Added tag jdk8-b56 for changeset 2e9eeef2909b

! .hgtags



From john.coomes at oracle.com  Fri Sep 14 09:46:28 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 09:46:28 +0000
Subject: hg: hsx/hotspot-gc/langtools: 5 new changesets
Message-ID: <20120914094705.D4CD147AD0@hg.openjdk.java.net>

Changeset: 873ddd9f4900
Author:    jfranck
Date:      2012-08-31 10:37 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/873ddd9f4900

7151010: Add compiler support for repeating annotations
Reviewed-by: jjg, mcimadamore

+ src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! 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/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.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/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Flow.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/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
+ test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java
+ test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java
+ test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java
+ test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java
+ test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java
+ test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java
+ test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java
+ test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java
+ test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java
+ test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java
+ test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java
+ test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java
+ test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java
+ test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java
+ test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java
+ test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java
+ test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java
+ test/tools/javac/diags/examples/ContainedByInheritedMismatch.java
+ test/tools/javac/diags/examples/ContainedByNoValue.java
+ test/tools/javac/diags/examples/ContainedByNonDefault.java
+ test/tools/javac/diags/examples/ContainedByRetentionMismatch.java
+ test/tools/javac/diags/examples/ContainedByTargetMismatch.java
+ test/tools/javac/diags/examples/ContainedByWrongValueType.java
! test/tools/javac/diags/examples/DuplicateAnnotation.java
+ test/tools/javac/diags/examples/DuplicateAnnotationJava8.java
+ test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java
+ test/tools/javac/diags/examples/WrongContainedBy.java
+ test/tools/javac/diags/examples/WrongContainerFor.java

Changeset: 3673c811be1c
Author:    jjh
Date:      2012-09-05 08:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3673c811be1c

7185778: javah error "Not a valid class name" on class names with dollar signs
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javah/JavahTask.java
+ test/tools/javah/T7185778.java

Changeset: 3f36e22c8c39
Author:    lana
Date:      2012-09-05 12:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3f36e22c8c39

Merge


Changeset: 363e9198b9de
Author:    lana
Date:      2012-09-10 17:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/363e9198b9de

Merge


Changeset: 27ba086a9b60
Author:    katleman
Date:      2012-09-13 13:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/27ba086a9b60

Added tag jdk8-b56 for changeset 363e9198b9de

! .hgtags



From bengt.rutisson at oracle.com  Fri Sep 14 13:06:02 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 14 Sep 2012 15:06:02 +0200
Subject: RFR(S): 7016955: G1: remove the is_zeroed parameter from the
	HeapRegion constructor
In-Reply-To: <50522863.7090506@oracle.com>
References: <50521300.4030306@oracle.com> <50522863.7090506@oracle.com>
Message-ID: <50532BBA.1090300@oracle.com>


Hi all,

This is really convoluted code but I think the change looks good. 
(Thanks Stefan for helping me untangle the control flow.)

There are two comments heapRegion.cpp that I think should be removed now:

  504   // Note that initialize() will set the start of the unmarked 
area of the
  505   // region.

  980   // false ==> we'll do the clearing if there's clearing to be done.

Thanks,
Bengt

On 2012-09-13 20:39, Jon Masamitsu wrote:
> Basically, it's deleting the G1OffsetTableContigSpace
> version of initialize(), using the ContiguousSpace initialize()
> and doing the little bit of extra work the constructor.
> And, of course, dumping the is_zeroed parameter.
>
> Looks good.
>
>
> On 09/13/12 10:08, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a volunteer to review the changes, which were contributed 
>> by Brandon Mitchell at Twitter, for this CR? The webrev can be found 
>> at: http://cr.openjdk.java.net/~johnc/7016955/webrev.0/
>>
>> Summary:
>> When Tony removed the zero filling thread, the is_zeroed parameter in 
>> the HeapRegion constructor became unused. These changes remove that 
>> unused parameter and clean up the HeapRegion initialization code.
>>
>> Testing:
>> SPECjvm98 and SPECjbb2005 on Linux (Brandon); GC test suite on 
>> solaris (x86 and sparc) and jprt (JohnC)
>>
>> Thanks,
>>
>> JohnC



From john.cuthbertson at oracle.com  Fri Sep 14 16:31:27 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 14 Sep 2012 09:31:27 -0700
Subject: RFR(XS): 7193946: Move warnings associated with UseMemSetInBOT
	flag
In-Reply-To: <5052D119.1080100@oracle.com>
References: <505210A4.2060202@oracle.com> <5052D119.1080100@oracle.com>
Message-ID: <50535BDF.5000309@oracle.com>

Hi Bengt,

Thanks for the review. I too went back and forth about where to put the 
check. I'm not sure there is a clear division but I'll see which 
location looks a bitter 'fit'.

JohnC

On 09/13/12 23:39, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for fixing this!
>
> It looks good to me. I'm not really sure about how the work in 
> arguments.cpp is supposed to be divided. You added the new check to 
> Arguments::parse() but I guess it would be possible to put the code 
> into Snippet Arguments::check_vm_args_consistency() instead. It looks 
> to me like it might fit better there, but I am fine with leaving it in 
> Arguments::parse() as well. Just glad to get rid of the duplicated code.
>
> Thanks,
> Bengt
>
>
> On 2012-09-13 18:58, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers review the changes for this CR? 
>> They are fairly small. The webrev can be found at: 
>> http://cr.openjdk.java.net/~johnc/7193946/webrev.0/
>>
>> Summary:
>> In the review comments for the fix for 7192128, Bengt suggested to 
>> move the individual warnings from concurrentMarkSweepGeneration.cpp 
>> and g1Collectedheap.cpp and place a single warning in a common piece 
>> of code. These changes address that review comment. The suggested 
>> location (vm_version_sparc.cpp) was unsuitable as the routine which 
>> would be the natural choice is called twice and the warning would be 
>> issued twice. A better place is when we check the other GC flags for 
>> consistency in arguments.cpp.
>>
>> Testing:
>> * command line testing
>> * GC basher and GCOld on sun4v with and without UseMemSetInBOT set
>>
>> Thanks,
>>
>> JohnC
>



From ysr1729 at gmail.com  Fri Sep 14 20:45:48 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Fri, 14 Sep 2012 21:45:48 +0100
Subject: RFR(XS): 7193946: Move warnings associated with UseMemSetInBOT
	flag
In-Reply-To: <50535BDF.5000309@oracle.com>
References: <505210A4.2060202@oracle.com> <5052D119.1080100@oracle.com>
	<50535BDF.5000309@oracle.com>
Message-ID: <CABzyjykLSQ3hACYKioErW99C0n29qdMjSH0uXh37MW329=+Riw@mail.gmail.com>

Looks good to me too; and I'd agree with Bengt that the code really belongs
under "consistency checking" rather than under "parsing".

-- ramki

On Fri, Sep 14, 2012 at 5:31 PM, John Cuthbertson <
john.cuthbertson at oracle.com> wrote:

> Hi Bengt,
>
> Thanks for the review. I too went back and forth about where to put the
> check. I'm not sure there is a clear division but I'll see which location
> looks a bitter 'fit'.
>
> JohnC
>
>
> On 09/13/12 23:39, Bengt Rutisson wrote:
>
>>
>> Hi John,
>>
>> Thanks for fixing this!
>>
>> It looks good to me. I'm not really sure about how the work in
>> arguments.cpp is supposed to be divided. You added the new check to
>> Arguments::parse() but I guess it would be possible to put the code into
>> Snippet Arguments::check_vm_args_**consistency() instead. It looks to me
>> like it might fit better there, but I am fine with leaving it in
>> Arguments::parse() as well. Just glad to get rid of the duplicated code.
>>
>> Thanks,
>> Bengt
>>
>>
>> On 2012-09-13 18:58, John Cuthbertson wrote:
>>
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers review the changes for this CR? They
>>> are fairly small. The webrev can be found at:
>>> http://cr.openjdk.java.net/~**johnc/7193946/webrev.0/<http://cr.openjdk.java.net/%7Ejohnc/7193946/webrev.0/>
>>>
>>> Summary:
>>> In the review comments for the fix for 7192128, Bengt suggested to move
>>> the individual warnings from concurrentMarkSweepGeneration.**cpp and
>>> g1Collectedheap.cpp and place a single warning in a common piece of code.
>>> These changes address that review comment. The suggested location
>>> (vm_version_sparc.cpp) was unsuitable as the routine which would be the
>>> natural choice is called twice and the warning would be issued twice. A
>>> better place is when we check the other GC flags for consistency in
>>> arguments.cpp.
>>>
>>> Testing:
>>> * command line testing
>>> * GC basher and GCOld on sun4v with and without UseMemSetInBOT set
>>>
>>> Thanks,
>>>
>>> JohnC
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120914/cb168507/attachment.htm>

From john.cuthbertson at oracle.com  Fri Sep 14 21:05:36 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 14 Sep 2012 14:05:36 -0700
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output
	comes out of order
In-Reply-To: <5052EDA8.4010106@oracle.com>
References: <50519444.4020403@oracle.com> <5052EDA8.4010106@oracle.com>
Message-ID: <50539C20.3050404@oracle.com>

Hi Bengt,

This looks good. One nit:

Instead of:

3671   if (PrintGCTimeStamps) {
3672     gclog_or_tty->stamp();
3673     gclog_or_tty->print(": ");
3674   }

How about:

3672     gclog_or_tty->stamp(PrintGCTimeStamps);


Regards,

JohnC

On 09/14/12 01:41, Bengt Rutisson wrote:
>
> Hi again,
>
> Updated webrev based on merging a similar patch from John Cuthbertson:
> http://cr.openjdk.java.net/~brutisso/7198130/webrev.02/
>
> Bengt
>
>
> On 2012-09-13 10:07, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Can I have some reviews for this change?
>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/
>>
>> This fixes two issues that were introduced by a previous change I 
>> made to the G1 logging. Most importantly the time stamp for the GC 
>> log entry is now the start of the GC. Secondly, any interleaved 
>> logging that is done by other modules will be seen within the GC log 
>> entry. This is the way it used to be.
>>
>> As an example using these switches on the command line "-XX:+UseG1GC 
>> -XX:+PrintGCDetails -XX:+PrintReferenceGC" currently produce output 
>> like:
>>
>> 3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: [WeakReference, 
>> 207 refs, 0.0000440 secs]3.648: [FinalReference, 14473 refs, 
>> 0.0499260 secs]3.698: [PhantomReference, 0 refs, 0.0000050 
>> secs]3.698: [JNI Weak Reference, 0.0000120 secs]3.700: [GC pause (G1 
>> Evacuation Pause) (young), 0.0853910 secs]
>>    [Parallel Time: 31.9 ms, GC Workers: 8]
>>
>> But with my suggested fix it will be:
>>
>> 5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924 
>> secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: 
>> [FinalReference, 6 refs, 0.0000924 secs]6.032: [PhantomReference, 0 
>> refs, 0.0000893 secs]6.032: [JNI Weak Reference, 0 refs, 0.0001699 
>> secs], 0.2200814 secs]
>>    [Parallel Time: 214.3 ms, GC Workers: 4]
>>
>>
>> This is consistent with the way it looked before my previous change 
>> to the G1 logging:
>>
>> 3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090 
>> secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802: 
>> [FinalReference, 13020 refs, 0.0462290 secs]3.848: [PhantomReference, 
>> 7 refs, 0.0000110 secs]3.848: [JNI Weak Reference, 0.0000150 secs], 
>> 0.10515900 secs]
>>    [Parallel Time:  52.2 ms]
>>
>>
>> Thanks,
>> Bengt
>



From zhengyu.gu at oracle.com  Fri Sep 14 21:50:27 2012
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Fri, 14 Sep 2012 21:50:27 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7198529: NPG: assert with NMT code in
	Thread destructor
Message-ID: <20120914215031.CC33B47AFC@hg.openjdk.java.net>

Changeset: 6dfc6a541338
Author:    zgu
Date:      2012-09-14 12:55 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6dfc6a541338

7198529: NPG: assert with NMT code in Thread destructor
Summary: Thread stack's base address can be NULL if it is not started or exited before recording the base
Reviewed-by: kvn, fparain

! src/share/vm/runtime/thread.cpp



From john.coomes at oracle.com  Fri Sep 14 23:08:56 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Sep 2012 23:08:56 +0000
Subject: hg: hsx/hotspot-gc/jdk: 2 new changesets
Message-ID: <20120914230939.CEC4A47AFD@hg.openjdk.java.net>

Changeset: 1e827cc26cf6
Author:    jcoomes
Date:      2012-09-14 15:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1e827cc26cf6

7198162: exclude test MemoryMXBean/LowMemoryTest2.sh
Reviewed-by: alanb, dsamersoff, sspitsyn

! test/ProblemList.txt

Changeset: 058d66fa372b
Author:    jcoomes
Date:      2012-09-14 16:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/058d66fa372b

7198676: NPG: exclude MemoryMXBean tests which assume a perm gen
Reviewed-by: dcubed

! test/ProblemList.txt



From john.coomes at oracle.com  Sat Sep 15 09:18:56 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Sat, 15 Sep 2012 09:18:56 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 5 new changesets
Message-ID: <20120915092008.4C01A47B0D@hg.openjdk.java.net>

Changeset: 6124ff421829
Author:    katleman
Date:      2012-09-06 17:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6124ff421829

Added tag jdk8-b55 for changeset af0c8a080851

! .hgtags

Changeset: d70102c4cb73
Author:    katleman
Date:      2012-09-13 13:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d70102c4cb73

Added tag jdk8-b56 for changeset 6124ff421829

! .hgtags

Changeset: 9b076bc3ab67
Author:    amurillo
Date:      2012-09-14 21:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9b076bc3ab67

Merge

- agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java
- agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java
- make/solaris/makefiles/reorder_COMPILER1_amd64
- make/solaris/makefiles/reorder_COMPILER1_i486
- make/solaris/makefiles/reorder_COMPILER1_sparc
- make/solaris/makefiles/reorder_COMPILER1_sparcv9
- make/solaris/makefiles/reorder_COMPILER2_amd64
- make/solaris/makefiles/reorder_COMPILER2_i486
- make/solaris/makefiles/reorder_COMPILER2_sparc
- make/solaris/makefiles/reorder_COMPILER2_sparcv9
- make/solaris/makefiles/reorder_CORE_i486
- make/solaris/makefiles/reorder_CORE_sparc
- make/solaris/makefiles/reorder_CORE_sparcv9
- make/solaris/makefiles/reorder_TIERED_amd64
- make/solaris/makefiles/reorder_TIERED_i486
- make/solaris/makefiles/reorder_TIERED_sparc
- make/solaris/makefiles/reorder_TIERED_sparcv9
- make/solaris/reorder.sh
- src/cpu/sparc/vm/dump_sparc.cpp
- src/cpu/x86/vm/dump_x86_32.cpp
- src/cpu/x86/vm/dump_x86_64.cpp
- src/cpu/zero/vm/dump_zero.cpp
- src/share/vm/ci/ciArrayKlassKlass.hpp
- src/share/vm/ci/ciCPCache.cpp
- src/share/vm/ci/ciCPCache.hpp
- src/share/vm/ci/ciInstanceKlassKlass.cpp
- src/share/vm/ci/ciInstanceKlassKlass.hpp
- src/share/vm/ci/ciKlassKlass.cpp
- src/share/vm/ci/ciKlassKlass.hpp
- src/share/vm/ci/ciMethodKlass.cpp
- src/share/vm/ci/ciMethodKlass.hpp
- src/share/vm/ci/ciObjArrayKlassKlass.cpp
- src/share/vm/ci/ciObjArrayKlassKlass.hpp
- src/share/vm/ci/ciTypeArrayKlassKlass.cpp
- src/share/vm/ci/ciTypeArrayKlassKlass.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp
- src/share/vm/memory/classify.cpp
- src/share/vm/memory/classify.hpp
- src/share/vm/memory/compactPermGen.hpp
- src/share/vm/memory/compactingPermGenGen.cpp
- src/share/vm/memory/compactingPermGenGen.hpp
- src/share/vm/memory/dump.cpp
- src/share/vm/memory/permGen.cpp
- src/share/vm/memory/permGen.hpp
- src/share/vm/memory/restore.cpp
- src/share/vm/memory/serialize.cpp
- src/share/vm/oops/arrayKlassKlass.cpp
- src/share/vm/oops/arrayKlassKlass.hpp
- src/share/vm/oops/compiledICHolderKlass.cpp
- src/share/vm/oops/compiledICHolderKlass.hpp
- src/share/vm/oops/compiledICHolderOop.cpp
- src/share/vm/oops/compiledICHolderOop.hpp
- src/share/vm/oops/constMethodKlass.cpp
- src/share/vm/oops/constMethodKlass.hpp
- src/share/vm/oops/constMethodOop.cpp
- src/share/vm/oops/constMethodOop.hpp
- src/share/vm/oops/constantPoolKlass.cpp
- src/share/vm/oops/constantPoolKlass.hpp
- src/share/vm/oops/constantPoolOop.cpp
- src/share/vm/oops/constantPoolOop.hpp
- src/share/vm/oops/cpCacheKlass.cpp
- src/share/vm/oops/cpCacheKlass.hpp
- src/share/vm/oops/cpCacheOop.cpp
- src/share/vm/oops/cpCacheOop.hpp
- src/share/vm/oops/instanceKlassKlass.cpp
- src/share/vm/oops/instanceKlassKlass.hpp
- src/share/vm/oops/klassKlass.cpp
- src/share/vm/oops/klassKlass.hpp
- src/share/vm/oops/klassOop.cpp
- src/share/vm/oops/klassOop.hpp
- src/share/vm/oops/methodDataKlass.cpp
- src/share/vm/oops/methodDataKlass.hpp
- src/share/vm/oops/methodDataOop.cpp
- src/share/vm/oops/methodDataOop.hpp
- src/share/vm/oops/methodKlass.cpp
- src/share/vm/oops/methodKlass.hpp
- src/share/vm/oops/methodOop.cpp
- src/share/vm/oops/methodOop.hpp
- src/share/vm/oops/objArrayKlassKlass.cpp
- src/share/vm/oops/objArrayKlassKlass.hpp
- src/share/vm/oops/typeArrayKlassKlass.cpp
- src/share/vm/oops/typeArrayKlassKlass.hpp

Changeset: 80e4129f0e28
Author:    amurillo
Date:      2012-09-14 21:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/80e4129f0e28

Added tag hs25-b01 for changeset 9b076bc3ab67

! .hgtags

Changeset: a6fe94b9759f
Author:    amurillo
Date:      2012-09-14 22:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a6fe94b9759f

7198641: new hotspot build - hs25-b02
Reviewed-by: jcoomes

! make/hotspot_version



From jon.masamitsu at oracle.com  Mon Sep 17 03:09:10 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Sun, 16 Sep 2012 20:09:10 -0700
Subject: Request for review - 7197557
Message-ID: <50569456.10705@oracle.com>

NPG: nsk/sysdict/vm/stress/chain/chain004 hangs intermittently

The code that was doing a GC to find dead class loaders so that metadata
could be freed does not correctly account for GC_locker activity (i.e., use
of JNI critical sections which stall GC).  Added code to recognize if
a GC_locker is active and expand the Metaspace and allocate out of the
expanded area.  If the expansion cannot provide metadata, wait for
the GC_locker to inactivate so that a GC can be done.

http://cr.openjdk.java.net/~jmasa/7197557/webrev.00/

Note that there are three places in the different GC's that need to
account for GC_locker activity.  I am investigating whether this
code can be unified.


From bengt.rutisson at oracle.com  Mon Sep 17 08:40:01 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 17 Sep 2012 10:40:01 +0200
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output
	comes out of order
In-Reply-To: <50539C20.3050404@oracle.com>
References: <50519444.4020403@oracle.com> <5052EDA8.4010106@oracle.com>
	<50539C20.3050404@oracle.com>
Message-ID: <5056E1E1.5090609@oracle.com>


Hi John,

Thanks for the review. Good point about using 
"gclog_or_tty->stamp(PrintGCTimeStamps)".  I found the same pattern in a 
few more places so I updated those as well. Here is an updated webrev:

http://cr.openjdk.java.net/~brutisso/7198130/webrev.03/

I still need one more review. Any takers?

Bengt


On 2012-09-14 23:05, John Cuthbertson wrote:
> Hi Bengt,
>
> This looks good. One nit:
>
> Instead of:
>
> 3671   if (PrintGCTimeStamps) {
> 3672     gclog_or_tty->stamp();
> 3673     gclog_or_tty->print(": ");
> 3674   }
>
> How about:
>
> 3672     gclog_or_tty->stamp(PrintGCTimeStamps);
>
>
> Regards,
>
> JohnC
>
> On 09/14/12 01:41, Bengt Rutisson wrote:
>>
>> Hi again,
>>
>> Updated webrev based on merging a similar patch from John Cuthbertson:
>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.02/
>>
>> Bengt
>>
>>
>> On 2012-09-13 10:07, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Can I have some reviews for this change?
>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/
>>>
>>> This fixes two issues that were introduced by a previous change I 
>>> made to the G1 logging. Most importantly the time stamp for the GC 
>>> log entry is now the start of the GC. Secondly, any interleaved 
>>> logging that is done by other modules will be seen within the GC log 
>>> entry. This is the way it used to be.
>>>
>>> As an example using these switches on the command line "-XX:+UseG1GC 
>>> -XX:+PrintGCDetails -XX:+PrintReferenceGC" currently produce output 
>>> like:
>>>
>>> 3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: [WeakReference, 
>>> 207 refs, 0.0000440 secs]3.648: [FinalReference, 14473 refs, 
>>> 0.0499260 secs]3.698: [PhantomReference, 0 refs, 0.0000050 
>>> secs]3.698: [JNI Weak Reference, 0.0000120 secs]3.700: [GC pause (G1 
>>> Evacuation Pause) (young), 0.0853910 secs]
>>>    [Parallel Time: 31.9 ms, GC Workers: 8]
>>>
>>> But with my suggested fix it will be:
>>>
>>> 5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924 
>>> secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: 
>>> [FinalReference, 6 refs, 0.0000924 secs]6.032: [PhantomReference, 0 
>>> refs, 0.0000893 secs]6.032: [JNI Weak Reference, 0 refs, 0.0001699 
>>> secs], 0.2200814 secs]
>>>    [Parallel Time: 214.3 ms, GC Workers: 4]
>>>
>>>
>>> This is consistent with the way it looked before my previous change 
>>> to the G1 logging:
>>>
>>> 3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090 
>>> secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802: 
>>> [FinalReference, 13020 refs, 0.0462290 secs]3.848: 
>>> [PhantomReference, 7 refs, 0.0000110 secs]3.848: [JNI Weak 
>>> Reference, 0.0000150 secs], 0.10515900 secs]
>>>    [Parallel Time:  52.2 ms]
>>>
>>>
>>> Thanks,
>>> Bengt
>>
>



From jesper.wilhelmsson at oracle.com  Mon Sep 17 10:44:59 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 17 Sep 2012 12:44:59 +0200
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output
	comes out of order
In-Reply-To: <5056E1E1.5090609@oracle.com>
References: <50519444.4020403@oracle.com> <5052EDA8.4010106@oracle.com>
	<50539C20.3050404@oracle.com> <5056E1E1.5090609@oracle.com>
Message-ID: <5056FF2B.2050000@oracle.com>

Looks good.
Ship it!
/Jesper

On 2012-09-17 10:40, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for the review. Good point about using
> "gclog_or_tty->stamp(PrintGCTimeStamps)".  I found the same pattern in a few
> more places so I updated those as well. Here is an updated webrev:
>
> http://cr.openjdk.java.net/~brutisso/7198130/webrev.03/
>
> I still need one more review. Any takers?
>
> Bengt
>
>
> On 2012-09-14 23:05, John Cuthbertson wrote:
>> Hi Bengt,
>>
>> This looks good. One nit:
>>
>> Instead of:
>>
>> 3671   if (PrintGCTimeStamps) {
>> 3672     gclog_or_tty->stamp();
>> 3673     gclog_or_tty->print(": ");
>> 3674   }
>>
>> How about:
>>
>> 3672     gclog_or_tty->stamp(PrintGCTimeStamps);
>>
>>
>> Regards,
>>
>> JohnC
>>
>> On 09/14/12 01:41, Bengt Rutisson wrote:
>>>
>>> Hi again,
>>>
>>> Updated webrev based on merging a similar patch from John Cuthbertson:
>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.02/
>>>
>>> Bengt
>>>
>>>
>>> On 2012-09-13 10:07, Bengt Rutisson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Can I have some reviews for this change?
>>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/
>>>>
>>>> This fixes two issues that were introduced by a previous change I made to
>>>> the G1 logging. Most importantly the time stamp for the GC log entry is
>>>> now the start of the GC. Secondly, any interleaved logging that is done by
>>>> other modules will be seen within the GC log entry. This is the way it
>>>> used to be.
>>>>
>>>> As an example using these switches on the command line "-XX:+UseG1GC
>>>> -XX:+PrintGCDetails -XX:+PrintReferenceGC" currently produce output like:
>>>>
>>>> 3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: [WeakReference, 207
>>>> refs, 0.0000440 secs]3.648: [FinalReference, 14473 refs, 0.0499260
>>>> secs]3.698: [PhantomReference, 0 refs, 0.0000050 secs]3.698: [JNI Weak
>>>> Reference, 0.0000120 secs]3.700: [GC pause (G1 Evacuation Pause) (young),
>>>> 0.0853910 secs]
>>>>    [Parallel Time: 31.9 ms, GC Workers: 8]
>>>>
>>>> But with my suggested fix it will be:
>>>>
>>>> 5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924
>>>> secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: [FinalReference,
>>>> 6 refs, 0.0000924 secs]6.032: [PhantomReference, 0 refs, 0.0000893
>>>> secs]6.032: [JNI Weak Reference, 0 refs, 0.0001699 secs], 0.2200814 secs]
>>>>    [Parallel Time: 214.3 ms, GC Workers: 4]
>>>>
>>>>
>>>> This is consistent with the way it looked before my previous change to the
>>>> G1 logging:
>>>>
>>>> 3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090
>>>> secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802:
>>>> [FinalReference, 13020 refs, 0.0462290 secs]3.848: [PhantomReference, 7
>>>> refs, 0.0000110 secs]3.848: [JNI Weak Reference, 0.0000150 secs],
>>>> 0.10515900 secs]
>>>>    [Parallel Time:  52.2 ms]
>>>>
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>
>


From bengt.rutisson at oracle.com  Mon Sep 17 13:33:50 2012
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Mon, 17 Sep 2012 13:33:50 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7197906:
	BlockOffsetArray::power_to_cards_back() needs to handle > 32
	bit shifts
Message-ID: <20120917133356.2F98F47B39@hg.openjdk.java.net>

Changeset: 859cd1a76f8a
Author:    brutisso
Date:      2012-09-13 21:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/859cd1a76f8a

7197906: BlockOffsetArray::power_to_cards_back() needs to handle > 32 bit shifts
Reviewed-by: brutisso, johnc, ysr
Contributed-by: Hal Mo <kungu.mjh at taobao.com>

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/memory/blockOffsetTable.hpp



From john.cuthbertson at oracle.com  Mon Sep 17 16:34:54 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 17 Sep 2012 09:34:54 -0700
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output
	comes out of order
In-Reply-To: <5056E1E1.5090609@oracle.com>
References: <50519444.4020403@oracle.com> <5052EDA8.4010106@oracle.com>
	<50539C20.3050404@oracle.com> <5056E1E1.5090609@oracle.com>
Message-ID: <5057512E.8020409@oracle.com>

Hi Bengt,

Looks good. Ship it.

JohnC

On 09/17/12 01:40, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for the review. Good point about using 
> "gclog_or_tty->stamp(PrintGCTimeStamps)".  I found the same pattern in 
> a few more places so I updated those as well. Here is an updated webrev:
>
> http://cr.openjdk.java.net/~brutisso/7198130/webrev.03/
>
> I still need one more review. Any takers?
>
> Bengt
>
>
> On 2012-09-14 23:05, John Cuthbertson wrote:
>> Hi Bengt,
>>
>> This looks good. One nit:
>>
>> Instead of:
>>
>> 3671   if (PrintGCTimeStamps) {
>> 3672     gclog_or_tty->stamp();
>> 3673     gclog_or_tty->print(": ");
>> 3674   }
>>
>> How about:
>>
>> 3672     gclog_or_tty->stamp(PrintGCTimeStamps);
>>
>>
>> Regards,
>>
>> JohnC
>>
>> On 09/14/12 01:41, Bengt Rutisson wrote:
>>>
>>> Hi again,
>>>
>>> Updated webrev based on merging a similar patch from John Cuthbertson:
>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.02/
>>>
>>> Bengt
>>>
>>>
>>> On 2012-09-13 10:07, Bengt Rutisson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Can I have some reviews for this change?
>>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/
>>>>
>>>> This fixes two issues that were introduced by a previous change I 
>>>> made to the G1 logging. Most importantly the time stamp for the GC 
>>>> log entry is now the start of the GC. Secondly, any interleaved 
>>>> logging that is done by other modules will be seen within the GC 
>>>> log entry. This is the way it used to be.
>>>>
>>>> As an example using these switches on the command line 
>>>> "-XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintReferenceGC" currently 
>>>> produce output like:
>>>>
>>>> 3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: 
>>>> [WeakReference, 207 refs, 0.0000440 secs]3.648: [FinalReference, 
>>>> 14473 refs, 0.0499260 secs]3.698: [PhantomReference, 0 refs, 
>>>> 0.0000050 secs]3.698: [JNI Weak Reference, 0.0000120 secs]3.700: 
>>>> [GC pause (G1 Evacuation Pause) (young), 0.0853910 secs]
>>>>    [Parallel Time: 31.9 ms, GC Workers: 8]
>>>>
>>>> But with my suggested fix it will be:
>>>>
>>>> 5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924 
>>>> secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: 
>>>> [FinalReference, 6 refs, 0.0000924 secs]6.032: [PhantomReference, 0 
>>>> refs, 0.0000893 secs]6.032: [JNI Weak Reference, 0 refs, 0.0001699 
>>>> secs], 0.2200814 secs]
>>>>    [Parallel Time: 214.3 ms, GC Workers: 4]
>>>>
>>>>
>>>> This is consistent with the way it looked before my previous change 
>>>> to the G1 logging:
>>>>
>>>> 3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090 
>>>> secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802: 
>>>> [FinalReference, 13020 refs, 0.0462290 secs]3.848: 
>>>> [PhantomReference, 7 refs, 0.0000110 secs]3.848: [JNI Weak 
>>>> Reference, 0.0000150 secs], 0.10515900 secs]
>>>>    [Parallel Time:  52.2 ms]
>>>>
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>
>



From bengt.rutisson at oracle.com  Mon Sep 17 18:37:10 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 17 Sep 2012 20:37:10 +0200
Subject: Request for review (S): 7198130: G1: PrintReferenceGC output
	comes out of order
In-Reply-To: <5057512E.8020409@oracle.com>
References: <50519444.4020403@oracle.com> <5052EDA8.4010106@oracle.com>
	<50539C20.3050404@oracle.com> <5056E1E1.5090609@oracle.com>
	<5057512E.8020409@oracle.com>
Message-ID: <50576DD6.2010806@oracle.com>


Thanks John and Jesper!

All set to push this now.

Bengt

On 2012-09-17 18:34, John Cuthbertson wrote:
> Hi Bengt,
>
> Looks good. Ship it.
>
> JohnC
>
> On 09/17/12 01:40, Bengt Rutisson wrote:
>>
>> Hi John,
>>
>> Thanks for the review. Good point about using 
>> "gclog_or_tty->stamp(PrintGCTimeStamps)".  I found the same pattern 
>> in a few more places so I updated those as well. Here is an updated 
>> webrev:
>>
>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.03/
>>
>> I still need one more review. Any takers?
>>
>> Bengt
>>
>>
>> On 2012-09-14 23:05, John Cuthbertson wrote:
>>> Hi Bengt,
>>>
>>> This looks good. One nit:
>>>
>>> Instead of:
>>>
>>> 3671   if (PrintGCTimeStamps) {
>>> 3672     gclog_or_tty->stamp();
>>> 3673     gclog_or_tty->print(": ");
>>> 3674   }
>>>
>>> How about:
>>>
>>> 3672     gclog_or_tty->stamp(PrintGCTimeStamps);
>>>
>>>
>>> Regards,
>>>
>>> JohnC
>>>
>>> On 09/14/12 01:41, Bengt Rutisson wrote:
>>>>
>>>> Hi again,
>>>>
>>>> Updated webrev based on merging a similar patch from John Cuthbertson:
>>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.02/
>>>>
>>>> Bengt
>>>>
>>>>
>>>> On 2012-09-13 10:07, Bengt Rutisson wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Can I have some reviews for this change?
>>>>> http://cr.openjdk.java.net/~brutisso/7198130/webrev.01/
>>>>>
>>>>> This fixes two issues that were introduced by a previous change I 
>>>>> made to the G1 logging. Most importantly the time stamp for the GC 
>>>>> log entry is now the start of the GC. Secondly, any interleaved 
>>>>> logging that is done by other modules will be seen within the GC 
>>>>> log entry. This is the way it used to be.
>>>>>
>>>>> As an example using these switches on the command line 
>>>>> "-XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintReferenceGC" currently 
>>>>> produce output like:
>>>>>
>>>>> 3.648: [SoftReference, 0 refs, 0.0000110 secs]3.648: 
>>>>> [WeakReference, 207 refs, 0.0000440 secs]3.648: [FinalReference, 
>>>>> 14473 refs, 0.0499260 secs]3.698: [PhantomReference, 0 refs, 
>>>>> 0.0000050 secs]3.698: [JNI Weak Reference, 0.0000120 secs]3.700: 
>>>>> [GC pause (G1 Evacuation Pause) (young), 0.0853910 secs]
>>>>>    [Parallel Time: 31.9 ms, GC Workers: 8]
>>>>>
>>>>> But with my suggested fix it will be:
>>>>>
>>>>> 5.814: [GC pause (young)6.030: [SoftReference, 0 refs, 0.0000924 
>>>>> secs]6.030: [WeakReference, 3 refs, 0.0001098 secs]6.031: 
>>>>> [FinalReference, 6 refs, 0.0000924 secs]6.032: [PhantomReference, 
>>>>> 0 refs, 0.0000893 secs]6.032: [JNI Weak Reference, 0 refs, 
>>>>> 0.0001699 secs], 0.2200814 secs]
>>>>>    [Parallel Time: 214.3 ms, GC Workers: 4]
>>>>>
>>>>>
>>>>> This is consistent with the way it looked before my previous 
>>>>> change to the G1 logging:
>>>>>
>>>>> 3.746: [GC pause (young)3.802: [SoftReference, 0 refs, 0.0000090 
>>>>> secs]3.802: [WeakReference, 148 refs, 0.0000400 secs]3.802: 
>>>>> [FinalReference, 13020 refs, 0.0462290 secs]3.848: 
>>>>> [PhantomReference, 7 refs, 0.0000110 secs]3.848: [JNI Weak 
>>>>> Reference, 0.0000150 secs], 0.10515900 secs]
>>>>>    [Parallel Time:  52.2 ms]
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>
>>>
>>
>



From coleen.phillimore at oracle.com  Mon Sep 17 20:08:04 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 17 Sep 2012 20:08:04 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7197269: NPG: FollowReferences has no
	ClassLoader -> Class link to follow
Message-ID: <20120917200806.4542647B4F@hg.openjdk.java.net>

Changeset: 2a48c84f1d04
Author:    coleenp
Date:      2012-09-17 10:46 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2a48c84f1d04

7197269: NPG: FollowReferences has no ClassLoader -> Class link to follow
Summary: restore java/lang/ClassLoader.addClass() upcall
Reviewed-by: sspitsyn, dcubed, jmasa

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp



From bengt.rutisson at oracle.com  Mon Sep 17 20:08:42 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 17 Sep 2012 22:08:42 +0200
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <CABzyjynqngYEETuJNERZUta8L4OLAQjWWbipp77a0u5OSGAE+g@mail.gmail.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
	<CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>
	<505233BB.4070909@oracle.com>
	<CABzyjynm8mPN=TvFAmDStiXyPONkj=Y_QuZzeUD_GN17nOeT6A@mail.gmail.com>
	<505269E4.9040301@oracle.com>
	<CABzyjynqngYEETuJNERZUta8L4OLAQjWWbipp77a0u5OSGAE+g@mail.gmail.com>
Message-ID: <5057834A.7000201@oracle.com>


FYI, I pushed this earlier today so the fix is now available in hotspot-gc:
http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/859cd1a76f8a

I've also filed a sub CR to backport the fix to hs24/7u12. I hope we get 
approval to push it there soon.

Thanks again for the patch Hal!
Bengt

On 2012-09-14 01:26, Srinivas Ramakrishna wrote:
>
> Great, thanks John, all!
>
> -- ramki
>
> On Fri, Sep 14, 2012 at 12:19 AM, John Cuthbertson 
> <john.cuthbertson at oracle.com <mailto:john.cuthbertson at oracle.com>> wrote:
>
>     Hi Ramki,
>
>     I don't think there will be an issue with back porting this to
>     hs24 (which I think is going into 7u12). I just have to check the
>     dates. There's a couple of other CRs that we're probably going to
>     want to back port as well.
>
>     I searched the sources for the offending pattern (with and without
>     whitespace) and only found the instances fixed by Hal. I think
>     we're OK in that respect. But thanks for making sure. :)
>
>     JohnC
>
>
>     On 09/13/12 15:21, Srinivas Ramakrishna wrote:
>>
>>     Thanks Bengt; changes look good to me too, Hal, although i just
>>     looked at the changes, and did not
>>     check the code to see if there might be more instances of the
>>     fingered anti-pattern. (I am pretty sure
>>     you and John and other reviewers have covered that front well :-)
>>
>>     Bengt, any chance that the fix will get bkported also to 7uXX
>>     soon, for some suitable value of XX?
>>
>>     thanks!
>>     -- ramki
>>
>>     On Thu, Sep 13, 2012 at 8:27 PM, Bengt Rutisson
>>     <bengt.rutisson at oracle.com <mailto:bengt.rutisson at oracle.com>> wrote:
>>
>>
>>         Hi Ramki,
>>
>>         Thanks for looking at this!
>>
>>         Here's a webrev based on the second patch that Hal sent out:
>>         http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/
>>         <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.02/>
>>
>>         Bengt
>>
>>
>>         On 2012-09-13 18:12, Srinivas Ramakrishna wrote:
>>>         Hal, thanks for the catch and the fix!
>>>
>>>         Bengt, might it be possible to host this as a traditional
>>>         webrev in the usual place, to simplify review logistics?
>>>
>>>         thanks!
>>>         -- ramki
>>>
>>>         On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo
>>>         <mojianhao at gmail.com <mailto:mojianhao at gmail.com>> wrote:
>>>
>>>             Hi all,
>>>
>>>             Attached please find the new patch, modified according
>>>             to John's advice.
>>>
>>>             Thanks Bengt again for the help :)
>>>
>>>             Regards,
>>>
>>>             Hal
>>>
>>>             2012/9/12 Jianhao Mo <mojianhao at gmail.com
>>>             <mailto:mojianhao at gmail.com>>
>>>
>>>                 Hi all,
>>>
>>>                 Could I get a couple of reviews for this small
>>>                 patch, please?
>>>
>>>                 7197906: BlockOffsetArray::power_to_cards_back()
>>>                 needs to handle > 32 bit shifts
>>>
>>>                 CR link:
>>>                 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>>>                 Webrev:
>>>                 http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>>>                 <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.01/>
>>>                 Contributed-by:
>>>                 Hal Mo <kungu.mjh at taobao.com
>>>                 <mailto:kungu.mjh at taobao.com>> from Alibaba
>>>                 Group(with OCA)
>>>
>>>                 It may take a while before the CR link is publicly
>>>                 accessible.
>>>
>>>                 In blockOffsetTable.hpp, there is an unexpected data
>>>                 truncation in power_to_cards_back(uint i), which may
>>>                 lead to crashing the VM on very large GC heaps.
>>>                 The problem could be reproduced easily on machines,
>>>                 that have enough memory, with:
>>>                 $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>>
>>>                 The proposed patch fixes this problem, and builds on
>>>                 all OpenJDK supported platforms.
>>>
>>>                 I'd like to thank Bengt Rutisson for the initial
>>>                 review and help preparing the CR and Webrev.
>>>
>>>                 Regards,
>>>                 Hal 
>>>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120917/b7eeec85/attachment.htm>

From jon.masamitsu at oracle.com  Mon Sep 17 22:18:28 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 17 Sep 2012 15:18:28 -0700
Subject: Request for review - 7197557
In-Reply-To: <50569456.10705@oracle.com>
References: <50569456.10705@oracle.com>
Message-ID: <5057A1B4.4070406@oracle.com>

I have one review (Thanks JohnCu).  The change is straight forward
but it is code that has problems in the past (GC_locker code) so any
other reviews would be welcome.

Jon

On 09/16/12 20:09, Jon Masamitsu wrote:
> NPG: nsk/sysdict/vm/stress/chain/chain004 hangs intermittently
>
> The code that was doing a GC to find dead class loaders so that metadata
> could be freed does not correctly account for GC_locker activity 
> (i.e., use
> of JNI critical sections which stall GC).  Added code to recognize if
> a GC_locker is active and expand the Metaspace and allocate out of the
> expanded area.  If the expansion cannot provide metadata, wait for
> the GC_locker to inactivate so that a GC can be done.
>
> http://cr.openjdk.java.net/~jmasa/7197557/webrev.00/
>
> Note that there are three places in the different GC's that need to
> account for GC_locker activity.  I am investigating whether this
> code can be unified.


From andrew_nuss at yahoo.com  Mon Sep 17 22:34:22 2012
From: andrew_nuss at yahoo.com (Andy Nuss)
Date: Mon, 17 Sep 2012 15:34:22 -0700 (PDT)
Subject: finite automata and L1 and L2 cache misses
Message-ID: <1347921262.53383.YahooMailNeo@web120301.mail.ne1.yahoo.com>

Hi,

My application creates and executes big finite automata, which are so costly to construct that it is worth caching them for reuse.? Thus they are likely to persist thru gc cycles.

My automata consist of arrays of ints, arrays of objects, and various small objects of different class types.? What strategies can I take to ensure that these are co-located on the heap to avoid L1/L2 cache misses during automata execution?? If I succeed in this, how can I be confident that they will still be co-located AFTER gc compaction?

One idea is to have the cache hold a wrapper object rather than the graph reference itself.? The wrapper object would hold references to all the individual components of the graph, as well as the graph.? Would this help the gc cycle continue to co-locate the element objects of the graph?

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120917/4c679d9f/attachment.htm>

From ysr1729 at gmail.com  Mon Sep 17 22:53:56 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Mon, 17 Sep 2012 15:53:56 -0700
Subject: Request for review - 7197557
In-Reply-To: <5057A1B4.4070406@oracle.com>
References: <50569456.10705@oracle.com>
	<5057A1B4.4070406@oracle.com>
Message-ID: <CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>

Hi Jon --

While I am not familiar with all of the details of the new metaspaces
implementation,
from my high level knowledge of how it works, the shape of the code changes
here to address the bug looks good to me.
(Although it would have been nice if one could have read the stack retrace
of the JVM when the deadlock occurred, i
think such information was not in the public part of the bug report visible
on bugs.sun.com.)

A somewhat orthogonal question:
Could you tell me if there is any a-priori limit that the JVM sets on the
c-heap space used for the metadata?
If yes, can that limit be changed from the command-line? If there is no
such a-priori limit, could you shed any light
on a comparison of the memory footprint between the pre-NPG world and the
new post-NPG world for
some benchmarks that exercise class load/unload etc.?

thanks!
-- ramki

On Mon, Sep 17, 2012 at 3:18 PM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

> I have one review (Thanks JohnCu).  The change is straight forward
> but it is code that has problems in the past (GC_locker code) so any
> other reviews would be welcome.
>
> Jon
>
>
> On 09/16/12 20:09, Jon Masamitsu wrote:
>
>> NPG: nsk/sysdict/vm/stress/chain/**chain004 hangs intermittently
>>
>> The code that was doing a GC to find dead class loaders so that metadata
>> could be freed does not correctly account for GC_locker activity (i.e.,
>> use
>> of JNI critical sections which stall GC).  Added code to recognize if
>> a GC_locker is active and expand the Metaspace and allocate out of the
>> expanded area.  If the expansion cannot provide metadata, wait for
>> the GC_locker to inactivate so that a GC can be done.
>>
>> http://cr.openjdk.java.net/~**jmasa/7197557/webrev.00/<http://cr.openjdk.java.net/%7Ejmasa/7197557/webrev.00/>
>>
>> Note that there are three places in the different GC's that need to
>> account for GC_locker activity.  I am investigating whether this
>> code can be unified.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120917/ebf1eeb2/attachment.htm>

From bengt.rutisson at oracle.com  Mon Sep 17 23:47:06 2012
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Mon, 17 Sep 2012 23:47:06 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7198130: G1: PrintReferenceGC output
	comes out of order
Message-ID: <20120917234710.DDD6E47B55@hg.openjdk.java.net>

Changeset: 9646b7ff4d14
Author:    brutisso
Date:      2012-09-17 10:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9646b7ff4d14

7198130: G1: PrintReferenceGC output comes out of order
Summary: Move the first part of the GC logging, including timestamp, to the start of the GC
Reviewed-by: johnc, jwilhelm

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/runtime/timer.cpp



From jon.masamitsu at oracle.com  Tue Sep 18 05:06:00 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 17 Sep 2012 22:06:00 -0700
Subject: Request for review - 7197557
In-Reply-To: <CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>
References: <50569456.10705@oracle.com>	<5057A1B4.4070406@oracle.com>
	<CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>
Message-ID: <50580138.8020100@oracle.com>

Ramki,

Thanks for taking at look.

On 9/17/2012 3:53 PM, Srinivas Ramakrishna wrote:
> Hi Jon --
>
> While I am not familiar with all of the details of the new metaspaces
> implementation,
> from my high level knowledge of how it works, the shape of the code changes
> here to address the bug looks good to me.
> (Although it would have been nice if one could have read the stack retrace
> of the JVM when the deadlock occurred, i
> think such information was not in the public part of the bug report visible
> on bugs.sun.com.)

This is the top of the stack trace of the thread doing the GC.  It is 
actually a live lock where
the GC has already entered the infinite loop that keeps trying to do a 
GC (checks the
results of the gc_prologue) until the GC succeeds.  We needed to check 
for an active
GC_locker.  A thread trying to release a JNI critical section was 
blocking on a
safepoint.

=>[1] GC_locker::is_active_internal(), line 88 in "gcLocker.hpp"
   [2] GC_locker::is_active_and_needs_gc(), line 104 in "gcLocker.hpp"
   [3] VM_GC_Operation::skip_operation(this = 0xfffffd7fec9d5358), line 
92 in "vm
GCOperations.cpp"
   [4] VM_GC_Operation::doit_prologue(this = 0xfffffd7fec9d5358), line 
111 in "vm
GCOperations.cpp"
   [5] VMThread::execute(op = 0xfffffd7fec9d5358), line 587 in 
"vmThread.cpp"
   [6] CollectorPolicy::satisfy_failed_metadata_allocation(this = 
0x432558, loade
r_data = 0x52a62f8, word_size = 0x3a99U, mdtype = NonClassType), line 
765 in "co
llectorPolicy.cpp"
   [7] Metaspace::allocate(loader_data = 0x52a62f8, word_size = 0x3a99U, 
read_onl
y = true, mdtype = NonClassType, __the_thread__ = 0x348d800), line 2953 
in "meta
space.cpp"
   [8] Array<unsigned short>::operator new(size = 0x8U, loader_data = 
0x52a62f8,
length = 0xea60, read_only = true, __the_thread__ = 0x348d800), line 322 
in "arr
ay.hpp"
   [9] MetadataFactory::new_array<unsigned short>(loader_data = 
0x52a62f8, length
  = 0xea60, __the_thread__ = 0x348d800), line 38 in "metadataFactory.hpp"

> A somewhat orthogonal question:
> Could you tell me if there is any a-priori limit that the JVM sets on the
> c-heap space used for the metadata?

No limit.  The space is actually not C-heap space.  It is allocated 
using Virtualspaces which
means mmap'ed space on unix systems.  You can set a limit on the command 
line with
MaxMetaspaceSize which is analogous to MaxPermSize.

> If yes, can that limit be changed from the command-line? If there is no
> such a-priori limit, could you shed any light
> on a comparison of the memory footprint between the pre-NPG world and the
> new post-NPG world for
> some benchmarks that exercise class load/unload etc.?

We do induce GC to do class unloading.  We have a high water mark (HWM) 
for class metadata
used.  When the used class metadata hits the HWM, we induce a GC.  The 
initial value of the
HWM is 12Mbytes to 16Mbytes depending on the platform  The HWM may be 
increased after the
GC depending on how much free metadata space there is.  Think 
MinFreeRation / MaxFreeRatio
kind of policy.

For small benchmarks that don't do extensive class loading, the 
footprint may look
less because we don't reserve the space for the perm gen.  In general it 
is comparable.
We do loose some space to fragmentation and need to do more tuning in that
area.

Jon
> thanks!
> -- ramki
>
> On Mon, Sep 17, 2012 at 3:18 PM, Jon Masamitsu<jon.masamitsu at oracle.com>wrote:
>
>> I have one review (Thanks JohnCu).  The change is straight forward
>> but it is code that has problems in the past (GC_locker code) so any
>> other reviews would be welcome.
>>
>> Jon
>>
>>
>> On 09/16/12 20:09, Jon Masamitsu wrote:
>>
>>> NPG: nsk/sysdict/vm/stress/chain/**chain004 hangs intermittently
>>>
>>> The code that was doing a GC to find dead class loaders so that metadata
>>> could be freed does not correctly account for GC_locker activity (i.e.,
>>> use
>>> of JNI critical sections which stall GC).  Added code to recognize if
>>> a GC_locker is active and expand the Metaspace and allocate out of the
>>> expanded area.  If the expansion cannot provide metadata, wait for
>>> the GC_locker to inactivate so that a GC can be done.
>>>
>>> http://cr.openjdk.java.net/~**jmasa/7197557/webrev.00/<http://cr.openjdk.java.net/%7Ejmasa/7197557/webrev.00/>
>>>
>>> Note that there are three places in the different GC's that need to
>>> account for GC_locker activity.  I am investigating whether this
>>> code can be unified.
>>>


From dawid.weiss at gmail.com  Tue Sep 18 06:51:52 2012
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Tue, 18 Sep 2012 08:51:52 +0200
Subject: finite automata and L1 and L2 cache misses
In-Reply-To: <1347921262.53383.YahooMailNeo@web120301.mail.ne1.yahoo.com>
References: <1347921262.53383.YahooMailNeo@web120301.mail.ne1.yahoo.com>
Message-ID: <CAM21Rt8v0CftW8vMizQuvibXqOx2CGRwCXxfyW=0XF2LsA55cg@mail.gmail.com>

Hi. I've implemented Daciuk-Mihov's algorithm for FSA construction
from sorted data once and it was a few times faster than the native
implementation in C++ by the original author. It's a matter of
tradeoffs, really. If you want speed you'll have to go with low-level
data structures. Simulate objects on (possibly parallel) arrays of
primitives or a bytebuffer. I realize it's a pain but the speedup
should be significant.

My implementation is part of the morfologik project here:
http://sourceforge.net/projects/morfologik/

There is another implementation, this time an FST, based on similar
principles (authored by many people from the Apache Lucene project),
look for FSTBuilder etc.:
http://lucene.apache.org/core/

I guess my point here is that the Java implementation comes with
tradeoffs -- if you're using objects and utilize GC heavily (the
objects are not statically allocated once, for example) then you'll
pay the price. If you're using low-level primitives then... well, it's
much like coding in C or assembly, really, so unless you have a strong
motivation to do it (a library) I'd rather consider going through JNI
or simply upgrading your hardware :)

Dawid

On Tue, Sep 18, 2012 at 12:34 AM, Andy Nuss <andrew_nuss at yahoo.com> wrote:
> Hi,
>
> My application creates and executes big finite automata, which are so costly
> to construct that it is worth caching them for reuse.  Thus they are likely
> to persist thru gc cycles.
>
> My automata consist of arrays of ints, arrays of objects, and various small
> objects of different class types.  What strategies can I take to ensure that
> these are co-located on the heap to avoid L1/L2 cache misses during automata
> execution?  If I succeed in this, how can I be confident that they will
> still be co-located AFTER gc compaction?
>
> One idea is to have the cache hold a wrapper object rather than the graph
> reference itself.  The wrapper object would hold references to all the
> individual components of the graph, as well as the graph.  Would this help
> the gc cycle continue to co-locate the element objects of the graph?
>
> Andy


From ysr1729 at gmail.com  Tue Sep 18 19:04:22 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Tue, 18 Sep 2012 12:04:22 -0700
Subject: Request for review - 7197557
In-Reply-To: <50580138.8020100@oracle.com>
References: <50569456.10705@oracle.com> <5057A1B4.4070406@oracle.com>
	<CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>
	<50580138.8020100@oracle.com>
Message-ID: <CABzyjynam--kqAfmMY7FQLab1-qkyeS5eROM3uVFTdi5RdRWSg@mail.gmail.com>

On Mon, Sep 17, 2012 at 10:06 PM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

> ... This is the top of the stack trace of the thread doing the GC.  It is
> actually a live lock where
> the GC has already entered the infinite loop that keeps trying to do a GC
> (checks the
> results of the gc_prologue) until the GC succeeds.  We needed to check for
> an active
> GC_locker.  A thread trying to release a JNI critical section was blocking
> on a
> safepoint.
>
> =>[1] GC_locker::is_active_internal(**), line 88 in "gcLocker.hpp"
>   [2] GC_locker::is_active_and_**needs_gc(), line 104 in "gcLocker.hpp"
>   [3] VM_GC_Operation::skip_**operation(this = 0xfffffd7fec9d5358), line
> 92 in "vm
> GCOperations.cpp"
>   [4] VM_GC_Operation::doit_**prologue(this = 0xfffffd7fec9d5358), line
> 111 in "vm
> GCOperations.cpp"
>   [5] VMThread::execute(op = 0xfffffd7fec9d5358), line 587 in
> "vmThread.cpp"
>   [6] CollectorPolicy::satisfy_**failed_metadata_allocation(**this =
> 0x432558, loade
> r_data = 0x52a62f8, word_size = 0x3a99U, mdtype = NonClassType), line 765
> in "co
> llectorPolicy.cpp"
>   [7] Metaspace::allocate(loader_**data = 0x52a62f8, word_size = 0x3a99U,
> read_onl
> y = true, mdtype = NonClassType, __the_thread__ = 0x348d800), line 2953 in
> "meta
> space.cpp"
>   [8] Array<unsigned short>::operator new(size = 0x8U, loader_data =
> 0x52a62f8,
> length = 0xea60, read_only = true, __the_thread__ = 0x348d800), line 322
> in "arr
> ay.hpp"
>   [9] MetadataFactory::new_array<**unsigned short>(loader_data =
> 0x52a62f8, length
>  = 0xea60, __the_thread__ = 0x348d800), line 38 in "metadataFactory.hpp"


Makes sense; thanks!


 A somewhat orthogonal question:
> Could you tell me if there is any a-priori limit that the JVM sets on the
> c-heap space used for the metadata?
>

No limit.  The space is actually not C-heap space.  It is allocated using
> Virtualspaces which
> means mmap'ed space on unix systems.  You can set a limit on the command
> line with
> MaxMetaspaceSize which is analogous to MaxPermSize.
>
>
>  If yes, can that limit be changed from the command-line? If there is no
>> such a-priori limit, could you shed any light
>> on a comparison of the memory footprint between the pre-NPG world and the
>> new post-NPG world for
>> some benchmarks that exercise class load/unload etc.?
>>
>
> We do induce GC to do class unloading.  We have a high water mark (HWM)
> for class metadata
> used.  When the used class metadata hits the HWM, we induce a GC.  The
> initial value of the
> HWM is 12Mbytes to 16Mbytes depending on the platform  The HWM may be
> increased after the
> GC depending on how much free metadata space there is.  Think
> MinFreeRation / MaxFreeRatio
> kind of policy.
>
> For small benchmarks that don't do extensive class loading, the footprint
> may look
> less because we don't reserve the space for the perm gen.  In general it
> is comparable.
> We do loose some space to fragmentation and need to do more tuning in that
> area.
>

Great; thanks a lot for that information. I am assuming that in general
full gc's as a result of the Java heap
filling up will, in most cases, take care of reclaiming enough space in the
metadata spaces, so that no explicit
collection is needed for the total size of the metadata spaces to stay
within the HWM computed. By the way, I assume that
there is some way that we can set the starting and maximum metaspace size
to the same value, analogous
to setting PermSize to MaxPermSize? (Essentially saying that the initial
size of the meta space is its maximum size
and that Max/Min free ratio must be ignored.) Anyway, I'll look at the code
and play with the JVM to learn more, but it would be
great if you folks could also put out a brief whitepaper giving an overview
of the implementation and
describing the transition to the new perm gen world and how one might size
these thresholds so as to empirically
"right-size" the heap based on the GC log data etc.

thanks a lot again! And sorry for hijacking the review thread for this
side-conversation.
-- ramki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120918/5412d0f9/attachment.htm>

From jon.masamitsu at oracle.com  Wed Sep 19 09:04:27 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Wed, 19 Sep 2012 09:04:27 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7197557: NPG:
	nsk/sysdict/vm/stress/chain/chain004 hangs intermittently
Message-ID: <20120919090431.0305147BB0@hg.openjdk.java.net>

Changeset: 8da5e203b993
Author:    jmasa
Date:      2012-09-18 14:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8da5e203b993

7197557: NPG: nsk/sysdict/vm/stress/chain/chain004 hangs intermittently
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp



From john.cuthbertson at oracle.com  Wed Sep 19 21:48:04 2012
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Wed, 19 Sep 2012 21:48:04 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7016955: G1: remove the is_zeroed
	parameter from the HeapRegion constructor
Message-ID: <20120919214808.6FB6147BC2@hg.openjdk.java.net>

Changeset: 8fbf05030e24
Author:    johnc
Date:      2012-09-19 08:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8fbf05030e24

7016955: G1: remove the is_zeroed parameter from the HeapRegion constructor
Summary: The is_zeroed parameter is no longer used and so can be removed.
Reviewed-by: johnc, jmasa, brutisso
Contributed-by: Brandon Mitchell <brandon at twitter.com>

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp



From jon.masamitsu at oracle.com  Wed Sep 19 22:30:03 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 19 Sep 2012 15:30:03 -0700
Subject: Request for review - 7197557
In-Reply-To: <CABzyjynam--kqAfmMY7FQLab1-qkyeS5eROM3uVFTdi5RdRWSg@mail.gmail.com>
References: <50569456.10705@oracle.com>	<5057A1B4.4070406@oracle.com>	<CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>	<50580138.8020100@oracle.com>
	<CABzyjynam--kqAfmMY7FQLab1-qkyeS5eROM3uVFTdi5RdRWSg@mail.gmail.com>
Message-ID: <505A476B.3020302@oracle.com>



On 9/18/2012 12:04 PM, Srinivas Ramakrishna wrote:
> ....
> Great; thanks a lot for that information. I am assuming that in general
> full gc's as a result of the Java heap
> filling up will, in most cases, take care of reclaiming enough space in the
> metadata spaces, so that no explicit
> collection is needed for the total size of the metadata spaces to stay
> within the HWM computed. By the way, I assume that

That's my experience.    GC's happen much more often because the heap 
gets  full
and the GC's (full) unload classes.

> there is some way that we can set the starting and maximum metaspace size
> to the same value, analogous
> to setting PermSize to MaxPermSize? (Essentially saying that the initial
   product_pd(uintx, 
MetaspaceSize,                                          \
           "Initial size of Metaspaces (in 
bytes)")                          \
                                                                             \
   product(uintx, MaxMetaspaceSize, 
max_uintx,                               \
           "Maximum size of Metaspaces (in 
bytes)")                          \

Those might even be at the same lines as PermSize and MaxPermSize used 
to be  :-)

> size of the meta space is its maximum size
> and that Max/Min free ratio must be ignored.) Anyway, I'll look at the code
> and play with the JVM to learn more, but it would be
> great if you folks could also put out a brief whitepaper giving an overview
> of the implementation and
Sounds like you've blocked out of your memory what life is like here.  
:-)  Whitepaper?  More likely
sparse release notes.

> describing the transition to the new perm gen world and how one might size
> these thresholds so as to empirically
> "right-size" the heap based on the GC log data etc.

That's actually something we don't know yet.  Performance seems to be 
neutral and I'll take that
given the number of lines we've touched.  And we do have more 
performance measurements
to do.

Jon
> thanks a lot again! And sorry for hijacking the review thread for this
> side-conversation.
> -- ramki
>


From vitalyd at gmail.com  Wed Sep 19 23:07:46 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 19 Sep 2012 19:07:46 -0400
Subject: Request for review - 7197557
In-Reply-To: <505A476B.3020302@oracle.com>
References: <50569456.10705@oracle.com> <5057A1B4.4070406@oracle.com>
	<CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>
	<50580138.8020100@oracle.com>
	<CABzyjynam--kqAfmMY7FQLab1-qkyeS5eROM3uVFTdi5RdRWSg@mail.gmail.com>
	<505A476B.3020302@oracle.com>
Message-ID: <CAHjP37GNDZov1iAomedP3w+cP58q7PNva+Jhgv=aQ-x3BfycQg@mail.gmail.com>

Hi Jon,

Do the Metaspace size args allow use of size specifiers (e.g. "g", "m",
etc) like Xmx/Xms? I don't have code in front of me but it's a bit unclear
from the option descriptions since they mention that the value is in bytes.

Thanks

Sent from my phone
On Sep 19, 2012 6:31 PM, "Jon Masamitsu" <jon.masamitsu at oracle.com> wrote:

>
>
> On 9/18/2012 12:04 PM, Srinivas Ramakrishna wrote:
>
>> ....
>> Great; thanks a lot for that information. I am assuming that in general
>> full gc's as a result of the Java heap
>> filling up will, in most cases, take care of reclaiming enough space in
>> the
>> metadata spaces, so that no explicit
>> collection is needed for the total size of the metadata spaces to stay
>> within the HWM computed. By the way, I assume that
>>
>
> That's my experience.    GC's happen much more often because the heap gets
>  full
> and the GC's (full) unload classes.
>
>  there is some way that we can set the starting and maximum metaspace size
>> to the same value, analogous
>> to setting PermSize to MaxPermSize? (Essentially saying that the initial
>>
>   product_pd(uintx, MetaspaceSize,
>  \
>           "Initial size of Metaspaces (in bytes)")
>  \
>
>   \
>   product(uintx, MaxMetaspaceSize, max_uintx,
>   \
>           "Maximum size of Metaspaces (in bytes)")
>  \
>
> Those might even be at the same lines as PermSize and MaxPermSize used to
> be  :-)
>
>  size of the meta space is its maximum size
>> and that Max/Min free ratio must be ignored.) Anyway, I'll look at the
>> code
>> and play with the JVM to learn more, but it would be
>> great if you folks could also put out a brief whitepaper giving an
>> overview
>> of the implementation and
>>
> Sounds like you've blocked out of your memory what life is like here.  :-)
>  Whitepaper?  More likely
> sparse release notes.
>
>  describing the transition to the new perm gen world and how one might size
>> these thresholds so as to empirically
>> "right-size" the heap based on the GC log data etc.
>>
>
> That's actually something we don't know yet.  Performance seems to be
> neutral and I'll take that
> given the number of lines we've touched.  And we do have more performance
> measurements
> to do.
>
> Jon
>
>> thanks a lot again! And sorry for hijacking the review thread for this
>> side-conversation.
>> -- ramki
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120919/f0932988/attachment.htm>

From jon.masamitsu at oracle.com  Wed Sep 19 23:52:11 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 19 Sep 2012 16:52:11 -0700
Subject: Request for review - 7197557
In-Reply-To: <CAHjP37GNDZov1iAomedP3w+cP58q7PNva+Jhgv=aQ-x3BfycQg@mail.gmail.com>
References: <50569456.10705@oracle.com>	<5057A1B4.4070406@oracle.com>	<CABzyjyk7J-XqyOkCRyHbQ4=kx4DzVZzUEM5_s1dFPZNSd6HEdg@mail.gmail.com>	<50580138.8020100@oracle.com>	<CABzyjynam--kqAfmMY7FQLab1-qkyeS5eROM3uVFTdi5RdRWSg@mail.gmail.com>	<505A476B.3020302@oracle.com>
	<CAHjP37GNDZov1iAomedP3w+cP58q7PNva+Jhgv=aQ-x3BfycQg@mail.gmail.com>
Message-ID: <505A5AAB.7070408@oracle.com>



On 9/19/2012 4:07 PM, Vitaly Davidovich wrote:
> Hi Jon,
>
> Do the Metaspace size args allow use of size specifiers (e.g. "g", "m",
> etc) like Xmx/Xms? I don't have code in front of me but it's a bit unclear
> from the option descriptions since they mention that the value is in bytes.

Yes, it does allow the size specifiers.

Jon



From jon.masamitsu at oracle.com  Thu Sep 20 03:40:27 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 19 Sep 2012 20:40:27 -0700
Subject: Request for review (m) - 7054397
Message-ID: <505A902B.60103@oracle.com>

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 john.cuthbertson at oracle.com  Thu Sep 20 09:42:06 2012
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Thu, 20 Sep 2012 09:42:06 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7193946: Move warnings associated with
	UseMemSetInBOT flag
Message-ID: <20120920094218.9E97747BE2@hg.openjdk.java.net>

Changeset: bc675e55b48c
Author:    johnc
Date:      2012-09-19 15:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bc675e55b48c

7193946: Move warnings associated with UseMemSetInBOT flag
Summary: The warnings associated with the UseMemSetInBOT flag are duplicated in CMS and G1. The separate warnings have been removed and single instance of the warning has been placed in a common location.
Reviewed-by: brutisso, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp



From jon.masamitsu at oracle.com  Thu Sep 20 18:36:05 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 20 Sep 2012 11:36:05 -0700
Subject: Request for review (vs) - 7199923
In-Reply-To: <505B609D.9030807@oracle.com>
References: <505B609D.9030807@oracle.com>
Message-ID: <505B6215.3030405@oracle.com>

7199923: NPG: tools/javac/T7093325.java timeout

The method has_defined() checks that a class is in
the classloader's list of classes. has_defined() was
used in an assertion when doing marking and
adjusting of pointers in a class. Doing that check
for every class spends too much time looking
down the list of a classloader's classes.

http://cr.openjdk.java.net/~jmasa/7199923/webrev.00/

I'd like to get this back for testing tonight so my
apologies if I cut short the review period.  Please
send your comments in any event and I'll fix
any problems in a second CR.


From john.cuthbertson at oracle.com  Thu Sep 20 19:15:49 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 20 Sep 2012 12:15:49 -0700
Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption
Message-ID: <505B6B65.1060201@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/7188263/webrev.0 ?

Summary:
Compared to the other collectors, G1 consumes much more C heap (even 
during start up):

ParallelGC (w/o ParallelOld):

dr-evil{jcuthber}:210> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
-XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
-XX:+UseParallelGC -XX:+PrintMallocStatistics -XX:-UseParallelOldGC
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug, 
mixed mode)
allocation stats: 3488 mallocs (12MB), 1161 frees (0MB), 4MB resrc

ParallelGC (w/ ParallelOld):


dr-evil{jcuthber}:211> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
-XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
-XX:+UseParallelGC -XX:+PrintMallocStatistics
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug, 
mixed mode)
allocation stats: 3553 mallocs (36MB), 1160 frees (0MB), 4MB resrc

G1:

dr-evil{jcuthber}:212> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
-XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
-XX:+UseG1GC -XX:+PrintMallocStatistics
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug, 
mixed mode)
allocation stats: 21703 mallocs (212MB), 1158 frees (0MB), 4MB resrc

With the parallel collector, the main culprit is the work queues. For 
ParallelGC (without ParallelOIdGC) the amount of space allocated is 
around 1Mb per GC thread. For ParallelGC (with ParallelOldGC) this 
increases to around 3Mb per worker thread.  In G1, the main culprits are 
the global marking stack, the work queues (for both GC threads and 
marking threads), and some per-worker structures used for liveness 
accounting. This results in an additional 128Mb being allocated for the 
global marking stack and the amount allocated per-worker thread 
increases to around 7Mb. On some systems (specifically large T-series 
SPARC) this increase in C heap consumption can result in 
out-of-system-memory errors. These marking data structures are critical 
for G1. Reducing the sizes is a possible solution but increases the 
possibility of restarting marking due to overflowing the marking 
stack(s), lengthening marking durations, and increasing the chance of an 
evacuation failure and/or a Full GC.

The solution we have adopted, therefore, is to allocate some of these 
marking data structures from virtual memory. This reduces the C heap 
consumption during start-up to:

dr-evil{jcuthber}:216> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
-XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
-XX:+UseG1GC -XX:+PrintMallocStatistics
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b18-internal-fastdebug, 
mixed mode)
allocation stats: 21682 mallocs (29MB), 1158 frees (0MB), 4MB resrc

The memory is still allocated - just not from C heap. With these 
changes, G1's C heap consumption is now approximately 2Mb for each 
worker thread (which are the work queues themselves):

C heap consumption (Mb) / # of GC threads

*Collector / # GC Threads
* 	*1
* 	*2
* 	*3
* 	*3
* 	*5
*
ParallelGC w/o ParallelOldGC
	3
	4
	5
	6
	7
ParallelGC w/ ParallelOldGC
	7
	11
	14
	17
	20
G1 before changes
	149
	156
	163
	170
	177
G1 after changes
	11
	13
	15
	17
	19


We shall also investigate reducing the work queue sizes, to further 
reduce the amount of C heap consumed,  for some or all of the collectors 
- but in a separate CR.

Testing:
GC test suite on x64 and sparc T-series with a low marking threshold and 
marking verification enabled; jprt. Our reference workload was used to 
verify that there was no significant performance difference.

Thanks,

JohnC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120920/7c90eb15/attachment.htm>

From vladimir.kozlov at oracle.com  Thu Sep 20 19:17:33 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 20 Sep 2012 12:17:33 -0700
Subject: Request for review (vs) - 7199923
In-Reply-To: <505B6215.3030405@oracle.com>
References: <505B609D.9030807@oracle.com> <505B6215.3030405@oracle.com>
Message-ID: <505B6BCD.8050607@oracle.com>

Good.

Vladimir

Jon Masamitsu wrote:
> 7199923: NPG: tools/javac/T7093325.java timeout
> 
> The method has_defined() checks that a class is in
> the classloader's list of classes. has_defined() was
> used in an assertion when doing marking and
> adjusting of pointers in a class. Doing that check
> for every class spends too much time looking
> down the list of a classloader's classes.
> 
> http://cr.openjdk.java.net/~jmasa/7199923/webrev.00/
> 
> I'd like to get this back for testing tonight so my
> apologies if I cut short the review period.  Please
> send your comments in any event and I'll fix
> any problems in a second CR.


From john.cuthbertson at oracle.com  Thu Sep 20 19:55:52 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 20 Sep 2012 12:55:52 -0700
Subject: Request for review (vs) - 7199923
In-Reply-To: <505B6215.3030405@oracle.com>
References: <505B609D.9030807@oracle.com> <505B6215.3030405@oracle.com>
Message-ID: <505B74C8.6030501@oracle.com>

Hi Jon,

This looks good to me.

JohnC

On 09/20/12 11:36, Jon Masamitsu wrote:
> 7199923: NPG: tools/javac/T7093325.java timeout
>
> The method has_defined() checks that a class is in
> the classloader's list of classes. has_defined() was
> used in an assertion when doing marking and
> adjusting of pointers in a class. Doing that check
> for every class spends too much time looking
> down the list of a classloader's classes.
>
> http://cr.openjdk.java.net/~jmasa/7199923/webrev.00/
>
> I'd like to get this back for testing tonight so my
> apologies if I cut short the review period.  Please
> send your comments in any event and I'll fix
> any problems in a second CR.



From john.cuthbertson at oracle.com  Thu Sep 20 20:44:37 2012
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Thu, 20 Sep 2012 20:44:37 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7190666: G1: assert(_unused == 0) failed:
	Inconsistency in PLAB stats
Message-ID: <20120920204441.CCBB247C04@hg.openjdk.java.net>

Changeset: b2ef234911c9
Author:    johnc
Date:      2012-09-20 09:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b2ef234911c9

7190666: G1: assert(_unused == 0) failed: Inconsistency in PLAB stats
Summary: Reset the fields in ParGCAllocBuffer, that are used for accumulating values for the ResizePLAB sensors in PLABStats, to zero after flushing the values to the PLABStats fields. Flush PLABStats values only when retiring the final allocation buffers prior to disposing of a G1ParScanThreadState object, rather than when retiring every allocation buffer.
Reviewed-by: jwilhelm, jmasa, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp



From ysr1729 at gmail.com  Thu Sep 20 21:39:14 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 20 Sep 2012 14:39:14 -0700
Subject: Request for review (vs) - 7199923
In-Reply-To: <505B6215.3030405@oracle.com>
References: <505B609D.9030807@oracle.com>
	<505B6215.3030405@oracle.com>
Message-ID: <CABzyjy=Eq-2hdvx_mR4UrsGvwoaeSSr2UCLLJ_rz9Ly=9GGxCg@mail.gmail.com>

Looks good. Was it mainly for the system class loader that this turned out
to be a problem because of the
very large number of classes it loads, although of course the linear walk
can result in quadratic lookup
complexity which makes it bad in general. (The other thing would be to have
the set be a tree (or a skip list),
splitting by some key such as full class name. Anyway, OK to throw away the
frequent assertion checking for now.)

-- ramki

On Thu, Sep 20, 2012 at 11:36 AM, Jon Masamitsu <jon.masamitsu at oracle.com>wrote:

> 7199923: NPG: tools/javac/T7093325.java timeout
>
> The method has_defined() checks that a class is in
> the classloader's list of classes. has_defined() was
> used in an assertion when doing marking and
> adjusting of pointers in a class. Doing that check
> for every class spends too much time looking
> down the list of a classloader's classes.
>
> http://cr.openjdk.java.net/~**jmasa/7199923/webrev.00/<http://cr.openjdk.java.net/%7Ejmasa/7199923/webrev.00/>
>
> I'd like to get this back for testing tonight so my
> apologies if I cut short the review period.  Please
> send your comments in any event and I'll fix
> any problems in a second CR.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120920/3a0e0411/attachment.htm>

From ysr1729 at gmail.com  Thu Sep 20 22:00:20 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 20 Sep 2012 15:00:20 -0700
Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption
In-Reply-To: <505B6B65.1060201@oracle.com>
References: <505B6B65.1060201@oracle.com>
Message-ID: <CABzyjy=wfttS1o9uw_m7aNMCqK8jg_S8xfO7=1Ns2P4CH5RjnQ@mail.gmail.com>

Hi John --

Do you have numbers for CMS, to check if it's a potential problem there as
well?
(since much of the work-queue & marking stack allocation code is likely
similar if not
identical -- although some of the other structures are G1-specific.)

By the way, on the T4/Solaris box, did you check how crowded the VA space
became when you
got the ostensible OOM from malloc? I wonder whether the problem is not the
use of the malloc-heap
per-se (although not using malloc for such large, static strcutures that
live for the lifetime of the JVM
is definitely a move in the right direction) but the fact that Solaris'
lmalloc may be constraining itself
to a contiguous section of the VA space, unlike some other malloc's (such
as Linux's) which don't do that.
If that is the case, may be that's a potential conversation with the
Solaris libc/malloc folk.

I'll look at the changes in a bit.
-- ramki

On Thu, Sep 20, 2012 at 12:15 PM, 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/7188263/webrev.0?
>
> Summary:
> Compared to the other collectors, G1 consumes much more C heap (even
> during start up):
>
> ParallelGC (w/o ParallelOld):
>
> dr-evil{jcuthber}:210> ./test.sh -d64 -XX:-ZapUnusedHeapArea
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g
> -XX:+UseParallelGC -XX:+PrintMallocStatistics -XX:-UseParallelOldGC
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug,
> mixed mode)
> allocation stats: 3488 mallocs (12MB), 1161 frees (0MB), 4MB resrc
>
> ParallelGC (w/ ParallelOld):
>
>
> dr-evil{jcuthber}:211> ./test.sh -d64 -XX:-ZapUnusedHeapArea
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g
> -XX:+UseParallelGC -XX:+PrintMallocStatistics
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug,
> mixed mode)
> allocation stats: 3553 mallocs (36MB), 1160 frees (0MB), 4MB resrc
>
> G1:
>
> dr-evil{jcuthber}:212> ./test.sh -d64 -XX:-ZapUnusedHeapArea
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g -XX:+UseG1GC
> -XX:+PrintMallocStatistics
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug,
> mixed mode)
> allocation stats: 21703 mallocs (212MB), 1158 frees (0MB), 4MB resrc
>
> With the parallel collector, the main culprit is the work queues. For
> ParallelGC (without ParallelOIdGC) the amount of space allocated is around
> 1Mb per GC thread. For ParallelGC (with ParallelOldGC) this increases to
> around 3Mb per worker thread.  In G1, the main culprits are the global
> marking stack, the work queues (for both GC threads and marking threads),
> and some per-worker structures used for liveness accounting. This results
> in an additional 128Mb being allocated for the global marking stack and the
> amount allocated per-worker thread increases to around 7Mb. On some systems
> (specifically large T-series SPARC) this increase in C heap consumption can
> result in out-of-system-memory errors. These marking data structures are
> critical for G1. Reducing the sizes is a possible solution but increases
> the possibility of restarting marking due to overflowing the marking
> stack(s), lengthening marking durations, and increasing the chance of an
> evacuation failure and/or a Full GC.
>
> The solution we have adopted, therefore, is to allocate some of these
> marking data structures from virtual memory. This reduces the C heap
> consumption during start-up to:
>
> dr-evil{jcuthber}:216> ./test.sh -d64 -XX:-ZapUnusedHeapArea
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g -XX:+UseG1GC
> -XX:+PrintMallocStatistics
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b18-internal-fastdebug,
> mixed mode)
> allocation stats: 21682 mallocs (29MB), 1158 frees (0MB), 4MB resrc
>
> The memory is still allocated - just not from C heap. With these changes,
> G1's C heap consumption is now approximately 2Mb for each worker thread
> (which are the work queues themselves):
>
> C heap consumption (Mb) / # of GC threads
>
>   *Collector / # GC Threads
> * *1
> * *2
> * *3
> * *3
> * *5
> *  ParallelGC w/o ParallelOldGC
>  3
>  4
>  5
>  6
>  7
>   ParallelGC w/ ParallelOldGC
>  7
>  11
>  14
>  17
>  20
>   G1 before changes
>  149
>  156
>  163
>  170
>  177
>   G1 after changes
>  11
>  13
>  15
>  17
>  19
>
> We shall also investigate reducing the work queue sizes, to further reduce
> the amount of C heap consumed,  for some or all of the collectors - but in
> a separate CR.
>
> Testing:
> GC test suite on x64 and sparc T-series with a low marking threshold and
> marking verification enabled; jprt. Our reference workload was used to
> verify that there was no significant performance difference.
>
> Thanks,
>
> JohnC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120920/70e9ee31/attachment.htm>

From jon.masamitsu at oracle.com  Thu Sep 20 23:21:25 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Thu, 20 Sep 2012 23:21:25 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets
Message-ID: <20120920232133.36B7847C06@hg.openjdk.java.net>

Changeset: e861d44e0c9c
Author:    jmasa
Date:      2012-09-20 12:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e861d44e0c9c

7199923: NPG: tools/javac/T7093325.java timeout
Reviewed-by: stefank, coleenp, kvn

! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/shared/markSweep.cpp

Changeset: 46b3b2dd84db
Author:    jmasa
Date:      2012-09-20 13:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/46b3b2dd84db

Merge




From john.coomes at oracle.com  Fri Sep 21 01:56:47 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 01:56:47 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7199082: write warning messages to stderr
Message-ID: <20120921015652.E56C047C11@hg.openjdk.java.net>

Changeset: 145ffab733e7
Author:    jcoomes
Date:      2012-09-20 16:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/145ffab733e7

7199082: write warning messages to stderr
Reviewed-by: ysr, dholmes, sla

! src/share/vm/utilities/debug.cpp



From bengt.rutisson at oracle.com  Fri Sep 21 14:17:16 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 21 Sep 2012 16:17:16 +0200
Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption
In-Reply-To: <505B6B65.1060201@oracle.com>
References: <505B6B65.1060201@oracle.com>
Message-ID: <505C76EC.5030902@oracle.com>


Hi John,

Thanks for doing the thorough analysis and providing the numbers. 
Interesting that G1 does 21703 mallocs at startup whereas Parallel only 
does 3500...

However, I think I need some more background on this change. We are 
choosing to allocating into a single VirtualSpace instead of using 
separate mallocs. I understand that this will reduce the number of 
mallocs we do, but is that really the problem? The CR says that we run 
out of memory due to the fact that the GC threads allocate too much 
memory. We will still allocate the same amount of memory just mmapped 
instead of malloced, right? Do we have any test cases that fail before 
your fix but pass now?

In fact, isn't the risk higher (at least on 32 bit platforms) that we 
fail to allocate the bitmaps now that we try to allocate them from one 
consecutive chunk of memory instead of several smaller ones? I'm 
thinking that if the memory is fragmented we might not get the 
contiguous memory we need for the VirtualSpace. But I am definitely no 
expert in this.

With the above reservation I think your change looks good. Here are a 
couple of minor comments:

CMMarkStack::allocate(size_t size)
"size" is kind of an overloaded name for an "allocate" method. Could we 
call it "capacity" or "number_of_entries"?


Snippet In ConcurrentMark::ConcurrentMark() we use both shifting and 
division to accomplish the same thing on the lines after each other. 
Could we maybe use the same style for both cases?

   // Card liveness bitmap size (in bits)
   BitMap::idx_t card_bm_size = (heap_rs.size() + 
CardTableModRefBS::card_size - 1)
                                 >> CardTableModRefBS::card_shift;
   // Card liveness bitmap size (in bytes)
   size_t card_bm_size_bytes = (card_bm_size + (BitsPerByte - 1)) / 
BitsPerByte;



Also in ConcurrentMark::ConcurrentMark() I think  that 
"marked_bytes_size_bytes" is not such a great name. Probably we could 
skip the first "bytes" in "marked_bytes_size" and just call 
"marked_bytes_size_bytes" for "marked_size_bytes".


I think it would be nice to factor some of the new stuff in 
ConcurrentMark::ConcurrentMark() out into methods. Both the calculations 
of the sizes and the creation/setting of the bitmaps. But I admit that 
this is just a style issue.


Thanks,
Bengt





On 2012-09-20 21:15, 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/7188263/webrev.0 ?
>
> Summary:
> Compared to the other collectors, G1 consumes much more C heap (even 
> during start up):
>
> ParallelGC (w/o ParallelOld):
>
> dr-evil{jcuthber}:210> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
> -XX:+UseParallelGC -XX:+PrintMallocStatistics -XX:-UseParallelOldGC
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug, 
> mixed mode)
> allocation stats: 3488 mallocs (12MB), 1161 frees (0MB), 4MB resrc
>
> ParallelGC (w/ ParallelOld):
>
>
> dr-evil{jcuthber}:211> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
> -XX:+UseParallelGC -XX:+PrintMallocStatistics
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug, 
> mixed mode)
> allocation stats: 3553 mallocs (36MB), 1160 frees (0MB), 4MB resrc
>
> G1:
>
> dr-evil{jcuthber}:212> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
> -XX:+UseG1GC -XX:+PrintMallocStatistics
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20-internal-fastdebug, 
> mixed mode)
> allocation stats: 21703 mallocs (212MB), 1158 frees (0MB), 4MB resrc
>
> With the parallel collector, the main culprit is the work queues. For 
> ParallelGC (without ParallelOIdGC) the amount of space allocated is 
> around 1Mb per GC thread. For ParallelGC (with ParallelOldGC) this 
> increases to around 3Mb per worker thread.  In G1, the main culprits 
> are the global marking stack, the work queues (for both GC threads and 
> marking threads), and some per-worker structures used for liveness 
> accounting. This results in an additional 128Mb being allocated for 
> the global marking stack and the amount allocated per-worker thread 
> increases to around 7Mb. On some systems (specifically large T-series 
> SPARC) this increase in C heap consumption can result in 
> out-of-system-memory errors. These marking data structures are 
> critical for G1. Reducing the sizes is a possible solution but 
> increases the possibility of restarting marking due to overflowing the 
> marking stack(s), lengthening marking durations, and increasing the 
> chance of an evacuation failure and/or a Full GC.
>
> The solution we have adopted, therefore, is to allocate some of these 
> marking data structures from virtual memory. This reduces the C heap 
> consumption during start-up to:
>
> dr-evil{jcuthber}:216> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
> -XX:+UseG1GC -XX:+PrintMallocStatistics
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b18-internal-fastdebug, 
> mixed mode)
> allocation stats: 21682 mallocs (29MB), 1158 frees (0MB), 4MB resrc
>
> The memory is still allocated - just not from C heap. With these 
> changes, G1's C heap consumption is now approximately 2Mb for each 
> worker thread (which are the work queues themselves):
>
> C heap consumption (Mb) / # of GC threads
>
> *Collector / # GC Threads
> * 	*1
> * 	*2
> * 	*3
> * 	*3
> * 	*5
> *
> ParallelGC w/o ParallelOldGC
> 	3
> 	4
> 	5
> 	6
> 	7
> ParallelGC w/ ParallelOldGC
> 	7
> 	11
> 	14
> 	17
> 	20
> G1 before changes
> 	149
> 	156
> 	163
> 	170
> 	177
> G1 after changes
> 	11
> 	13
> 	15
> 	17
> 	19
>
>
> We shall also investigate reducing the work queue sizes, to further 
> reduce the amount of C heap consumed,  for some or all of the 
> collectors - but in a separate CR.
>
> Testing:
> GC test suite on x64 and sparc T-series with a low marking threshold 
> and marking verification enabled; jprt. Our reference workload was 
> used to verify that there was no significant performance difference.
>
> Thanks,
>
> JohnC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120921/bacaaf6e/attachment.htm>

From jon.masamitsu at oracle.com  Fri Sep 21 18:44:54 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 21 Sep 2012 11:44:54 -0700
Subject: Request for review (vs) - 7199923
In-Reply-To: <CABzyjy=Eq-2hdvx_mR4UrsGvwoaeSSr2UCLLJ_rz9Ly=9GGxCg@mail.gmail.com>
References: <505B609D.9030807@oracle.com>	<505B6215.3030405@oracle.com>
	<CABzyjy=Eq-2hdvx_mR4UrsGvwoaeSSr2UCLLJ_rz9Ly=9GGxCg@mail.gmail.com>
Message-ID: <505CB5A6.8030003@oracle.com>



On 9/20/2012 2:39 PM, Srinivas Ramakrishna wrote:
> Looks good. Was it mainly for the system class loader that this turned out
> to be a problem because of the
> very large number of classes it loads, although of course the linear walk
It was probably the system classes but I could not rightly tell from the
profiling.  I saw it with something as simple as GCOld so that it was
the system classes is a good bet.

We don't have a reason for a more efficient lookup of a class
other than this assertion checking so it doesn't seem worth
the code.  We considered a debug flag to control it but even
that seemed too much.

Thanks for the review.

Jon
> can result in quadratic lookup
> complexity which makes it bad in general. (The other thing would be to have
> the set be a tree (or a skip list),
> splitting by some key such as full class name. Anyway, OK to throw away the
> frequent assertion checking for now.)
>
> -- ramki
>
> On Thu, Sep 20, 2012 at 11:36 AM, Jon Masamitsu<jon.masamitsu at oracle.com>wrote:
>
>> 7199923: NPG: tools/javac/T7093325.java timeout
>>
>> The method has_defined() checks that a class is in
>> the classloader's list of classes. has_defined() was
>> used in an assertion when doing marking and
>> adjusting of pointers in a class. Doing that check
>> for every class spends too much time looking
>> down the list of a classloader's classes.
>>
>> http://cr.openjdk.java.net/~**jmasa/7199923/webrev.00/<http://cr.openjdk.java.net/%7Ejmasa/7199923/webrev.00/>
>>
>> I'd like to get this back for testing tonight so my
>> apologies if I cut short the review period.  Please
>> send your comments in any event and I'll fix
>> any problems in a second CR.
>>


From john.coomes at oracle.com  Fri Sep 21 21:48:35 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 21:48:35 +0000
Subject: hg: hsx/hotspot-gc: 3 new changesets
Message-ID: <20120921214835.6088547C4C@hg.openjdk.java.net>

Changeset: 2ba6f4da4bf3
Author:    ohair
Date:      2012-09-18 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2ba6f4da4bf3

7197849: Update new build-infra makefiles
Reviewed-by: ihse, erikj, ohrstrom, tbell

! .hgignore
! Makefile
+ NewMakefile.gmk
! common/autoconf/autogen.sh
! common/autoconf/basics.m4
! common/autoconf/boot-jdk.m4
+ common/autoconf/bootcycle-spec.gmk.in
! common/autoconf/build-aux/config.guess
! common/autoconf/build-performance.m4
! common/autoconf/builddeps.conf.example
! common/autoconf/builddeps.m4
+ common/autoconf/compare.sh.in
! common/autoconf/configure
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh
+ common/autoconf/hotspot-spec.gmk.in
! common/autoconf/jdk-options.m4
! common/autoconf/libraries.m4
! common/autoconf/platform.m4
! common/autoconf/source-dirs.m4
! common/autoconf/spec.gmk.in
! common/autoconf/spec.sh.in
! common/autoconf/toolchain.m4
+ common/bin/boot_cycle.sh
! common/bin/compare-objects.sh
+ common/bin/test_builds.sh
+ common/bin/unicode2x.sed
+ common/makefiles/HotspotWrapper.gmk
! common/makefiles/JavaCompilation.gmk
! common/makefiles/MakeBase.gmk
! common/makefiles/MakeHelpers.gmk
! common/makefiles/Makefile
! common/makefiles/NativeCompilation.gmk
+ common/makefiles/javadoc/CORE_PKGS.gmk
+ common/makefiles/javadoc/Javadoc.gmk
+ common/makefiles/javadoc/NON_CORE_PKGS.gmk
+ common/makefiles/javadoc/Notes.html

Changeset: 522dfac8ca4d
Author:    katleman
Date:      2012-09-19 15:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/522dfac8ca4d

Merge


Changeset: 936702480487
Author:    katleman
Date:      2012-09-20 13:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/936702480487

Added tag jdk8-b57 for changeset 522dfac8ca4d

! .hgtags



From john.coomes at oracle.com  Fri Sep 21 21:48:40 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 21:48:40 +0000
Subject: hg: hsx/hotspot-gc/corba: 3 new changesets
Message-ID: <20120921214843.941EF47C4D@hg.openjdk.java.net>

Changeset: 5c4f045fbd5f
Author:    ohair
Date:      2012-09-18 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/5c4f045fbd5f

7197849: Update new build-infra makefiles
Reviewed-by: ihse, erikj, ohrstrom, tbell

! makefiles/Makefile

Changeset: f3ab4163ae01
Author:    katleman
Date:      2012-09-19 15:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/f3ab4163ae01

Merge


Changeset: 18462a19f7bd
Author:    katleman
Date:      2012-09-20 13:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/18462a19f7bd

Added tag jdk8-b57 for changeset f3ab4163ae01

! .hgtags



From john.coomes at oracle.com  Fri Sep 21 21:48:48 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 21:48:48 +0000
Subject: hg: hsx/hotspot-gc/jaxp: 3 new changesets
Message-ID: <20120921214859.E3DDA47C4E@hg.openjdk.java.net>

Changeset: 2eafc339f7e1
Author:    ohair
Date:      2012-09-18 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/2eafc339f7e1

7197849: Update new build-infra makefiles
Reviewed-by: ihse, erikj, ohrstrom, tbell

! makefiles/Makefile

Changeset: 7c9475c7618c
Author:    katleman
Date:      2012-09-19 15:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/7c9475c7618c

Merge


Changeset: 1cb19abb3f7b
Author:    katleman
Date:      2012-09-20 13:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/1cb19abb3f7b

Added tag jdk8-b57 for changeset 7c9475c7618c

! .hgtags



From john.coomes at oracle.com  Fri Sep 21 21:49:07 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 21:49:07 +0000
Subject: hg: hsx/hotspot-gc/jaxws: 3 new changesets
Message-ID: <20120921214914.E987647C4F@hg.openjdk.java.net>

Changeset: bbcbebb9bc74
Author:    ohair
Date:      2012-09-18 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/bbcbebb9bc74

7197849: Update new build-infra makefiles
Reviewed-by: ihse, erikj, ohrstrom, tbell

! makefiles/Makefile

Changeset: b51b611209f1
Author:    katleman
Date:      2012-09-19 15:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b51b611209f1

Merge


Changeset: cac4c3937063
Author:    katleman
Date:      2012-09-20 13:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/cac4c3937063

Added tag jdk8-b57 for changeset b51b611209f1

! .hgtags



From john.coomes at oracle.com  Fri Sep 21 21:49:25 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 21:49:25 +0000
Subject: hg: hsx/hotspot-gc/jdk: 6 new changesets
Message-ID: <20120921215148.7E31447C50@hg.openjdk.java.net>

Changeset: 71ff959f9a34
Author:    ohair
Date:      2012-09-18 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/71ff959f9a34

7197849: Update new build-infra makefiles
Reviewed-by: ihse, erikj, ohrstrom, tbell

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CopySamples.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataBreakIterator.gmk
! makefiles/GendataFontConfig.gmk
! makefiles/GendataTimeZone.gmk
! makefiles/GenerateClasses.gmk
! makefiles/GenerateData.gmk
! makefiles/GensrcBuffer.gmk
! makefiles/GensrcCharsetCoder.gmk
! makefiles/GensrcIcons.gmk
! makefiles/GensrcJDWP.gmk
! makefiles/GensrcJObjC.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcProperties.gmk
! makefiles/GensrcX11Wrappers.gmk
! makefiles/Images.gmk
! makefiles/Import.gmk
! makefiles/Makefile
! makefiles/Setup.gmk
! makefiles/Tools.gmk
+ makefiles/mapfiles/launchers/mapfile-x86
+ makefiles/mapfiles/launchers/mapfile-x86_64
+ makefiles/mapfiles/libawt_headless/reorder-x86
! makefiles/mapfiles/libjava/mapfile-vers
+ makefiles/mapfiles/libjava/reorder-x86
! makefiles/mapfiles/libjli/mapfile-vers
+ makefiles/mapfiles/libjpeg/reorder-x86
! makefiles/mapfiles/libnio/mapfile-linux
+ makefiles/mapfiles/libnio/mapfile-macosx
! makefiles/mapfiles/libnio/mapfile-solaris
+ makefiles/mapfiles/libnio/reorder-x86
+ makefiles/mapfiles/libverify/reorder-x86
! makefiles/mapfiles/libzip/mapfile-vers
+ makefiles/mapfiles/libzip/reorder-x86

Changeset: dcbcecbe7b23
Author:    ohair
Date:      2012-09-18 12:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dcbcecbe7b23

7198325: Fix more $(sort) issues on lnk commands in makefiles, making binaries more consistent
7130909: Add a more general mechanism for customizing the build logic
Reviewed-by: dholmes, tbell, erikj, ihse, ohrstrom

! make/Makefile
! make/com/sun/java/pack/Makefile
! make/common/Defs.gmk
! make/common/Release.gmk
! make/java/jli/Makefile

Changeset: ab1523b7ca2a
Author:    dholmes
Date:      2012-09-19 04:26 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ab1523b7ca2a

7199410: Remove files that were omitted from 7130909 changeset
Reviewed-by: ohair

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk

Changeset: 51594d095a4b
Author:    katleman
Date:      2012-09-19 15:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/51594d095a4b

Merge


Changeset: 34202653829a
Author:    katleman
Date:      2012-09-20 13:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/34202653829a

Added tag jdk8-b57 for changeset 51594d095a4b

! .hgtags

Changeset: 1dde94130b0c
Author:    jcoomes
Date:      2012-09-21 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1dde94130b0c

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk



From john.coomes at oracle.com  Fri Sep 21 21:53:14 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 21 Sep 2012 21:53:14 +0000
Subject: hg: hsx/hotspot-gc/langtools: 3 new changesets
Message-ID: <20120921215322.2835D47C51@hg.openjdk.java.net>

Changeset: 463fea75b618
Author:    ohair
Date:      2012-09-18 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/463fea75b618

7197849: Update new build-infra makefiles
Reviewed-by: ihse, erikj, ohrstrom, tbell

! makefiles/Makefile

Changeset: 86d5740b9fdc
Author:    katleman
Date:      2012-09-19 15:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/86d5740b9fdc

Merge


Changeset: bc42f20bfe48
Author:    katleman
Date:      2012-09-20 13:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bc42f20bfe48

Added tag jdk8-b57 for changeset 86d5740b9fdc

! .hgtags



From john.cuthbertson at oracle.com  Fri Sep 21 23:37:18 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 21 Sep 2012 16:37:18 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during marking
	verification
Message-ID: <505CFA2E.70809@oracle.com>

Hi Everyone,

Can I have a couple of volunteers look over the fix for this CR? The 
webrev can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.0/

Summary:
The clipping in the code that sets the bits for a range of cards in the 
"expected" card bitmap that we check the liveness accounting data 
against was incorrect. This could lead to spurious verification 
failures. In addition to fixing the clipping, I've upleveled this 
routine and moved it into ConcurrentMark and now use it to generate the 
real liveness data.

Testing:
The failing test cases with marking verification; jprt.

Thanks,

JohnC


From jesper.wilhelmsson at oracle.com  Sat Sep 22 04:16:57 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Sat, 22 Sep 2012 06:16:57 +0200
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <505CFA2E.70809@oracle.com>
References: <505CFA2E.70809@oracle.com>
Message-ID: <8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>

John,

Looks good!

Would it make sense to change set_card_bitmap_range to be exclusive, or even to take a start and a size of the area? I think inclusive functions like this one are unintuitive, especially when the only use of last_idx is used with a +1. Maybe that's a different change?
/Jesper



22 sep 2012 kl. 01:37 skrev John Cuthbertson <john.cuthbertson at oracle.com>:

> Hi Everyone,
> 
> Can I have a couple of volunteers look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
> 
> Summary:
> The clipping in the code that sets the bits for a range of cards in the "expected" card bitmap that we check the liveness accounting data against was incorrect. This could lead to spurious verification failures. In addition to fixing the clipping, I've upleveled this routine and moved it into ConcurrentMark and now use it to generate the real liveness data.
> 
> Testing:
> The failing test cases with marking verification; jprt.
> 
> Thanks,
> 
> JohnC


From jon.masamitsu at oracle.com  Sat Sep 22 05:48:48 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 21 Sep 2012 22:48:48 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
References: <505CFA2E.70809@oracle.com>
	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
Message-ID: <505D5140.2070002@oracle.com>

I'm used to seeing a range like [start, end).  That the second index is 
named
last_idx helps but if I were just looking at the call site, I would have 
guessed
wrongly - i.e., thinking it was [start, end).

Jon

On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
> John,
>
> Looks good!
>
> Would it make sense to change set_card_bitmap_range to be exclusive, or even to take a start and a size of the area? I think inclusive functions like this one are unintuitive, especially when the only use of last_idx is used with a +1. Maybe that's a different change?
> /Jesper
>
>
>
> 22 sep 2012 kl. 01:37 skrev John Cuthbertson<john.cuthbertson at oracle.com>:
>
>> Hi Everyone,
>>
>> Can I have a couple of volunteers look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>
>> Summary:
>> The clipping in the code that sets the bits for a range of cards in the "expected" card bitmap that we check the liveness accounting data against was incorrect. This could lead to spurious verification failures. In addition to fixing the clipping, I've upleveled this routine and moved it into ConcurrentMark and now use it to generate the real liveness data.
>>
>> Testing:
>> The failing test cases with marking verification; jprt.
>>
>> Thanks,
>>
>> JohnC


From alejandro.murillo at oracle.com  Sat Sep 22 11:00:25 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 22 Sep 2012 11:00:25 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 4 new changesets
Message-ID: <20120922110109.6EFA447C6F@hg.openjdk.java.net>

Changeset: da0d652d0c2f
Author:    katleman
Date:      2012-09-20 13:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da0d652d0c2f

Added tag jdk8-b57 for changeset d70102c4cb73

! .hgtags

Changeset: 5f54277c67f7
Author:    amurillo
Date:      2012-09-21 14:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5f54277c67f7

Merge

! .hgtags
- agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java
- agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java
- make/solaris/makefiles/reorder_COMPILER1_amd64
- make/solaris/makefiles/reorder_COMPILER1_i486
- make/solaris/makefiles/reorder_COMPILER1_sparc
- make/solaris/makefiles/reorder_COMPILER1_sparcv9
- make/solaris/makefiles/reorder_COMPILER2_amd64
- make/solaris/makefiles/reorder_COMPILER2_i486
- make/solaris/makefiles/reorder_COMPILER2_sparc
- make/solaris/makefiles/reorder_COMPILER2_sparcv9
- make/solaris/makefiles/reorder_CORE_i486
- make/solaris/makefiles/reorder_CORE_sparc
- make/solaris/makefiles/reorder_CORE_sparcv9
- make/solaris/makefiles/reorder_TIERED_amd64
- make/solaris/makefiles/reorder_TIERED_i486
- make/solaris/makefiles/reorder_TIERED_sparc
- make/solaris/makefiles/reorder_TIERED_sparcv9
- make/solaris/reorder.sh
- src/cpu/sparc/vm/dump_sparc.cpp
- src/cpu/x86/vm/dump_x86_32.cpp
- src/cpu/x86/vm/dump_x86_64.cpp
- src/cpu/zero/vm/dump_zero.cpp
- src/share/vm/ci/ciArrayKlassKlass.hpp
- src/share/vm/ci/ciCPCache.cpp
- src/share/vm/ci/ciCPCache.hpp
- src/share/vm/ci/ciInstanceKlassKlass.cpp
- src/share/vm/ci/ciInstanceKlassKlass.hpp
- src/share/vm/ci/ciKlassKlass.cpp
- src/share/vm/ci/ciKlassKlass.hpp
- src/share/vm/ci/ciMethodKlass.cpp
- src/share/vm/ci/ciMethodKlass.hpp
- src/share/vm/ci/ciObjArrayKlassKlass.cpp
- src/share/vm/ci/ciObjArrayKlassKlass.hpp
- src/share/vm/ci/ciTypeArrayKlassKlass.cpp
- src/share/vm/ci/ciTypeArrayKlassKlass.hpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp
- src/share/vm/memory/classify.cpp
- src/share/vm/memory/classify.hpp
- src/share/vm/memory/compactPermGen.hpp
- src/share/vm/memory/compactingPermGenGen.cpp
- src/share/vm/memory/compactingPermGenGen.hpp
- src/share/vm/memory/dump.cpp
- src/share/vm/memory/permGen.cpp
- src/share/vm/memory/permGen.hpp
- src/share/vm/memory/restore.cpp
- src/share/vm/memory/serialize.cpp
- src/share/vm/oops/arrayKlassKlass.cpp
- src/share/vm/oops/arrayKlassKlass.hpp
- src/share/vm/oops/compiledICHolderKlass.cpp
- src/share/vm/oops/compiledICHolderKlass.hpp
- src/share/vm/oops/compiledICHolderOop.cpp
- src/share/vm/oops/compiledICHolderOop.hpp
- src/share/vm/oops/constMethodKlass.cpp
- src/share/vm/oops/constMethodKlass.hpp
- src/share/vm/oops/constMethodOop.cpp
- src/share/vm/oops/constMethodOop.hpp
- src/share/vm/oops/constantPoolKlass.cpp
- src/share/vm/oops/constantPoolKlass.hpp
- src/share/vm/oops/constantPoolOop.cpp
- src/share/vm/oops/constantPoolOop.hpp
- src/share/vm/oops/cpCacheKlass.cpp
- src/share/vm/oops/cpCacheKlass.hpp
- src/share/vm/oops/cpCacheOop.cpp
- src/share/vm/oops/cpCacheOop.hpp
- src/share/vm/oops/instanceKlassKlass.cpp
- src/share/vm/oops/instanceKlassKlass.hpp
- src/share/vm/oops/klassKlass.cpp
- src/share/vm/oops/klassKlass.hpp
- src/share/vm/oops/klassOop.cpp
- src/share/vm/oops/klassOop.hpp
- src/share/vm/oops/methodDataKlass.cpp
- src/share/vm/oops/methodDataKlass.hpp
- src/share/vm/oops/methodDataOop.cpp
- src/share/vm/oops/methodDataOop.hpp
- src/share/vm/oops/methodKlass.cpp
- src/share/vm/oops/methodKlass.hpp
- src/share/vm/oops/methodOop.cpp
- src/share/vm/oops/methodOop.hpp
- src/share/vm/oops/objArrayKlassKlass.cpp
- src/share/vm/oops/objArrayKlassKlass.hpp
- src/share/vm/oops/typeArrayKlassKlass.cpp
- src/share/vm/oops/typeArrayKlassKlass.hpp

Changeset: 6bb378c50828
Author:    amurillo
Date:      2012-09-21 14:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bb378c50828

Added tag hs25-b02 for changeset 5f54277c67f7

! .hgtags

Changeset: 04ed664b7e30
Author:    amurillo
Date:      2012-09-21 14:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04ed664b7e30

7200236: new hotspot build - hs25-b03
Reviewed-by: jcoomes

! make/hotspot_version



From bengt.rutisson at oracle.com  Mon Sep 24 06:44:34 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 24 Sep 2012 08:44:34 +0200
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <505CFA2E.70809@oracle.com>
References: <505CFA2E.70809@oracle.com>
Message-ID: <50600152.1040102@oracle.com>


Hi John,

The actual bug fix looks good. Nice catch! I'll let you battle out the 
inclusion/exclusion boundary values with Jesper and Jon.

I like that you moved set_card_bitmap_range() to ConcurrentMark. One 
question about the <= 8 optimization. I think it would be nice if 
set_card_bitmap_range() didn't have to worry about that. To me it seems 
more like the responsibility of the Bitmap. Maybe we can move that 
optimization in to par_at_put_range() / set_range() ? That way all users 
of these method will get the benefit of the optimization.

Actually there already seem to exist a concept inside Bitmap to handle 
different range sizes. I didn't look very closely, but the RangeSizeHint 
concept seem to address the same issue, right? Can we consolidate this 
somehow?

Thanks,
Bengt


On 2012-09-22 01:37, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers look over the fix for this CR? The 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>
> Summary:
> The clipping in the code that sets the bits for a range of cards in 
> the "expected" card bitmap that we check the liveness accounting data 
> against was incorrect. This could lead to spurious verification 
> failures. In addition to fixing the clipping, I've upleveled this 
> routine and moved it into ConcurrentMark and now use it to generate 
> the real liveness data.
>
> Testing:
> The failing test cases with marking verification; jprt.
>
> Thanks,
>
> JohnC



From jesper.wilhelmsson at oracle.com  Mon Sep 24 13:57:30 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 24 Sep 2012 15:57:30 +0200
Subject: RFR (S) Make tenuring threshold unsigned
Message-ID: <506066CA.8090402@oracle.com>

Hi,

While working on a different change I noticed that the tenuring threshold was 
stored in a signed int. This struck me as odd, and since I wanted to avoid 
some unintuitive casts in my other change I would prefer to change the 
threshold to an unsigned.

The change is available here:

http://cr.openjdk.java.net/~jwilhelm/TenuringThreshold/

Several files are touched but there's just type changes in a few places per file.

In this change I also change the declared type of -XX:MaxTenuringThreshold and 
-XX:InitialTenuringThreshold to uintx. This should not be a problem since we 
don't allow negative values for these flags anyway.
/Jesper


From john.cuthbertson at oracle.com  Mon Sep 24 17:00:55 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 24 Sep 2012 10:00:55 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
References: <505CFA2E.70809@oracle.com>
	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
Message-ID: <506091C7.20405@oracle.com>

Hi Jesper,

Thanks for review. That is a good idea (and we have entertained doing it 
in the past) but is does have a slight downside.

We need to set bits for all the cards spanned by a live object - 
including the last card if the object doesn't end at a card boundary. If 
we made set_card_bitmap_range() exclusive we end up moving the logic to 
determine which card index would be the second parameter into the 
callers (or a utility routine). The logic in the caller becomes 
something like:

HeapWord* end = obj + obj->size();
idx_t end_idx = card_bitmap_index_for(end);
if (!card_aligned(end)) {
// Next object doesn't start on a card boundary.We need to also include 
the card in which the current object ends.
end_idx += 1;
}
set_card_bitmap_range(start_idx, end_idx);

versus:

HeapWord* last = obj + obj->size() - 1;
idx_t last_idx = card_bitmap_index_for(last)
set_card_bitmap_range(start_idx, last_idx)

The mapping from the inclusive range to cards to the exclusive range 
expected by the bitmap routines is localized in set_card_bitmap_range().

I don't think either is really better than the other.

JohnC

On 09/21/12 21:16, Jesper Wilhelmsson wrote:
> John,
>
> Looks good!
>
> Would it make sense to change set_card_bitmap_range to be exclusive, or even to take a start and a size of the area? I think inclusive functions like this one are unintuitive, especially when the only use of last_idx is used with a +1. Maybe that's a different change?
> /Jesper
>
>
>
> 22 sep 2012 kl. 01:37 skrev John Cuthbertson <john.cuthbertson at oracle.com>:
>
>   
>> Hi Everyone,
>>
>> Can I have a couple of volunteers look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>
>> Summary:
>> The clipping in the code that sets the bits for a range of cards in the "expected" card bitmap that we check the liveness accounting data against was incorrect. This could lead to spurious verification failures. In addition to fixing the clipping, I've upleveled this routine and moved it into ConcurrentMark and now use it to generate the real liveness data.
>>
>> Testing:
>> The failing test cases with marking verification; jprt.
>>
>> Thanks,
>>
>> JohnC
>>     



From john.cuthbertson at oracle.com  Mon Sep 24 17:03:11 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 24 Sep 2012 10:03:11 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <505D5140.2070002@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
	<505D5140.2070002@oracle.com>
Message-ID: <5060924F.6090705@oracle.com>

Hi Jon,

Thanks for the comments. I'm going to refer you to my reply to Jesper. 
If people feel strongly about making the routine exclusive - I'll make 
it so.

JohnC

On 09/21/12 22:48, Jon Masamitsu wrote:
> I'm used to seeing a range like [start, end).  That the second index 
> is named
> last_idx helps but if I were just looking at the call site, I would 
> have guessed
> wrongly - i.e., thinking it was [start, end).
>
> Jon
>
> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>> John,
>>
>> Looks good!
>>
>> Would it make sense to change set_card_bitmap_range to be exclusive, 
>> or even to take a start and a size of the area? I think inclusive 
>> functions like this one are unintuitive, especially when the only use 
>> of last_idx is used with a +1. Maybe that's a different change?
>> /Jesper
>>
>>
>>
>> 22 sep 2012 kl. 01:37 skrev John 
>> Cuthbertson<john.cuthbertson at oracle.com>:
>>
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers look over the fix for this CR? The 
>>> webrev can be found at: 
>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>
>>> Summary:
>>> The clipping in the code that sets the bits for a range of cards in 
>>> the "expected" card bitmap that we check the liveness accounting 
>>> data against was incorrect. This could lead to spurious verification 
>>> failures. In addition to fixing the clipping, I've upleveled this 
>>> routine and moved it into ConcurrentMark and now use it to generate 
>>> the real liveness data.
>>>
>>> Testing:
>>> The failing test cases with marking verification; jprt.
>>>
>>> Thanks,
>>>
>>> JohnC



From john.cuthbertson at oracle.com  Mon Sep 24 17:23:38 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 24 Sep 2012 10:23:38 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <50600152.1040102@oracle.com>
References: <505CFA2E.70809@oracle.com> <50600152.1040102@oracle.com>
Message-ID: <5060971A.4070409@oracle.com>

Hi Bengt,

Thanks for the review.

The small range vs larger range was done purely because of what Tony and 
I saw in collect profiles. From the profiles, the bitmap routines 
were/are not (always) inlined (we couldn't figure out why). Also at 8 
iterations the loop was completely unrolled with the Solaris Studio 
compilers.

With the additional code, that may no longer the be the case but I 
suspect it might be since the is_par parameter should be folded away 
when the routine is inlined.

JohnC

On 09/23/12 23:44, Bengt Rutisson wrote:
>
> Hi John,
>
> The actual bug fix looks good. Nice catch! I'll let you battle out the 
> inclusion/exclusion boundary values with Jesper and Jon.
>
> I like that you moved set_card_bitmap_range() to ConcurrentMark. One 
> question about the <= 8 optimization. I think it would be nice if 
> set_card_bitmap_range() didn't have to worry about that. To me it 
> seems more like the responsibility of the Bitmap. Maybe we can move 
> that optimization in to par_at_put_range() / set_range() ? That way 
> all users of these method will get the benefit of the optimization.
>
> Actually there already seem to exist a concept inside Bitmap to handle 
> different range sizes. I didn't look very closely, but the 
> RangeSizeHint concept seem to address the same issue, right? Can we 
> consolidate this somehow?
>
> Thanks,
> Bengt
>
>
> On 2012-09-22 01:37, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers look over the fix for this CR? The 
>> webrev can be found at: 
>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>
>> Summary:
>> The clipping in the code that sets the bits for a range of cards in 
>> the "expected" card bitmap that we check the liveness accounting data 
>> against was incorrect. This could lead to spurious verification 
>> failures. In addition to fixing the clipping, I've upleveled this 
>> routine and moved it into ConcurrentMark and now use it to generate 
>> the real liveness data.
>>
>> Testing:
>> The failing test cases with marking verification; jprt.
>>
>> Thanks,
>>
>> JohnC
>



From jesper.wilhelmsson at oracle.com  Mon Sep 24 17:46:54 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 24 Sep 2012 19:46:54 +0200
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <506091C7.20405@oracle.com>
References: <505CFA2E.70809@oracle.com>
	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
	<506091C7.20405@oracle.com>
Message-ID: <50609C8E.7@oracle.com>

On 2012-09-24 19:00, John Cuthbertson wrote:
> Hi Jesper,
>
> Thanks for review. That is a good idea (and we have entertained doing it in
> the past) but is does have a slight downside.
>
> We need to set bits for all the cards spanned by a live object - including the
> last card if the object doesn't end at a card boundary. If we made
> set_card_bitmap_range() exclusive we end up moving the logic to determine
> which card index would be the second parameter into the callers (or a utility
> routine). The logic in the caller becomes something like:
>
> HeapWord* end = obj + obj->size();
> idx_t end_idx = card_bitmap_index_for(end);
> if (!card_aligned(end)) {
> // Next object doesn't start on a card boundary.We need to also include the
> card in which the current object ends.
> end_idx += 1;
> }
> set_card_bitmap_range(start_idx, end_idx);
>
> versus:
>
> HeapWord* last = obj + obj->size() - 1;
> idx_t last_idx = card_bitmap_index_for(last)
> set_card_bitmap_range(start_idx, last_idx)
>
> The mapping from the inclusive range to cards to the exclusive range expected
> by the bitmap routines is localized in set_card_bitmap_range().
>
> I don't think either is really better than the other.

set_card_bitmap_range seems to be called from three places. If I'm not 
mistaken only one of these calls have a end index based on an object that 
might stretch in to an extra card. On the contrary it seems as if the two 
other call sites have some extra logic imposed on them because of the set 
function being inclusive. Again, I may be wrong as I don't know the code very 
well.

If it is the case that only one call site needs the extra code in your example 
then I think set_card_bitmap_range should be changed to be exclusive. If the 
extra code is needed in all three places it may be better to keep it as it is.
/Jesper


>
> JohnC
>
> On 09/21/12 21:16, Jesper Wilhelmsson wrote:
>> John,
>>
>> Looks good!
>>
>> Would it make sense to change set_card_bitmap_range to be exclusive, or even
>> to take a start and a size of the area? I think inclusive functions like
>> this one are unintuitive, especially when the only use of last_idx is used
>> with a +1. Maybe that's a different change?
>> /Jesper
>>
>>
>>
>> 22 sep 2012 kl. 01:37 skrev John Cuthbertson <john.cuthbertson at oracle.com>:
>>
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers look over the fix for this CR? The webrev
>>> can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>
>>> Summary:
>>> The clipping in the code that sets the bits for a range of cards in the
>>> "expected" card bitmap that we check the liveness accounting data against
>>> was incorrect. This could lead to spurious verification failures. In
>>> addition to fixing the clipping, I've upleveled this routine and moved it
>>> into ConcurrentMark and now use it to generate the real liveness data.
>>>
>>> Testing:
>>> The failing test cases with marking verification; jprt.
>>>
>>> Thanks,
>>>
>>> JohnC
>


From jon.masamitsu at oracle.com  Mon Sep 24 21:46:47 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 24 Sep 2012 14:46:47 -0700
Subject: Request for review (s) - 7198873
Message-ID: <5060D4C7.9080306@oracle.com>

NPG: VM Does not unload classes with UseConcMarkSweepGC

If CMS is not doing class unloading, don't start a concurrent
collection for classloader (and metadata) collection (since
it won't happen without class unloading).

http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/

Also, refactored the code for readability and guarded extra
output with Verbose.

Thanks.

Jon


From jon.masamitsu at oracle.com  Mon Sep 24 23:09:29 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 24 Sep 2012 16:09:29 -0700
Subject: Request for review (vs) - 7200615
Message-ID: <5060E829.8010908@oracle.com>

7200615: NPG: optimized VM build is broken

Fixed 2 mismatches between declarations and definitions
with regard to #ifndef PRODUCT and
#ifdef ASSERT

http://cr.openjdk.java.net/~jmasa/7200615/webrev.00/


From vladimir.kozlov at oracle.com  Mon Sep 24 23:11:32 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 24 Sep 2012 16:11:32 -0700
Subject: Request for review (vs) - 7200615
In-Reply-To: <5060E829.8010908@oracle.com>
References: <5060E829.8010908@oracle.com>
Message-ID: <5060E8A4.3010602@oracle.com>

Good.

Vladimir

Jon Masamitsu wrote:
> 7200615: NPG: optimized VM build is broken
> 
> Fixed 2 mismatches between declarations and definitions
> with regard to #ifndef PRODUCT and
> #ifdef ASSERT
> 
> http://cr.openjdk.java.net/~jmasa/7200615/webrev.00/


From bengt.rutisson at oracle.com  Tue Sep 25 12:15:50 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 25 Sep 2012 14:15:50 +0200
Subject: Request for review (XS): 7197906:
	BlockOffsetArray::power_to_cards_back()
	needs to handle > 32 bit shifts
In-Reply-To: <5057834A.7000201@oracle.com>
References: <CAKz_je6M0dr=UaBDnf7k+wA6FpnV=7KnQhWSZiSD1SEZxKZW6A@mail.gmail.com>
	<CAKz_je43bvYHehXdZOadi7J12epkqn=FL_x4Dn0vCoc6356Kkw@mail.gmail.com>
	<CABzyjynMaXfgPJba9AKLsrWVA1Q43Fjet4SLoD-OUdUSLKr+xQ@mail.gmail.com>
	<505233BB.4070909@oracle.com>
	<CABzyjynm8mPN=TvFAmDStiXyPONkj=Y_QuZzeUD_GN17nOeT6A@mail.gmail.com>
	<505269E4.9040301@oracle.com>
	<CABzyjynqngYEETuJNERZUta8L4OLAQjWWbipp77a0u5OSGAE+g@mail.gmail.com>
	<5057834A.7000201@oracle.com>
Message-ID: <5061A076.8050201@oracle.com>


Another FYI: Last week I pushed the fix to the HS24 repository:
http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9c930c24f9b0

This will most likely go in to the next 7update release. With the 
current planning this means 7u12.

Bengt


On 2012-09-17 22:08, Bengt Rutisson wrote:
>
> FYI, I pushed this earlier today so the fix is now available in 
> hotspot-gc:
> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/859cd1a76f8a
>
> I've also filed a sub CR to backport the fix to hs24/7u12. I hope we 
> get approval to push it there soon.
>
> Thanks again for the patch Hal!
> Bengt
>
> On 2012-09-14 01:26, Srinivas Ramakrishna wrote:
>>
>> Great, thanks John, all!
>>
>> -- ramki
>>
>> On Fri, Sep 14, 2012 at 12:19 AM, John Cuthbertson 
>> <john.cuthbertson at oracle.com <mailto:john.cuthbertson at oracle.com>> wrote:
>>
>>     Hi Ramki,
>>
>>     I don't think there will be an issue with back porting this to
>>     hs24 (which I think is going into 7u12). I just have to check the
>>     dates. There's a couple of other CRs that we're probably going to
>>     want to back port as well.
>>
>>     I searched the sources for the offending pattern (with and
>>     without whitespace) and only found the instances fixed by Hal. I
>>     think we're OK in that respect. But thanks for making sure. :)
>>
>>     JohnC
>>
>>
>>     On 09/13/12 15:21, Srinivas Ramakrishna wrote:
>>>
>>>     Thanks Bengt; changes look good to me too, Hal, although i just
>>>     looked at the changes, and did not
>>>     check the code to see if there might be more instances of the
>>>     fingered anti-pattern. (I am pretty sure
>>>     you and John and other reviewers have covered that front well :-)
>>>
>>>     Bengt, any chance that the fix will get bkported also to 7uXX
>>>     soon, for some suitable value of XX?
>>>
>>>     thanks!
>>>     -- ramki
>>>
>>>     On Thu, Sep 13, 2012 at 8:27 PM, Bengt Rutisson
>>>     <bengt.rutisson at oracle.com <mailto:bengt.rutisson at oracle.com>>
>>>     wrote:
>>>
>>>
>>>         Hi Ramki,
>>>
>>>         Thanks for looking at this!
>>>
>>>         Here's a webrev based on the second patch that Hal sent out:
>>>         http://cr.openjdk.java.net/~brutisso/7197906/webrev.02/
>>>         <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.02/>
>>>
>>>         Bengt
>>>
>>>
>>>         On 2012-09-13 18:12, Srinivas Ramakrishna wrote:
>>>>         Hal, thanks for the catch and the fix!
>>>>
>>>>         Bengt, might it be possible to host this as a traditional
>>>>         webrev in the usual place, to simplify review logistics?
>>>>
>>>>         thanks!
>>>>         -- ramki
>>>>
>>>>         On Thu, Sep 13, 2012 at 4:55 PM, Jianhao Mo
>>>>         <mojianhao at gmail.com <mailto:mojianhao at gmail.com>> wrote:
>>>>
>>>>             Hi all,
>>>>
>>>>             Attached please find the new patch, modified according
>>>>             to John's advice.
>>>>
>>>>             Thanks Bengt again for the help :)
>>>>
>>>>             Regards,
>>>>
>>>>             Hal
>>>>
>>>>             2012/9/12 Jianhao Mo <mojianhao at gmail.com
>>>>             <mailto:mojianhao at gmail.com>>
>>>>
>>>>                 Hi all,
>>>>
>>>>                 Could I get a couple of reviews for this small
>>>>                 patch, please?
>>>>
>>>>                 7197906: BlockOffsetArray::power_to_cards_back()
>>>>                 needs to handle > 32 bit shifts
>>>>
>>>>                 CR link:
>>>>                 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197906
>>>>                 Webrev:
>>>>                 http://cr.openjdk.java.net/~brutisso/7197906/webrev.01/
>>>>                 <http://cr.openjdk.java.net/%7Ebrutisso/7197906/webrev.01/>
>>>>                 Contributed-by:
>>>>                 Hal Mo <kungu.mjh at taobao.com
>>>>                 <mailto:kungu.mjh at taobao.com>> from Alibaba
>>>>                 Group(with OCA)
>>>>
>>>>                 It may take a while before the CR link is publicly
>>>>                 accessible.
>>>>
>>>>                 In blockOffsetTable.hpp, there is an unexpected
>>>>                 data truncation in power_to_cards_back(uint i),
>>>>                 which may lead to crashing the VM on very large GC
>>>>                 heaps.
>>>>                 The problem could be reproduced easily on machines,
>>>>                 that have enough memory, with:
>>>>                 $ java -Xmx135g -XX:+UseConcMarkSweepGC
>>>>
>>>>                 The proposed patch fixes this problem, and builds
>>>>                 on all OpenJDK supported platforms.
>>>>
>>>>                 I'd like to thank Bengt Rutisson for the initial
>>>>                 review and help preparing the CR and Webrev.
>>>>
>>>>                 Regards,
>>>>                 Hal 
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120925/6897ae0b/attachment.htm>

From jon.masamitsu at oracle.com  Tue Sep 25 13:41:21 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 25 Sep 2012 06:41:21 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <5060924F.6090705@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
	<505D5140.2070002@oracle.com> <5060924F.6090705@oracle.com>
Message-ID: <5061B481.6090803@oracle.com>

John,

Is it common practice in G1 code to have the ranges
be inclusive?

Jon

PS.  Sorry for being tardy on my reply - so much mail,
so little time :-)

On 09/24/12 10:03, John Cuthbertson wrote:
> Hi Jon,
>
> Thanks for the comments. I'm going to refer you to my reply to Jesper. 
> If people feel strongly about making the routine exclusive - I'll make 
> it so.
>
> JohnC
>
> On 09/21/12 22:48, Jon Masamitsu wrote:
>> I'm used to seeing a range like [start, end).  That the second index 
>> is named
>> last_idx helps but if I were just looking at the call site, I would 
>> have guessed
>> wrongly - i.e., thinking it was [start, end).
>>
>> Jon
>>
>> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>>> John,
>>>
>>> Looks good!
>>>
>>> Would it make sense to change set_card_bitmap_range to be exclusive, 
>>> or even to take a start and a size of the area? I think inclusive 
>>> functions like this one are unintuitive, especially when the only 
>>> use of last_idx is used with a +1. Maybe that's a different change?
>>> /Jesper
>>>
>>>
>>>
>>> 22 sep 2012 kl. 01:37 skrev John 
>>> Cuthbertson<john.cuthbertson at oracle.com>:
>>>
>>>> Hi Everyone,
>>>>
>>>> Can I have a couple of volunteers look over the fix for this CR? 
>>>> The webrev can be found at: 
>>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>>
>>>> Summary:
>>>> The clipping in the code that sets the bits for a range of cards in 
>>>> the "expected" card bitmap that we check the liveness accounting 
>>>> data against was incorrect. This could lead to spurious 
>>>> verification failures. In addition to fixing the clipping, I've 
>>>> upleveled this routine and moved it into ConcurrentMark and now use 
>>>> it to generate the real liveness data.
>>>>
>>>> Testing:
>>>> The failing test cases with marking verification; jprt.
>>>>
>>>> Thanks,
>>>>
>>>> JohnC
>


From jesper.wilhelmsson at oracle.com  Tue Sep 25 14:16:14 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 25 Sep 2012 16:16:14 +0200
Subject: [PATCH] 7189971: Implement CMSWaitDuration for non-incremental
	mode of CMS
In-Reply-To: <CABzyjyk95Q0edSwSJzktthc7JHN+5jMwHsg_5++9Uftkur4WwQ@mail.gmail.com>
References: <M9FC1G$F19EE6753EB207E2E8CE3E81E768E71B@frajt.eu>
	<CABzyjyk95Q0edSwSJzktthc7JHN+5jMwHsg_5++9Uftkur4WwQ@mail.gmail.com>
Message-ID: <5061BCAE.4070808@oracle.com>

Hi Michal,

Thank you for your contribution! I have attached your patches to CR 7189971.

As Ramki mentioned in his mail, you need to complete the contributor agreement 
before we can use the patch. Once this is done we can have a look at the 
patches and find someone to shepherd the change.

It's not as easy as just applying the patches though. To avoid creating a 
regression from JDK 7 to JDK 8 we need to fix the problem in the current hsx 
repositories first and then backport it to 7u and 6.

Regards,
/Jesper


On 2012-08-30 10:05, Srinivas Ramakrishna wrote:
> Hi Michal -- Thanks so much for the patch... (hopefully you have or will 
> complete the contributor agreement that will allow the patch to be used). I 
> will definitely try and review the patch over the next day or two as soon as 
> i find a few spare cycles.
>
> thanks!
> -- ramki
>
> On Mon, Aug 27, 2012 at 10:17 AM, Michal Frajt <michal at frajt.eu 
> <mailto:michal at frajt.eu>> wrote:
>
>     Hi Ramki / Jon,
>     Please find the patch for the CMSWaitDuration unstable behavior issue.
>     The patch keeps the method wait_on_cms_lock untouched for the calls from
>     the abortable_preclean phase (not very correct behaviour but still
>     acceptable for the abortable preclean 'short break' calls between the
>     preclean work iterations). The new method wait_on_cms_lock_for_scavenge
>     has been added. The method monitors the CGC_lock for notifications,
>     handles the full wait time interval, checks the scavenge occurrence by
>     the total_collections counter changing its value. When reviewing please
>     mind that the allowed locking order in the CMS thread should be
>     FreelistHolder -> Heap_lock -> CGC_lock (based on a source code comment
>     but the collect_in_background method is using reverted order between the
>     Freelist and the Heap_lock ??). The sleepBeforeNextCycle method is now
>     using the new wait_on_cms_lock_for_scavenge method for both the normal
>     and the incremental CMS mode.
>     The patch has been prepared for the openjdk6 and openjdk7u. The openjdk6
>     got compiled and tested on solaris-amd64 platform. The openjdk7u got
>     compiled without much testing (we have jdk6 application environment only).
>     You additionally suggested to have an explicit flag such as
>     CMSScavengeBeforeInitialMark. I already replied to it but it did not get
>     into the posting list (sent from another email address). The idea of the
>     CMSScavengeBeforeInitialMark could be easier to implement but we strongly
>     prefer not to invoke yet another scavenge explicitly as it is unbalancing
>     young objects aging and leads to unwanted promotions. I could think about
>     a combined solution when it first waits for the CMSWaitDuration and, if
>     there is no scavenge occurring, it is explicitly invoking a scavenge
>     before the inital-mark phase (or better pause) starts.
>     Regards,
>     Michal
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120925/b96b2de5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jesper_wilhelmsson.vcf
Type: text/x-vcard
Size: 251 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120925/b96b2de5/jesper_wilhelmsson.vcf>

From mikael.gerdin at oracle.com  Tue Sep 25 14:23:14 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 25 Sep 2012 16:23:14 +0200
Subject: Request for review (s) - 7198873
In-Reply-To: <5060D4C7.9080306@oracle.com>
References: <5060D4C7.9080306@oracle.com>
Message-ID: <5061BE52.2020902@oracle.com>

Jon,

On 2012-09-24 23:46, Jon Masamitsu wrote:
> NPG: VM Does not unload classes with UseConcMarkSweepGC
>
> If CMS is not doing class unloading, don't start a concurrent
> collection for classloader (and metadata) collection (since
> it won't happen without class unloading).

It looks like you still unconditionally call expand_and_allocate when 
running with CMS, no matter the value of CMSClassUnloadingEnabled.
I think that the code:

  213       // For CMS expand since the collection is going to be 
concurrent.
  214       _result =
  215 
_loader_data->metaspace_non_null()->expand_and_allocate(_size, _mdtype);

Should be inside the "if (CMSClassUnloadingEnabled)" and if running 
without it set then CMS users will have to take the hit of a stw full gc 
when running into the metadata threshold.

/Mikael

>
> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>
> Also, refactored the code for readability and guarded extra
> output with Verbose.
>
> Thanks.
>
> Jon

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From jon.masamitsu at oracle.com  Tue Sep 25 16:23:23 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 25 Sep 2012 09:23:23 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <5061BE52.2020902@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
Message-ID: <5061DA7B.2000804@oracle.com>

Mikael,

Thanks for the review.

The expand_and_allocate() does not do a GC.  It expands
the Metaspace and does an allocation from the expanded
space.  Only if that fails does the CMS case fall through to
the full GC.

The policy for CMS is

1) Hitting the HWM should start a concurrent collection if
CMS is doing class unloading.
2) Always  expand the Metaspace and allocate from
the expanded space.
3) If expanding the Metaspace does not provide any free
space, do a full GC to reclaim classloaders and class metadata
and then retry the allocation.

Jon


On 09/25/12 07:23, Mikael Gerdin wrote:
> Jon,
>
> On 2012-09-24 23:46, Jon Masamitsu wrote:
>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>
>> If CMS is not doing class unloading, don't start a concurrent
>> collection for classloader (and metadata) collection (since
>> it won't happen without class unloading).
>
> It looks like you still unconditionally call expand_and_allocate when 
> running with CMS, no matter the value of CMSClassUnloadingEnabled.
> I think that the code:
>
>  213       // For CMS expand since the collection is going to be 
> concurrent.
>  214       _result =
>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size, 
> _mdtype);
>
> Should be inside the "if (CMSClassUnloadingEnabled)" and if running 
> without it set then CMS users will have to take the hit of a stw full 
> gc when running into the metadata threshold.
>
> /Mikael
>
>>
>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>
>> Also, refactored the code for readability and guarded extra
>> output with Verbose.
>>
>> Thanks.
>>
>> Jon
>


From jon.masamitsu at oracle.com  Tue Sep 25 16:25:48 2012
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Tue, 25 Sep 2012 16:25:48 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7200615: NPG: optimized VM build is broken
Message-ID: <20120925162551.2FC9547D2E@hg.openjdk.java.net>

Changeset: 5baec2e69518
Author:    jmasa
Date:      2012-09-25 07:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5baec2e69518

7200615: NPG: optimized VM build is broken
Reviewed-by: kvn

! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/memory/metaspace.cpp



From john.cuthbertson at oracle.com  Tue Sep 25 17:54:29 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 25 Sep 2012 10:54:29 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <5061B481.6090803@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>
	<505D5140.2070002@oracle.com> <5060924F.6090705@oracle.com>
	<5061B481.6090803@oracle.com>
Message-ID: <5061EFD5.5080008@oracle.com>

Hi Jon,

AFAIK this was the only place.

I don't recall any comment from Dave Detlefs in the original code 
explaining why. Most of the ranges (address ranges in regions etc) are 
exclusive. But this is the only place in G1 where we need the range of 
cards spanned by an object. In the original code - Dave was just using 
an inclusive loop - which set each bit in the inclusive range of cards 
individually. We changed the code to use the BitMap routines because 
they can work at the word level for large ranges, which should be more 
efficient. Hence this inclusive range was mapped to the exclusive range 
needed by the range utility routines in the BitMap class.

Do you know, offhand, how the other collectors find all of the cards 
spanned by a single object? Do they calculate an inclusive or exclusive 
range of cards? Do they use the last address word in the current object, 
or the start of the next object? In an earlier life, I can remember 
fixing a few OOB assertions (in the DirtyCardToOopClosures I believe) 
caused by attempting to get the card for the address returned by 
MemRegion::end() instead of MemRegion::last().

Having made the routine and call sites exclusive we could end up with a 
pointer that is actually outside the heap (if we're examining the last 
object in the heap) which will cause an assertion in 
CardTableModRefBS::is_card_aligned() to fire unless 
CardTableModRefBS::is_card_aligned() is guarded with a heap range check. 
With an inclusive range routine you can assume that the last address 
word of any object in the heap is also in the heap and so don't need to 
check if it's card aligned (no need to increment) and hence no need to 
check if it's in the heap.

Anyway the routine now takes an exclusive range - which, IMO, doesn't 
look any cleaner than the previous code. Expect a new webrev after some 
more testing.

JohnC

On 09/25/12 06:41, Jon Masamitsu wrote:
> John,
>
> Is it common practice in G1 code to have the ranges
> be inclusive?
>
> Jon
>
> PS.  Sorry for being tardy on my reply - so much mail,
> so little time :-)
>
> On 09/24/12 10:03, John Cuthbertson wrote:
>> Hi Jon,
>>
>> Thanks for the comments. I'm going to refer you to my reply to 
>> Jesper. If people feel strongly about making the routine exclusive - 
>> I'll make it so.
>>
>> JohnC
>>
>> On 09/21/12 22:48, Jon Masamitsu wrote:
>>> I'm used to seeing a range like [start, end).  That the second index 
>>> is named
>>> last_idx helps but if I were just looking at the call site, I would 
>>> have guessed
>>> wrongly - i.e., thinking it was [start, end).
>>>
>>> Jon
>>>
>>> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>>>> John,
>>>>
>>>> Looks good!
>>>>
>>>> Would it make sense to change set_card_bitmap_range to be 
>>>> exclusive, or even to take a start and a size of the area? I think 
>>>> inclusive functions like this one are unintuitive, especially when 
>>>> the only use of last_idx is used with a +1. Maybe that's a 
>>>> different change?
>>>> /Jesper
>>>>
>>>>
>>>>
>>>> 22 sep 2012 kl. 01:37 skrev John 
>>>> Cuthbertson<john.cuthbertson at oracle.com>:
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> Can I have a couple of volunteers look over the fix for this CR? 
>>>>> The webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>>>
>>>>> Summary:
>>>>> The clipping in the code that sets the bits for a range of cards 
>>>>> in the "expected" card bitmap that we check the liveness 
>>>>> accounting data against was incorrect. This could lead to spurious 
>>>>> verification failures. In addition to fixing the clipping, I've 
>>>>> upleveled this routine and moved it into ConcurrentMark and now 
>>>>> use it to generate the real liveness data.
>>>>>
>>>>> Testing:
>>>>> The failing test cases with marking verification; jprt.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JohnC
>>



From mikael.gerdin at oracle.com  Tue Sep 25 18:09:14 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 25 Sep 2012 20:09:14 +0200
Subject: Request for review (s) - 7198873
In-Reply-To: <5061DA7B.2000804@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com>
Message-ID: <5061F34A.9000307@oracle.com>

On 2012-09-25 18:23, Jon Masamitsu wrote:
> Mikael,
>
> Thanks for the review.
>
> The expand_and_allocate() does not do a GC.  It expands
> the Metaspace and does an allocation from the expanded
> space.  Only if that fails does the CMS case fall through to
> the full GC.

Yes.

>
> The policy for CMS is
>
> 1) Hitting the HWM should start a concurrent collection if
> CMS is doing class unloading.
> 2) Always  expand the Metaspace and allocate from
> the expanded space.
> 3) If expanding the Metaspace does not provide any free
> space, do a full GC to reclaim classloaders and class metadata
> and then retry the allocation.

But at what point does expanding the Metaspace not provide any free 
space? Is there some sort of back-off so that we don't just go ahead and 
allocate all available memory and then try to do a full gc when we've 
filled up the address space?
I'm kind of concerned about the case with CMS without 
CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks 
and cases where an application loads a bunch of classes and then 
releases the java level references to them but does not unload them 
since we don't get to the expand_and_allocate returning null.

/Mikael

>
> Jon
>
>
> On 09/25/12 07:23, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>
>>> If CMS is not doing class unloading, don't start a concurrent
>>> collection for classloader (and metadata) collection (since
>>> it won't happen without class unloading).
>>
>> It looks like you still unconditionally call expand_and_allocate when
>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>> I think that the code:
>>
>>  213       // For CMS expand since the collection is going to be
>> concurrent.
>>  214       _result =
>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>> _mdtype);
>>
>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>> without it set then CMS users will have to take the hit of a stw full
>> gc when running into the metadata threshold.
>>
>> /Mikael
>>
>>>
>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>
>>> Also, refactored the code for readability and guarded extra
>>> output with Verbose.
>>>
>>> Thanks.
>>>
>>> Jon
>>



From jon.masamitsu at oracle.com  Tue Sep 25 19:15:59 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 25 Sep 2012 12:15:59 -0700
Subject: RFR (S) Make tenuring threshold unsigned
In-Reply-To: <506066CA.8090402@oracle.com>
References: <506066CA.8090402@oracle.com>
Message-ID: <506202EF.6010509@oracle.com>

Change looks good.

On 09/24/12 06:57, Jesper Wilhelmsson wrote:
> Hi,
>
> While working on a different change I noticed that the tenuring 
> threshold was stored in a signed int. This struck me as odd, and since 
> I wanted to avoid some unintuitive casts in my other change I would 
> prefer to change the threshold to an unsigned.
>
> The change is available here:
>
> http://cr.openjdk.java.net/~jwilhelm/TenuringThreshold/
>
> Several files are touched but there's just type changes in a few 
> places per file.
>
> In this change I also change the declared type of 
> -XX:MaxTenuringThreshold and -XX:InitialTenuringThreshold to uintx. 
> This should not be a problem since we don't allow negative values for 
> these flags anyway.
> /Jesper


From jon.masamitsu at oracle.com  Tue Sep 25 20:11:17 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 25 Sep 2012 13:11:17 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <5061F34A.9000307@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
Message-ID: <50620FE5.5080608@oracle.com>



On 09/25/12 11:09, Mikael Gerdin wrote:
> ...
>>
>> The policy for CMS is
>>
>> 1) Hitting the HWM should start a concurrent collection if
>> CMS is doing class unloading.
>> 2) Always  expand the Metaspace and allocate from
>> the expanded space.
>> 3) If expanding the Metaspace does not provide any free
>> space, do a full GC to reclaim classloaders and class metadata
>> and then retry the allocation.
>
> But at what point does expanding the Metaspace not provide any free 
> space? Is there some sort of back-off so that we don't just go ahead 
> and allocate all available memory and then try to do a full gc when 
> we've filled up the address space?

I don't know what to do about this case.  We could change
CMSClassUnloadingEnabled to true by default so that
users would have to turn it off (at their own risk) if
they don't want to unload classes.  We could pick
some size for MaxMetaspaceSize (something appropriately
large) and again make the users change it (at their own
risk).  The latter isn't quite in line with the spirit of "removing
the need to turn perm gen" but maybe it is the lesser of
two evils.  I just don't know.

> I'm kind of concerned about the case with CMS without 
> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks 
> and cases where an application loads a bunch of classes and then 
> releases the java level references to them but does not unload them 
> since we don't get to the expand_and_allocate returning null.

We're trading the VM shutting down for perm gen OOM for
the VM shutting down because out of address space.  I'm
beginning to think we should have a reasonably large
default value for MaxMetaspaceSize.


Jon
>
> /Mikael
>
>>
>> Jon
>>
>>
>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>
>>>> If CMS is not doing class unloading, don't start a concurrent
>>>> collection for classloader (and metadata) collection (since
>>>> it won't happen without class unloading).
>>>
>>> It looks like you still unconditionally call expand_and_allocate when
>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>> I think that the code:
>>>
>>>  213       // For CMS expand since the collection is going to be
>>> concurrent.
>>>  214       _result =
>>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>> _mdtype);
>>>
>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>> without it set then CMS users will have to take the hit of a stw full
>>> gc when running into the metadata threshold.
>>>
>>> /Mikael
>>>
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>
>>>> Also, refactored the code for readability and guarded extra
>>>> output with Verbose.
>>>>
>>>> Thanks.
>>>>
>>>> Jon
>>>
>


From bengt.rutisson at oracle.com  Tue Sep 25 20:47:17 2012
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Tue, 25 Sep 2012 20:47:17 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets
Message-ID: <20120925204724.0277E47D59@hg.openjdk.java.net>

Changeset: 8966c2d65d96
Author:    brutisso
Date:      2012-09-25 14:58 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8966c2d65d96

7200470: KeepAliveClosure not needed in CodeCache::do_unloading
Summary: Removed the unused keep_alive parameter
Reviewed-by: stefank, dholmes, kamg, coleenp

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/memory/genMarkSweep.cpp

Changeset: 7c2fd5948145
Author:    brutisso
Date:      2012-09-25 18:28 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7c2fd5948145

Merge




From john.cuthbertson at oracle.com  Tue Sep 25 20:53:52 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 25 Sep 2012 13:53:52 -0700
Subject: RFR (S) Make tenuring threshold unsigned
In-Reply-To: <506066CA.8090402@oracle.com>
References: <506066CA.8090402@oracle.com>
Message-ID: <506219E0.1080702@oracle.com>

Hi Jesper,

Looks OK except for the nits below:


cmsAdaptiveSizePolicy.cpp:
Line 1318: Change the format descriptor.

g1CollectorPolicy.hpp:
Looks like you missed this file:

Line 844:
  // Current tenuring threshold, set to 0 if the collector reaches the
  // maximum amount of suvivors regions.
  int _tenuring_threshold;

Line 865:
age should be unsigned too.

psScavenge.cpp:
Line 528: Change the format descriptor.

psScavenge.hpp:
Line 91: Missed
static int tenuring_threshold() { return _tenuring_threshold; }

adaptiveSizePolicy.cpp
Looks like you missed this file:
Line 643:
bool AdaptiveSizePolicy::print_adaptive_size_policy_on(
                                            outputStream* st,
                                            int tenuring_threshold_arg) 
const {

Line 666: Change format descriptor

adaptiveSizePolic.hpp:
Line 493:
Another missed:
  bool print_adaptive_size_policy_on(outputStream* st, int
                                  tenuring_threshold) const;

ageTable.cpp:
Line 99: Change format descriptors.

defNewGeneration.hpp:
Another file missed:
Line 46:
  int         _tenuring_threshold;   // Tenuring threshold for next 
collection.

Line 328:
  int tenuring_threshold() { return _tenuring_threshold; }

vmStructs.cpp:
Another miss:
Line 511:
  nonstatic_field(DefNewGeneration,            
_tenuring_threshold,                           
int)                                   \

arguments.cpp:
Line 1158:
tenuring_default should be uintx.

oop.hpp:
Line 330: Shouldn't age() return an unsigned?

JohnC

On 09/24/12 06:57, Jesper Wilhelmsson wrote:
> Hi,
>
> While working on a different change I noticed that the tenuring 
> threshold was stored in a signed int. This struck me as odd, and since 
> I wanted to avoid some unintuitive casts in my other change I would 
> prefer to change the threshold to an unsigned.
>
> The change is available here:
>
> http://cr.openjdk.java.net/~jwilhelm/TenuringThreshold/
>
> Several files are touched but there's just type changes in a few 
> places per file.
>
> In this change I also change the declared type of 
> -XX:MaxTenuringThreshold and -XX:InitialTenuringThreshold to uintx. 
> This should not be a problem since we don't allow negative values for 
> these flags anyway.
> /Jesper



From ysr1729 at gmail.com  Tue Sep 25 21:32:21 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Tue, 25 Sep 2012 14:32:21 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <50620FE5.5080608@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<50620FE5.5080608@oracle.com>
Message-ID: <FDBA075A-4A67-49EC-9210-EA9E878A8DC6@gmail.com>

I think that it's definitely time to set cms class unloading to be true by default :-)
In my recent experience the impact of that on remark pauses has been very small... Of course I haven't run w/NPG so don't know how that changes the perf eqn ... Worth checking .. May be already done, Jon et al.?

However, even then we don't want CMS or G1 to do a full gc because meatspace could've expanded but was reluctant. I agree w/Jon that making the default max size for metaspace large reasonable value based on say the heap size max, might be appropriate.

--Ramki

ysr1729

On Sep 25, 2012, at 13:11, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:

> 
> 
> On 09/25/12 11:09, Mikael Gerdin wrote:
>> ...
>>> 
>>> The policy for CMS is
>>> 
>>> 1) Hitting the HWM should start a concurrent collection if
>>> CMS is doing class unloading.
>>> 2) Always  expand the Metaspace and allocate from
>>> the expanded space.
>>> 3) If expanding the Metaspace does not provide any free
>>> space, do a full GC to reclaim classloaders and class metadata
>>> and then retry the allocation.
>> 
>> But at what point does expanding the Metaspace not provide any free space? Is there some sort of back-off so that we don't just go ahead and allocate all available memory and then try to do a full gc when we've filled up the address space?
> 
> I don't know what to do about this case.  We could change
> CMSClassUnloadingEnabled to true by default so that
> users would have to turn it off (at their own risk) if
> they don't want to unload classes.  We could pick
> some size for MaxMetaspaceSize (something appropriately
> large) and again make the users change it (at their own
> risk).  The latter isn't quite in line with the spirit of "removing
> the need to turn perm gen" but maybe it is the lesser of
> two evils.  I just don't know.
> 
>> I'm kind of concerned about the case with CMS without CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks and cases where an application loads a bunch of classes and then releases the java level references to them but does not unload them since we don't get to the expand_and_allocate returning null.
> 
> We're trading the VM shutting down for perm gen OOM for
> the VM shutting down because out of address space.  I'm
> beginning to think we should have a reasonably large
> default value for MaxMetaspaceSize.
> 
> 
> Jon
>> 
>> /Mikael
>> 
>>> 
>>> Jon
>>> 
>>> 
>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>> Jon,
>>>> 
>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>> 
>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>> collection for classloader (and metadata) collection (since
>>>>> it won't happen without class unloading).
>>>> 
>>>> It looks like you still unconditionally call expand_and_allocate when
>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>> I think that the code:
>>>> 
>>>> 213       // For CMS expand since the collection is going to be
>>>> concurrent.
>>>> 214       _result =
>>>> 215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>>> _mdtype);
>>>> 
>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>> without it set then CMS users will have to take the hit of a stw full
>>>> gc when running into the metadata threshold.
>>>> 
>>>> /Mikael
>>>> 
>>>>> 
>>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>> 
>>>>> Also, refactored the code for readability and guarded extra
>>>>> output with Verbose.
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Jon
>>>> 
>> 


From john.cuthbertson at oracle.com  Tue Sep 25 22:44:58 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 25 Sep 2012 15:44:58 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <5061EFD5.5080008@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>	<505D5140.2070002@oracle.com>
	<5060924F.6090705@oracle.com>	<5061B481.6090803@oracle.com>
	<5061EFD5.5080008@oracle.com>
Message-ID: <506233EA.6080609@oracle.com>

Hi Everyone,

A new webrev for these changes can be found at: 
http://cr.openjdk.java.net/~johnc/7200261/webrev.1/

Based upon the code review comments - the set_card_bitmap_range() 
routine now takes an exclusive range of cards. As a result I have to 
check whether the end address of the current address range/region/object 
(i.e. the start the next) is card aligned (and in the heap) and 
increment the card index range appropriately. The essence of the bugfix 
is the same.

Testing:
The failing tests; GC test suite with a low IHOP and verification; GC 
test suite with forced evacuation failures; nsk  (gc,  jit, regression, 
and runtime) tests with a low IHOP and verification; jprt.

Thanks,

JohnC

On 09/25/12 10:54, John Cuthbertson wrote:
>
> Anyway the routine now takes an exclusive range - which, IMO, doesn't 
> look any cleaner than the previous code. Expect a new webrev after 
> some more testing.
>
> JohnC
>
> On 09/25/12 06:41, Jon Masamitsu wrote:
>> John,
>>
>> Is it common practice in G1 code to have the ranges
>> be inclusive?
>>
>> Jon
>>
>> PS.  Sorry for being tardy on my reply - so much mail,
>> so little time :-)
>>
>> On 09/24/12 10:03, John Cuthbertson wrote:
>>> Hi Jon,
>>>
>>> Thanks for the comments. I'm going to refer you to my reply to 
>>> Jesper. If people feel strongly about making the routine exclusive - 
>>> I'll make it so.
>>>
>>> JohnC
>>>
>>> On 09/21/12 22:48, Jon Masamitsu wrote:
>>>> I'm used to seeing a range like [start, end).  That the second 
>>>> index is named
>>>> last_idx helps but if I were just looking at the call site, I would 
>>>> have guessed
>>>> wrongly - i.e., thinking it was [start, end).
>>>>
>>>> Jon
>>>>
>>>> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>>>>> John,
>>>>>
>>>>> Looks good!
>>>>>
>>>>> Would it make sense to change set_card_bitmap_range to be 
>>>>> exclusive, or even to take a start and a size of the area? I think 
>>>>> inclusive functions like this one are unintuitive, especially when 
>>>>> the only use of last_idx is used with a +1. Maybe that's a 
>>>>> different change?
>>>>> /Jesper
>>>>>
>>>>>
>>>>>
>>>>> 22 sep 2012 kl. 01:37 skrev John 
>>>>> Cuthbertson<john.cuthbertson at oracle.com>:
>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Can I have a couple of volunteers look over the fix for this CR? 
>>>>>> The webrev can be found at: 
>>>>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>>>>
>>>>>> Summary:
>>>>>> The clipping in the code that sets the bits for a range of cards 
>>>>>> in the "expected" card bitmap that we check the liveness 
>>>>>> accounting data against was incorrect. This could lead to 
>>>>>> spurious verification failures. In addition to fixing the 
>>>>>> clipping, I've upleveled this routine and moved it into 
>>>>>> ConcurrentMark and now use it to generate the real liveness data.
>>>>>>
>>>>>> Testing:
>>>>>> The failing test cases with marking verification; jprt.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> JohnC
>>>
>



From john.cuthbertson at oracle.com  Wed Sep 26 00:10:07 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 25 Sep 2012 17:10:07 -0700
Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption
In-Reply-To: <505C76EC.5030902@oracle.com>
References: <505B6B65.1060201@oracle.com> <505C76EC.5030902@oracle.com>
Message-ID: <506247DF.80709@oracle.com>

Hi Bengt,

Thanks for the review. Replies inline...

On 09/21/12 07:17, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for doing the thorough analysis and providing the numbers. 
> Interesting that G1 does 21703 mallocs at startup whereas Parallel 
> only does 3500...
>
> However, I think I need some more background on this change. We are 
> choosing to allocating into a single VirtualSpace instead of using 
> separate mallocs. I understand that this will reduce the number of 
> mallocs we do, but is that really the problem? The CR says that we run 
> out of memory due to the fact that the GC threads allocate too much 
> memory. We will still allocate the same amount of memory just mmapped 
> instead of malloced, right? Do we have any test cases that fail before 
> your fix but pass now?
We didn't run out of memory - we ran out of C heap.

There is an issue on Solaris (I have to check whether Ramki's email 
describes the underlying problem) where by we asked for a 26Gb heap 
(which we got) but the C heap was only given 2Gb. Vladimir saw the issue 
during COOPs testing. In this situation we ran out of C heap trying to 
allocate the work queues for the marking threads.

Azeem submitted an issue a few weeks ago as well that ran into the same 
problem (this time with ParallelGC/ParallelOld) and the process died 
while trying to allocate the PSPromotionManager instances (and their 
internal work queue) - see CR 7167969. I believe that 7197666 is similar.

A real reduction in memory use will come from reducing the task queue 
size. I want to do that in a separate CR (for some or all of the 
collectors)  provided there is no real performance difference.

>
> In fact, isn't the risk higher (at least on 32 bit platforms) that we 
> fail to allocate the bitmaps now that we try to allocate them from one 
> consecutive chunk of memory instead of several smaller ones? I'm 
> thinking that if the memory is fragmented we might not get the 
> contiguous memory we need for the VirtualSpace. But I am definitely no 
> expert in this.

Good question and I wish I knew the answer. The occupancy of the task 
card bitmaps depends on the # of GC threads and the heap size (1 bit per 
card) - I guess it might be possible. Should I then only be allocating 
out of the backing store in a 64-bit JVM?
>
> With the above reservation I think your change looks good. Here are a 
> couple of minor comments:
>
> CMMarkStack::allocate(size_t size)
> "size" is kind of an overloaded name for an "allocate" method. Could 
> we call it "capacity" or "number_of_entries"?

Sure. Done. I renamed 'size' to 'capacity' - which matches the field 
name. But you bring up a good point about this confusion. If we look at 
the CMS version of the same routine:

bool CMSMarkStack::allocate(size_t size) {
  // allocate a stack of the requisite depth
  ReservedSpace rs(ReservedSpace::allocation_align_size_up(
                   size * sizeof(oop)));
  if (!rs.is_reserved()) {
    warning("CMSMarkStack allocation failure");
    return false;
  }
  if (!_virtual_space.initialize(rs, rs.size())) {
    warning("CMSMarkStack backing store failure");
    return false;
  }
  assert(_virtual_space.committed_size() == rs.size(),
         "didn't reserve backing store for all of CMS stack?");
  _base = (oop*)(_virtual_space.low());
  _index = 0;
  _capacity = size;
  NOT_PRODUCT(_max_depth = 0);
  return true;
}

it used the parameter as the real size in bytes of the marking stack. In 
G1, since we used NEW_C_HEAP_ARRAY, the size was multiplied by the size 
of an oop and we got a larger marking stack than requested. Instead of a 
16 Mb stack (128 * 128K), we got a 128Mb stack (8 * 128 * 128K). 
Basically we asked for the equivalent of the task queues for another 128 
threads:

dr-evil{jcuthber}:265> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
-XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
-XX:+UseG1GC -XX:+PrintMallocStatistics
Using java runtime at: 
/net/jre.us.oracle.com/p/v42/jdk/7/fcs/b147/binaries/solaris-sparcv9/jre
size: 16777216, MarkStackSize: 16777216, TASKQUEUE_SIZE: 131072
os::malloc 134217728 bytes --> 0x00000001010709e8
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-b03-internal-fastdebug, 
mixed mode)
allocation stats: 24489 mallocs (212MB), 1147 frees (0MB), 4MB resrc

Mimicking CMS is probably the way to go here.
>
>
> In ConcurrentMark::ConcurrentMark() we use both shifting and division 
> to accomplish the same thing on the lines after each other. Could we 
> maybe use the same style for both cases?
>
>   // Card liveness bitmap size (in bits)
>   BitMap::idx_t card_bm_size = (heap_rs.size() + 
> CardTableModRefBS::card_size - 1)
>                                 >> CardTableModRefBS::card_shift;
>   // Card liveness bitmap size (in bytes)
>   size_t card_bm_size_bytes = (card_bm_size + (BitsPerByte - 1)) / 
> BitsPerByte;

Sure. Changed the latter one to use LogBitsPerByte.

> Also in ConcurrentMark::ConcurrentMark() I think  that 
> "marked_bytes_size_bytes" is not such a great name. Probably we could 
> skip the first "bytes" in "marked_bytes_size" and just call 
> "marked_bytes_size_bytes" for "marked_size_bytes".

OK. What about just marked_bytes_size?
>
> I think it would be nice to factor some of the new stuff in 
> ConcurrentMark::ConcurrentMark() out into methods. Both the 
> calculations of the sizes and the creation/setting of the bitmaps. But 
> I admit that this is just a style issue.

OK. I'll try a few things to pretty it up.

Expect a new webrev soon.

JohnC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120925/3ffaeda9/attachment.htm>

From jon.masamitsu at oracle.com  Wed Sep 26 04:12:05 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 25 Sep 2012 21:12:05 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <FDBA075A-4A67-49EC-9210-EA9E878A8DC6@gmail.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<50620FE5.5080608@oracle.com>
	<FDBA075A-4A67-49EC-9210-EA9E878A8DC6@gmail.com>
Message-ID: <50628095.9000604@oracle.com>



On 9/25/2012 2:32 PM, Srinivas Ramakrishna wrote:
> I think that it's definitely time to set cms class unloading to be true by default :-)
> In my recent experience the impact of that on remark pauses has been very small... Of course I haven't run w/NPG so don't know how that changes the perf eqn ... Worth checking .. May be already done, Jon et al.?

I'll run something and see but maybe not this week.

> However, even then we don't want CMS or G1 to do a full gc because meatspace could've expanded but was reluctant. I agree w/Jon that making the default max size for metaspace large reasonable value based on say the heap size max, might be appropriate.

You might be right that something related to the max size of the heap 
would be
appropriate but I'm not sure it's worth having the value vary from platform
to platform (just because I have to ask how much physical memory was
on the system).

Jon
> --Ramki
>
> ysr1729
>
> On Sep 25, 2012, at 13:11, Jon Masamitsu<jon.masamitsu at oracle.com>  wrote:
>
>>
>> On 09/25/12 11:09, Mikael Gerdin wrote:
>>> ...
>>>> The policy for CMS is
>>>>
>>>> 1) Hitting the HWM should start a concurrent collection if
>>>> CMS is doing class unloading.
>>>> 2) Always  expand the Metaspace and allocate from
>>>> the expanded space.
>>>> 3) If expanding the Metaspace does not provide any free
>>>> space, do a full GC to reclaim classloaders and class metadata
>>>> and then retry the allocation.
>>> But at what point does expanding the Metaspace not provide any free space? Is there some sort of back-off so that we don't just go ahead and allocate all available memory and then try to do a full gc when we've filled up the address space?
>> I don't know what to do about this case.  We could change
>> CMSClassUnloadingEnabled to true by default so that
>> users would have to turn it off (at their own risk) if
>> they don't want to unload classes.  We could pick
>> some size for MaxMetaspaceSize (something appropriately
>> large) and again make the users change it (at their own
>> risk).  The latter isn't quite in line with the spirit of "removing
>> the need to turn perm gen" but maybe it is the lesser of
>> two evils.  I just don't know.
>>
>>> I'm kind of concerned about the case with CMS without CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks and cases where an application loads a bunch of classes and then releases the java level references to them but does not unload them since we don't get to the expand_and_allocate returning null.
>> We're trading the VM shutting down for perm gen OOM for
>> the VM shutting down because out of address space.  I'm
>> beginning to think we should have a reasonably large
>> default value for MaxMetaspaceSize.
>>
>>
>> Jon
>>> /Mikael
>>>
>>>> Jon
>>>>
>>>>
>>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>>> Jon,
>>>>>
>>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>>>
>>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>>> collection for classloader (and metadata) collection (since
>>>>>> it won't happen without class unloading).
>>>>> It looks like you still unconditionally call expand_and_allocate when
>>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>>> I think that the code:
>>>>>
>>>>> 213       // For CMS expand since the collection is going to be
>>>>> concurrent.
>>>>> 214       _result =
>>>>> 215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>>>> _mdtype);
>>>>>
>>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>>> without it set then CMS users will have to take the hit of a stw full
>>>>> gc when running into the metadata threshold.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>>>
>>>>>> Also, refactored the code for readability and guarded extra
>>>>>> output with Verbose.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Jon


From jesper.wilhelmsson at oracle.com  Wed Sep 26 13:18:52 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 26 Sep 2012 15:18:52 +0200
Subject: RFR (S) Make tenuring threshold unsigned
In-Reply-To: <506219E0.1080702@oracle.com>
References: <506066CA.8090402@oracle.com> <506219E0.1080702@oracle.com>
Message-ID: <506300BC.308@oracle.com>

John and Jon,

Thanks for the reviews!

All comments below has been taken care of. I updated the webrev in place:
http://cr.openjdk.java.net/~jwilhelm/TenuringThreshold/

/Jesper

On 2012-09-25 22:53, John Cuthbertson wrote:
> Hi Jesper,
>
> Looks OK except for the nits below:
>
>
> cmsAdaptiveSizePolicy.cpp:
> Line 1318: Change the format descriptor.
>
> g1CollectorPolicy.hpp:
> Looks like you missed this file:
>
> Line 844:
>   // Current tenuring threshold, set to 0 if the collector reaches the
>   // maximum amount of suvivors regions.
>   int _tenuring_threshold;
>
> Line 865:
> age should be unsigned too.
>
> psScavenge.cpp:
> Line 528: Change the format descriptor.
>
> psScavenge.hpp:
> Line 91: Missed
> static int tenuring_threshold() { return _tenuring_threshold; }
>
> adaptiveSizePolicy.cpp
> Looks like you missed this file:
> Line 643:
> bool AdaptiveSizePolicy::print_adaptive_size_policy_on(
>                                             outputStream* st,
>                                             int tenuring_threshold_arg) const {
>
> Line 666: Change format descriptor
>
> adaptiveSizePolic.hpp:
> Line 493:
> Another missed:
>   bool print_adaptive_size_policy_on(outputStream* st, int
>                                   tenuring_threshold) const;
>
> ageTable.cpp:
> Line 99: Change format descriptors.
>
> defNewGeneration.hpp:
> Another file missed:
> Line 46:
>   int         _tenuring_threshold;   // Tenuring threshold for next collection.
>
> Line 328:
>   int tenuring_threshold() { return _tenuring_threshold; }
>
> vmStructs.cpp:
> Another miss:
> Line 511:
>   nonstatic_field(DefNewGeneration, _tenuring_threshold,
> int)                                   \
>
> arguments.cpp:
> Line 1158:
> tenuring_default should be uintx.
>
> oop.hpp:
> Line 330: Shouldn't age() return an unsigned?
>
> JohnC
>
> On 09/24/12 06:57, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> While working on a different change I noticed that the tenuring threshold
>> was stored in a signed int. This struck me as odd, and since I wanted to
>> avoid some unintuitive casts in my other change I would prefer to change the
>> threshold to an unsigned.
>>
>> The change is available here:
>>
>> http://cr.openjdk.java.net/~jwilhelm/TenuringThreshold/
>>
>> Several files are touched but there's just type changes in a few places per
>> file.
>>
>> In this change I also change the declared type of -XX:MaxTenuringThreshold
>> and -XX:InitialTenuringThreshold to uintx. This should not be a problem
>> since we don't allow negative values for these flags anyway.
>> /Jesper
>


From jon.masamitsu at oracle.com  Wed Sep 26 16:44:07 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 26 Sep 2012 09:44:07 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <5061F34A.9000307@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
Message-ID: <506330D7.5070504@oracle.com>

Mikael,

Do you want a default value (less than max uint) for MaxMetaspaceSize before
this change goes back?

Jon

On 9/25/2012 11:09 AM, Mikael Gerdin wrote:
> On 2012-09-25 18:23, Jon Masamitsu wrote:
>> Mikael,
>>
>> Thanks for the review.
>>
>> The expand_and_allocate() does not do a GC.  It expands
>> the Metaspace and does an allocation from the expanded
>> space.  Only if that fails does the CMS case fall through to
>> the full GC.
>
> Yes.
>
>>
>> The policy for CMS is
>>
>> 1) Hitting the HWM should start a concurrent collection if
>> CMS is doing class unloading.
>> 2) Always  expand the Metaspace and allocate from
>> the expanded space.
>> 3) If expanding the Metaspace does not provide any free
>> space, do a full GC to reclaim classloaders and class metadata
>> and then retry the allocation.
>
> But at what point does expanding the Metaspace not provide any free 
> space? Is there some sort of back-off so that we don't just go ahead 
> and allocate all available memory and then try to do a full gc when 
> we've filled up the address space?
> I'm kind of concerned about the case with CMS without 
> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks 
> and cases where an application loads a bunch of classes and then 
> releases the java level references to them but does not unload them 
> since we don't get to the expand_and_allocate returning null.
>
> /Mikael
>
>>
>> Jon
>>
>>
>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>
>>>> If CMS is not doing class unloading, don't start a concurrent
>>>> collection for classloader (and metadata) collection (since
>>>> it won't happen without class unloading).
>>>
>>> It looks like you still unconditionally call expand_and_allocate when
>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>> I think that the code:
>>>
>>>  213       // For CMS expand since the collection is going to be
>>> concurrent.
>>>  214       _result =
>>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>> _mdtype);
>>>
>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>> without it set then CMS users will have to take the hit of a stw full
>>> gc when running into the metadata threshold.
>>>
>>> /Mikael
>>>
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>
>>>> Also, refactored the code for readability and guarded extra
>>>> output with Verbose.
>>>>
>>>> Thanks.
>>>>
>>>> Jon
>>>
>


From jon.masamitsu at oracle.com  Wed Sep 26 18:04:00 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 26 Sep 2012 11:04:00 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <506233EA.6080609@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>	<505D5140.2070002@oracle.com>	<5060924F.6090705@oracle.com>	<5061B481.6090803@oracle.com>	<5061EFD5.5080008@oracle.com>
	<506233EA.6080609@oracle.com>
Message-ID: <50634390.4020702@oracle.com>

John,

Thanks for the answers to my questions and for
clarifying the comment.  Changes look good.

Jon

On 9/25/2012 3:44 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> A new webrev for these changes can be found at: 
> http://cr.openjdk.java.net/~johnc/7200261/webrev.1/
>
> Based upon the code review comments - the set_card_bitmap_range() 
> routine now takes an exclusive range of cards. As a result I have to 
> check whether the end address of the current address 
> range/region/object (i.e. the start the next) is card aligned (and in 
> the heap) and increment the card index range appropriately. The 
> essence of the bugfix is the same.
>
> Testing:
> The failing tests; GC test suite with a low IHOP and verification; GC 
> test suite with forced evacuation failures; nsk  (gc,  jit, 
> regression, and runtime) tests with a low IHOP and verification; jprt.
>
> Thanks,
>
> JohnC
>
> On 09/25/12 10:54, John Cuthbertson wrote:
>>
>> Anyway the routine now takes an exclusive range - which, IMO, doesn't 
>> look any cleaner than the previous code. Expect a new webrev after 
>> some more testing.
>>
>> JohnC
>>
>> On 09/25/12 06:41, Jon Masamitsu wrote:
>>> John,
>>>
>>> Is it common practice in G1 code to have the ranges
>>> be inclusive?
>>>
>>> Jon
>>>
>>> PS.  Sorry for being tardy on my reply - so much mail,
>>> so little time :-)
>>>
>>> On 09/24/12 10:03, John Cuthbertson wrote:
>>>> Hi Jon,
>>>>
>>>> Thanks for the comments. I'm going to refer you to my reply to 
>>>> Jesper. If people feel strongly about making the routine exclusive 
>>>> - I'll make it so.
>>>>
>>>> JohnC
>>>>
>>>> On 09/21/12 22:48, Jon Masamitsu wrote:
>>>>> I'm used to seeing a range like [start, end).  That the second 
>>>>> index is named
>>>>> last_idx helps but if I were just looking at the call site, I 
>>>>> would have guessed
>>>>> wrongly - i.e., thinking it was [start, end).
>>>>>
>>>>> Jon
>>>>>
>>>>> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>>>>>> John,
>>>>>>
>>>>>> Looks good!
>>>>>>
>>>>>> Would it make sense to change set_card_bitmap_range to be 
>>>>>> exclusive, or even to take a start and a size of the area? I 
>>>>>> think inclusive functions like this one are unintuitive, 
>>>>>> especially when the only use of last_idx is used with a +1. Maybe 
>>>>>> that's a different change?
>>>>>> /Jesper
>>>>>>
>>>>>>
>>>>>>
>>>>>> 22 sep 2012 kl. 01:37 skrev John 
>>>>>> Cuthbertson<john.cuthbertson at oracle.com>:
>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> Can I have a couple of volunteers look over the fix for this CR? 
>>>>>>> The webrev can be found at: 
>>>>>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>>>>>
>>>>>>> Summary:
>>>>>>> The clipping in the code that sets the bits for a range of cards 
>>>>>>> in the "expected" card bitmap that we check the liveness 
>>>>>>> accounting data against was incorrect. This could lead to 
>>>>>>> spurious verification failures. In addition to fixing the 
>>>>>>> clipping, I've upleveled this routine and moved it into 
>>>>>>> ConcurrentMark and now use it to generate the real liveness data.
>>>>>>>
>>>>>>> Testing:
>>>>>>> The failing test cases with marking verification; jprt.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> JohnC
>>>>
>>
>


From john.cuthbertson at oracle.com  Wed Sep 26 18:46:23 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 26 Sep 2012 11:46:23 -0700
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <50634390.4020702@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>	<505D5140.2070002@oracle.com>	<5060924F.6090705@oracle.com>	<5061B481.6090803@oracle.com>	<5061EFD5.5080008@oracle.com>	<506233EA.6080609@oracle.com>
	<50634390.4020702@oracle.com>
Message-ID: <50634D7F.201@oracle.com>

Hi Jon,

Thanks for the review. And answering the questions was no problem. This 
is tricksy code and, since it's used to prune RSet entries, important to 
get right.

Thanks,

JohnC

On 09/26/12 11:04, Jon Masamitsu wrote:
> John,
>
> Thanks for the answers to my questions and for
> clarifying the comment.  Changes look good.
>
> Jon
>
> On 9/25/2012 3:44 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> A new webrev for these changes can be found at: 
>> http://cr.openjdk.java.net/~johnc/7200261/webrev.1/
>>
>> Based upon the code review comments - the set_card_bitmap_range() 
>> routine now takes an exclusive range of cards. As a result I have to 
>> check whether the end address of the current address 
>> range/region/object (i.e. the start the next) is card aligned (and in 
>> the heap) and increment the card index range appropriately. The 
>> essence of the bugfix is the same.
>>
>> Testing:
>> The failing tests; GC test suite with a low IHOP and verification; GC 
>> test suite with forced evacuation failures; nsk  (gc,  jit, 
>> regression, and runtime) tests with a low IHOP and verification; jprt.
>>
>> Thanks,
>>
>> JohnC
>>
>> On 09/25/12 10:54, John Cuthbertson wrote:
>>>
>>> Anyway the routine now takes an exclusive range - which, IMO, 
>>> doesn't look any cleaner than the previous code. Expect a new webrev 
>>> after some more testing.
>>>
>>> JohnC
>>>
>>> On 09/25/12 06:41, Jon Masamitsu wrote:
>>>> John,
>>>>
>>>> Is it common practice in G1 code to have the ranges
>>>> be inclusive?
>>>>
>>>> Jon
>>>>
>>>> PS.  Sorry for being tardy on my reply - so much mail,
>>>> so little time :-)
>>>>
>>>> On 09/24/12 10:03, John Cuthbertson wrote:
>>>>> Hi Jon,
>>>>>
>>>>> Thanks for the comments. I'm going to refer you to my reply to 
>>>>> Jesper. If people feel strongly about making the routine exclusive 
>>>>> - I'll make it so.
>>>>>
>>>>> JohnC
>>>>>
>>>>> On 09/21/12 22:48, Jon Masamitsu wrote:
>>>>>> I'm used to seeing a range like [start, end).  That the second 
>>>>>> index is named
>>>>>> last_idx helps but if I were just looking at the call site, I 
>>>>>> would have guessed
>>>>>> wrongly - i.e., thinking it was [start, end).
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>>>>>>> John,
>>>>>>>
>>>>>>> Looks good!
>>>>>>>
>>>>>>> Would it make sense to change set_card_bitmap_range to be 
>>>>>>> exclusive, or even to take a start and a size of the area? I 
>>>>>>> think inclusive functions like this one are unintuitive, 
>>>>>>> especially when the only use of last_idx is used with a +1. 
>>>>>>> Maybe that's a different change?
>>>>>>> /Jesper
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 22 sep 2012 kl. 01:37 skrev John 
>>>>>>> Cuthbertson<john.cuthbertson at oracle.com>:
>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>> Can I have a couple of volunteers look over the fix for this 
>>>>>>>> CR? The webrev can be found at: 
>>>>>>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>> The clipping in the code that sets the bits for a range of 
>>>>>>>> cards in the "expected" card bitmap that we check the liveness 
>>>>>>>> accounting data against was incorrect. This could lead to 
>>>>>>>> spurious verification failures. In addition to fixing the 
>>>>>>>> clipping, I've upleveled this routine and moved it into 
>>>>>>>> ConcurrentMark and now use it to generate the real liveness data.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> The failing test cases with marking verification; jprt.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> JohnC
>>>>>
>>>
>>



From vitalyd at gmail.com  Wed Sep 26 23:09:09 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 26 Sep 2012 19:09:09 -0400
Subject: TLAB and NUMA aware allocator
In-Reply-To: <CAHjP37EQ5++nUdr60rf3s8Sz0-D7qkOPskKS1o0=WakRqFNwrQ@mail.gmail.com>
References: <CAHjP37GkqDqeN+L2X8vMWEERmfmKTixb6_fRFtCqQvV8-sb3mQ@mail.gmail.com>
	<CAHjP37HXd0AZJUSSv1K87hZGX8NdfV9qmLQ_qJmrLsGrw1qLqg@mail.gmail.com>
	<CAHjP37GBT9Y0Rt_JPAwENrYt6k7Wc+9ohgy3VUquYMfYNq1BBw@mail.gmail.com>
	<CAHjP37EQ5++nUdr60rf3s8Sz0-D7qkOPskKS1o0=WakRqFNwrQ@mail.gmail.com>
Message-ID: <CAHjP37FYjjJasq_6Os3Jvu6kSrt9m0MqxcmSSBmex7Dn9+4LHw@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120926/c0c527e5/attachment.htm>

From jon.masamitsu at oracle.com  Thu Sep 27 04:55:06 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 26 Sep 2012 21:55:06 -0700
Subject: TLAB and NUMA aware allocator
In-Reply-To: <CAHjP37FYjjJasq_6Os3Jvu6kSrt9m0MqxcmSSBmex7Dn9+4LHw@mail.gmail.com>
References: <CAHjP37GkqDqeN+L2X8vMWEERmfmKTixb6_fRFtCqQvV8-sb3mQ@mail.gmail.com>	<CAHjP37HXd0AZJUSSv1K87hZGX8NdfV9qmLQ_qJmrLsGrw1qLqg@mail.gmail.com>	<CAHjP37GBT9Y0Rt_JPAwENrYt6k7Wc+9ohgy3VUquYMfYNq1BBw@mail.gmail.com>	<CAHjP37EQ5++nUdr60rf3s8Sz0-D7qkOPskKS1o0=WakRqFNwrQ@mail.gmail.com>
	<CAHjP37FYjjJasq_6Os3Jvu6kSrt9m0MqxcmSSBmex7Dn9+4LHw@mail.gmail.com>
Message-ID: <5063DC2A.6000807@oracle.com>

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
>


From mikael.gerdin at oracle.com  Thu Sep 27 07:27:52 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 27 Sep 2012 09:27:52 +0200
Subject: Request for review (s) - 7198873
In-Reply-To: <506330D7.5070504@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<506330D7.5070504@oracle.com>
Message-ID: <5063FFF8.50608@oracle.com>

Jon,

On 2012-09-26 18:44, Jon Masamitsu wrote:
> Mikael,
>
> Do you want a default value (less than max uint) for MaxMetaspaceSize
> before
> this change goes back?

While I see a value in setting some sort of "sensible" value for 
MaxMetaspaceSize this is not really the exact issue I was worried about.

Consider this scenario:

* Person runs a Java app server/container with +UseConcMarkSweepGC (but 
without +CMSClassUnloadingEnabled).
* Some app is repeatedly deployed and un-deployed from the instance, 
every time an app is un-deployed its class loader and classes are made 
unreachable.

In this case CMS would not opt to unload classes until MaxMetaspaceSize 
is hit or the process/system runs out of memory.

Maybe there could be some sort of threshold for when to trigger a full 
collection (which includes class unloading) without that threshold value 
being a limit on the amount of memory available for meta data?

I know this is a complicated policy issue, and I agree that it would be 
good if we could enable +CMSClassUnloadingEnabled and get rid of the 
issue altogether. The question is whether or not performance testing 
resources are available to evaluate that.

/Mikael

>
> Jon
>
> On 9/25/2012 11:09 AM, Mikael Gerdin wrote:
>> On 2012-09-25 18:23, Jon Masamitsu wrote:
>>> Mikael,
>>>
>>> Thanks for the review.
>>>
>>> The expand_and_allocate() does not do a GC.  It expands
>>> the Metaspace and does an allocation from the expanded
>>> space.  Only if that fails does the CMS case fall through to
>>> the full GC.
>>
>> Yes.
>>
>>>
>>> The policy for CMS is
>>>
>>> 1) Hitting the HWM should start a concurrent collection if
>>> CMS is doing class unloading.
>>> 2) Always  expand the Metaspace and allocate from
>>> the expanded space.
>>> 3) If expanding the Metaspace does not provide any free
>>> space, do a full GC to reclaim classloaders and class metadata
>>> and then retry the allocation.
>>
>> But at what point does expanding the Metaspace not provide any free
>> space? Is there some sort of back-off so that we don't just go ahead
>> and allocate all available memory and then try to do a full gc when
>> we've filled up the address space?
>> I'm kind of concerned about the case with CMS without
>> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks
>> and cases where an application loads a bunch of classes and then
>> releases the java level references to them but does not unload them
>> since we don't get to the expand_and_allocate returning null.
>>
>> /Mikael
>>
>>>
>>> Jon
>>>
>>>
>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>> Jon,
>>>>
>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>>
>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>> collection for classloader (and metadata) collection (since
>>>>> it won't happen without class unloading).
>>>>
>>>> It looks like you still unconditionally call expand_and_allocate when
>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>> I think that the code:
>>>>
>>>>  213       // For CMS expand since the collection is going to be
>>>> concurrent.
>>>>  214       _result =
>>>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>>> _mdtype);
>>>>
>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>> without it set then CMS users will have to take the hit of a stw full
>>>> gc when running into the metadata threshold.
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>>
>>>>> Also, refactored the code for readability and guarded extra
>>>>> output with Verbose.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jon
>>>>
>>

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From ysr1729 at gmail.com  Thu Sep 27 07:49:55 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 27 Sep 2012 00:49:55 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <5063FFF8.50608@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<506330D7.5070504@oracle.com> <5063FFF8.50608@oracle.com>
Message-ID: <CABzyjy=AWXEUnFTXONOrj+4mfHg8JEw-BCr9VSEwQsY8Rm4RzA@mail.gmail.com>

I agree that if the user repeatedly does deploy-undeploy and is running
with class unloading disabled,
it would be good if he were to run out of native memory and realized his
mistake :-) and turned on class unloading.

As regards yr policy suggestion of forcing a perm gen collection every so
many cycles, i believe that is possible to do
so in a concurrent cycle rather than doing a stop-world collection for that
purpose  --
there was talk at one time of making the cms class unloading flag a
"manageable" flag (so it could be turned on or off
on-the-fly) -- there's probably even a bug about adaptively collecting the
perm gen with CMS.
 If it was found that the cost of class unloading at each major CMS cycle
was too expensive, one could,
as you suggest, do it ever so often.

How about a quick survey on the "-dev" and "-use" lists to see how many
users who use CMS explicitly switch on class
unloading vs not?

In any case, as regards Jon's question, I would say that the changes should
go back in woithout waiting for a decision
on MaxMetaSpaceSize or CMSClassUnloadingEnabled. If they run out of native
space they will probably quickly figure out what
happened (i am assuming the GC logs that inform one about one's usage of
metadata space would clue one in fairly soon if one
discovered how much space that was taking... I am assuming +PrintHeapAtGC
would produce some information, even if
+PrintGCDetails didn't re metatdataspace use?).

my $0.02.
-- ramki

On Thu, Sep 27, 2012 at 12:27 AM, Mikael Gerdin <mikael.gerdin at oracle.com>wrote:

> Jon,
>
>
> On 2012-09-26 18:44, Jon Masamitsu wrote:
>
>> Mikael,
>>
>> Do you want a default value (less than max uint) for MaxMetaspaceSize
>> before
>> this change goes back?
>>
>
> While I see a value in setting some sort of "sensible" value for
> MaxMetaspaceSize this is not really the exact issue I was worried about.
>
> Consider this scenario:
>
> * Person runs a Java app server/container with +UseConcMarkSweepGC (but
> without +CMSClassUnloadingEnabled).
> * Some app is repeatedly deployed and un-deployed from the instance, every
> time an app is un-deployed its class loader and classes are made
> unreachable.
>
> In this case CMS would not opt to unload classes until MaxMetaspaceSize is
> hit or the process/system runs out of memory.
>
> Maybe there could be some sort of threshold for when to trigger a full
> collection (which includes class unloading) without that threshold value
> being a limit on the amount of memory available for meta data?
>
> I know this is a complicated policy issue, and I agree that it would be
> good if we could enable +CMSClassUnloadingEnabled and get rid of the issue
> altogether. The question is whether or not performance testing resources
> are available to evaluate that.
>
> /Mikael
>
>
>
>> Jon
>>
>> On 9/25/2012 11:09 AM, Mikael Gerdin wrote:
>>
>>> On 2012-09-25 18:23, Jon Masamitsu wrote:
>>>
>>>> Mikael,
>>>>
>>>> Thanks for the review.
>>>>
>>>> The expand_and_allocate() does not do a GC.  It expands
>>>> the Metaspace and does an allocation from the expanded
>>>> space.  Only if that fails does the CMS case fall through to
>>>> the full GC.
>>>>
>>>
>>> Yes.
>>>
>>>
>>>> The policy for CMS is
>>>>
>>>> 1) Hitting the HWM should start a concurrent collection if
>>>> CMS is doing class unloading.
>>>> 2) Always  expand the Metaspace and allocate from
>>>> the expanded space.
>>>> 3) If expanding the Metaspace does not provide any free
>>>> space, do a full GC to reclaim classloaders and class metadata
>>>> and then retry the allocation.
>>>>
>>>
>>> But at what point does expanding the Metaspace not provide any free
>>> space? Is there some sort of back-off so that we don't just go ahead
>>> and allocate all available memory and then try to do a full gc when
>>> we've filled up the address space?
>>> I'm kind of concerned about the case with CMS without
>>> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks
>>> and cases where an application loads a bunch of classes and then
>>> releases the java level references to them but does not unload them
>>> since we don't get to the expand_and_allocate returning null.
>>>
>>> /Mikael
>>>
>>>
>>>> Jon
>>>>
>>>>
>>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>>
>>>>> Jon,
>>>>>
>>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>>
>>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>>>
>>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>>> collection for classloader (and metadata) collection (since
>>>>>> it won't happen without class unloading).
>>>>>>
>>>>>
>>>>> It looks like you still unconditionally call expand_and_allocate when
>>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>>> I think that the code:
>>>>>
>>>>>  213       // For CMS expand since the collection is going to be
>>>>> concurrent.
>>>>>  214       _result =
>>>>>  215 _loader_data->metaspace_non_**null()->expand_and_allocate(_**
>>>>> size,
>>>>> _mdtype);
>>>>>
>>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>>> without it set then CMS users will have to take the hit of a stw full
>>>>> gc when running into the metadata threshold.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>
>>>>>> http://cr.openjdk.java.net/~**jmasa/7198873/webrev.00/<http://cr.openjdk.java.net/%7Ejmasa/7198873/webrev.00/>
>>>>>>
>>>>>> Also, refactored the code for readability and guarded extra
>>>>>> output with Verbose.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>
>>>>>
>>>
> --
> Mikael Gerdin
> Java SE VM SQE Stockholm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120927/cebf179e/attachment.htm>

From jesper.wilhelmsson at oracle.com  Thu Sep 27 12:49:35 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 27 Sep 2012 14:49:35 +0200
Subject: RFR(S): 7200261: G1: Liveness counting inconsistencies during
	marking verification
In-Reply-To: <506233EA.6080609@oracle.com>
References: <505CFA2E.70809@oracle.com>	<8D9981D0-F9BA-43B1-93F3-D7681617CDD3@oracle.com>	<505D5140.2070002@oracle.com>
	<5060924F.6090705@oracle.com>	<5061B481.6090803@oracle.com>
	<5061EFD5.5080008@oracle.com> <506233EA.6080609@oracle.com>
Message-ID: <50644B5F.1080304@oracle.com>

John,

Looks good!
I like this version better. Thansk for doing the changes!
/Jesper

2012-09-26 00:44, John Cuthbertson skrev:
> Hi Everyone,
>
> A new webrev for these changes can be found at: 
> http://cr.openjdk.java.net/~johnc/7200261/webrev.1/
>
> Based upon the code review comments - the set_card_bitmap_range() routine now 
> takes an exclusive range of cards. As a result I have to check whether the 
> end address of the current address range/region/object (i.e. the start the 
> next) is card aligned (and in the heap) and increment the card index range 
> appropriately. The essence of the bugfix is the same.
>
> Testing:
> The failing tests; GC test suite with a low IHOP and verification; GC test 
> suite with forced evacuation failures; nsk  (gc,  jit, regression, and 
> runtime) tests with a low IHOP and verification; jprt.
>
> Thanks,
>
> JohnC
>
> On 09/25/12 10:54, John Cuthbertson wrote:
>>
>> Anyway the routine now takes an exclusive range - which, IMO, doesn't look 
>> any cleaner than the previous code. Expect a new webrev after some more 
>> testing.
>>
>> JohnC
>>
>> On 09/25/12 06:41, Jon Masamitsu wrote:
>>> John,
>>>
>>> Is it common practice in G1 code to have the ranges
>>> be inclusive?
>>>
>>> Jon
>>>
>>> PS.  Sorry for being tardy on my reply - so much mail,
>>> so little time :-)
>>>
>>> On 09/24/12 10:03, John Cuthbertson wrote:
>>>> Hi Jon,
>>>>
>>>> Thanks for the comments. I'm going to refer you to my reply to Jesper. If 
>>>> people feel strongly about making the routine exclusive - I'll make it so.
>>>>
>>>> JohnC
>>>>
>>>> On 09/21/12 22:48, Jon Masamitsu wrote:
>>>>> I'm used to seeing a range like [start, end).  That the second index is 
>>>>> named
>>>>> last_idx helps but if I were just looking at the call site, I would have 
>>>>> guessed
>>>>> wrongly - i.e., thinking it was [start, end).
>>>>>
>>>>> Jon
>>>>>
>>>>> On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
>>>>>> John,
>>>>>>
>>>>>> Looks good!
>>>>>>
>>>>>> Would it make sense to change set_card_bitmap_range to be exclusive, or 
>>>>>> even to take a start and a size of the area? I think inclusive functions 
>>>>>> like this one are unintuitive, especially when the only use of last_idx 
>>>>>> is used with a +1. Maybe that's a different change?
>>>>>> /Jesper
>>>>>>
>>>>>>
>>>>>>
>>>>>> 22 sep 2012 kl. 01:37 skrev John Cuthbertson<john.cuthbertson at oracle.com>:
>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> Can I have a couple of volunteers look over the fix for this CR? The 
>>>>>>> webrev can be found at: 
>>>>>>> http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>>>>>>
>>>>>>> Summary:
>>>>>>> The clipping in the code that sets the bits for a range of cards in the 
>>>>>>> "expected" card bitmap that we check the liveness accounting data 
>>>>>>> against was incorrect. This could lead to spurious verification 
>>>>>>> failures. In addition to fixing the clipping, I've upleveled this 
>>>>>>> routine and moved it into ConcurrentMark and now use it to generate the 
>>>>>>> real liveness data.
>>>>>>>
>>>>>>> Testing:
>>>>>>> The failing test cases with marking verification; jprt.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> JohnC
>>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jesper_wilhelmsson.vcf
Type: text/x-vcard
Size: 251 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120927/b7216497/jesper_wilhelmsson.vcf>

From jon.masamitsu at oracle.com  Thu Sep 27 15:24:04 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 27 Sep 2012 08:24:04 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <5063FFF8.50608@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<506330D7.5070504@oracle.com> <5063FFF8.50608@oracle.com>
Message-ID: <50646F94.5090101@oracle.com>

Mikael,

I like the idea of having some way to make CMS do a full
collection (or a CMS concurrent collection with class unloading)
for metadata but don't know how to do it.  This is a case where
the users has told CMS not to unload classes.  In the case where
that a safe thing to do, we don't want to hit the application with
class unloading periodically.  Doing that behind users' backs
drive them crazy.   Seems like we would want to do this for
the user who has said not to unload classes when the user
should really do class unloading.  How do we help the latter
user without punishing the former?

I think that a good case can be made for making CMS do
class unloading by default.   I think it was a bad decision to
make it off by default and this is a good time to fix it.
It may not even have a visible effect.  When we first
decided to make it off by default the remark phase was
serial and now it is parallel (by default).

Jon

On 09/27/12 00:27, Mikael Gerdin wrote:
> Jon,
>
> On 2012-09-26 18:44, Jon Masamitsu wrote:
>> Mikael,
>>
>> Do you want a default value (less than max uint) for MaxMetaspaceSize
>> before
>> this change goes back?
>
> While I see a value in setting some sort of "sensible" value for 
> MaxMetaspaceSize this is not really the exact issue I was worried about.
>
> Consider this scenario:
>
> * Person runs a Java app server/container with +UseConcMarkSweepGC 
> (but without +CMSClassUnloadingEnabled).
> * Some app is repeatedly deployed and un-deployed from the instance, 
> every time an app is un-deployed its class loader and classes are made 
> unreachable.
>
> In this case CMS would not opt to unload classes until 
> MaxMetaspaceSize is hit or the process/system runs out of memory.
>
> Maybe there could be some sort of threshold for when to trigger a full 
> collection (which includes class unloading) without that threshold 
> value being a limit on the amount of memory available for meta data?
>
> I know this is a complicated policy issue, and I agree that it would 
> be good if we could enable +CMSClassUnloadingEnabled and get rid of 
> the issue altogether. The question is whether or not performance 
> testing resources are available to evaluate that.
>
> /Mikael
>
>>
>> Jon
>>
>> On 9/25/2012 11:09 AM, Mikael Gerdin wrote:
>>> On 2012-09-25 18:23, Jon Masamitsu wrote:
>>>> Mikael,
>>>>
>>>> Thanks for the review.
>>>>
>>>> The expand_and_allocate() does not do a GC.  It expands
>>>> the Metaspace and does an allocation from the expanded
>>>> space.  Only if that fails does the CMS case fall through to
>>>> the full GC.
>>>
>>> Yes.
>>>
>>>>
>>>> The policy for CMS is
>>>>
>>>> 1) Hitting the HWM should start a concurrent collection if
>>>> CMS is doing class unloading.
>>>> 2) Always  expand the Metaspace and allocate from
>>>> the expanded space.
>>>> 3) If expanding the Metaspace does not provide any free
>>>> space, do a full GC to reclaim classloaders and class metadata
>>>> and then retry the allocation.
>>>
>>> But at what point does expanding the Metaspace not provide any free
>>> space? Is there some sort of back-off so that we don't just go ahead
>>> and allocate all available memory and then try to do a full gc when
>>> we've filled up the address space?
>>> I'm kind of concerned about the case with CMS without
>>> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks
>>> and cases where an application loads a bunch of classes and then
>>> releases the java level references to them but does not unload them
>>> since we don't get to the expand_and_allocate returning null.
>>>
>>> /Mikael
>>>
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>>> Jon,
>>>>>
>>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>>>
>>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>>> collection for classloader (and metadata) collection (since
>>>>>> it won't happen without class unloading).
>>>>>
>>>>> It looks like you still unconditionally call expand_and_allocate when
>>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>>> I think that the code:
>>>>>
>>>>>  213       // For CMS expand since the collection is going to be
>>>>> concurrent.
>>>>>  214       _result =
>>>>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>>>> _mdtype);
>>>>>
>>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>>> without it set then CMS users will have to take the hit of a stw full
>>>>> gc when running into the metadata threshold.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>>>
>>>>>> Also, refactored the code for readability and guarded extra
>>>>>> output with Verbose.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Jon
>>>>>
>>>
>


From mikael.gerdin at oracle.com  Thu Sep 27 15:36:50 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 27 Sep 2012 17:36:50 +0200
Subject: Request for review (s) - 7198873
In-Reply-To: <50646F94.5090101@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<506330D7.5070504@oracle.com> <5063FFF8.50608@oracle.com>
	<50646F94.5090101@oracle.com>
Message-ID: <50647292.7090808@oracle.com>

Jon,

On 2012-09-27 17:24, Jon Masamitsu wrote:
> Mikael,
>
> I like the idea of having some way to make CMS do a full
> collection (or a CMS concurrent collection with class unloading)
> for metadata but don't know how to do it.

Isn't
"heap->collect_as_vm_thread(GCCause::_metadata_GC_threshold);"
exactly what causes CMS to do a STW full collection (which includes 
unloading classes)?

> This is a case where
> the users has told CMS not to unload classes.In the case where
> that a safe thing to do, we don't want to hit the application with
> class unloading periodically.  Doing that behind users' backs
> drive them crazy.   Seems like we would want to do this for
> the user who has said not to unload classes when the user
> should really do class unloading.  How do we help the latter
> user without punishing the former?

But the net effect will be that before perm removal CMS did unload 
classes without +CMSClassUnloadingEnabled but did it as a STW full gc.
Now that won't happen until we've used up a lot of machine resources, 
which we then don't return because we don't hand back memory for unused 
chunks to the OS, right?
To tell the VM to not unload classses at all would be to use 
-ClassUnloading (or -Xnoclassgc).
Hitting the user with class unloading should only need to happen 
periodically if the user loads a lot of new classes after "warmup".
If the user then deems it unacceptable to get STW full gcs when 
loading/unloading a lot of classes he can enable +CMSClassUnloadingEnabled.


>
> I think that a good case can be made for making CMS do
> class unloading by default.   I think it was a bad decision to
> make it off by default and this is a good time to fix it.
> It may not even have a visible effect.  When we first
> decided to make it off by default the remark phase was
> serial and now it is parallel (by default).

Agreed, but it seems like a larger effort to measure the impact of that 
setting.

/Mikael

>
> Jon
>
> On 09/27/12 00:27, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2012-09-26 18:44, Jon Masamitsu wrote:
>>> Mikael,
>>>
>>> Do you want a default value (less than max uint) for MaxMetaspaceSize
>>> before
>>> this change goes back?
>>
>> While I see a value in setting some sort of "sensible" value for
>> MaxMetaspaceSize this is not really the exact issue I was worried about.
>>
>> Consider this scenario:
>>
>> * Person runs a Java app server/container with +UseConcMarkSweepGC
>> (but without +CMSClassUnloadingEnabled).
>> * Some app is repeatedly deployed and un-deployed from the instance,
>> every time an app is un-deployed its class loader and classes are made
>> unreachable.
>>
>> In this case CMS would not opt to unload classes until
>> MaxMetaspaceSize is hit or the process/system runs out of memory.
>>
>> Maybe there could be some sort of threshold for when to trigger a full
>> collection (which includes class unloading) without that threshold
>> value being a limit on the amount of memory available for meta data?
>>
>> I know this is a complicated policy issue, and I agree that it would
>> be good if we could enable +CMSClassUnloadingEnabled and get rid of
>> the issue altogether. The question is whether or not performance
>> testing resources are available to evaluate that.
>>
>> /Mikael
>>
>>>
>>> Jon
>>>
>>> On 9/25/2012 11:09 AM, Mikael Gerdin wrote:
>>>> On 2012-09-25 18:23, Jon Masamitsu wrote:
>>>>> Mikael,
>>>>>
>>>>> Thanks for the review.
>>>>>
>>>>> The expand_and_allocate() does not do a GC.  It expands
>>>>> the Metaspace and does an allocation from the expanded
>>>>> space.  Only if that fails does the CMS case fall through to
>>>>> the full GC.
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> The policy for CMS is
>>>>>
>>>>> 1) Hitting the HWM should start a concurrent collection if
>>>>> CMS is doing class unloading.
>>>>> 2) Always  expand the Metaspace and allocate from
>>>>> the expanded space.
>>>>> 3) If expanding the Metaspace does not provide any free
>>>>> space, do a full GC to reclaim classloaders and class metadata
>>>>> and then retry the allocation.
>>>>
>>>> But at what point does expanding the Metaspace not provide any free
>>>> space? Is there some sort of back-off so that we don't just go ahead
>>>> and allocate all available memory and then try to do a full gc when
>>>> we've filled up the address space?
>>>> I'm kind of concerned about the case with CMS without
>>>> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks
>>>> and cases where an application loads a bunch of classes and then
>>>> releases the java level references to them but does not unload them
>>>> since we don't get to the expand_and_allocate returning null.
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>>>> Jon,
>>>>>>
>>>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>>>>
>>>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>>>> collection for classloader (and metadata) collection (since
>>>>>>> it won't happen without class unloading).
>>>>>>
>>>>>> It looks like you still unconditionally call expand_and_allocate when
>>>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>>>> I think that the code:
>>>>>>
>>>>>>  213       // For CMS expand since the collection is going to be
>>>>>> concurrent.
>>>>>>  214       _result =
>>>>>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>>>>> _mdtype);
>>>>>>
>>>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>>>> without it set then CMS users will have to take the hit of a stw full
>>>>>> gc when running into the metadata threshold.
>>>>>>
>>>>>> /Mikael
>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>>>>
>>>>>>> Also, refactored the code for readability and guarded extra
>>>>>>> output with Verbose.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Jon
>>>>>>
>>>>
>>



From bengt.rutisson at oracle.com  Thu Sep 27 19:28:30 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 27 Sep 2012 21:28:30 +0200
Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption
In-Reply-To: <506247DF.80709@oracle.com>
References: <505B6B65.1060201@oracle.com> <505C76EC.5030902@oracle.com>
	<506247DF.80709@oracle.com>
Message-ID: <5064A8DE.2070509@oracle.com>


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.

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.

Cheers,
Bengt

On 2012-09-26 02:10, John Cuthbertson wrote:
> Hi Bengt,
>
> Thanks for the review. Replies inline...
>
> On 09/21/12 07:17, Bengt Rutisson wrote:
>>
>> Hi John,
>>
>> Thanks for doing the thorough analysis and providing the numbers. 
>> Interesting that G1 does 21703 mallocs at startup whereas Parallel 
>> only does 3500...
>>
>> However, I think I need some more background on this change. We are 
>> choosing to allocating into a single VirtualSpace instead of using 
>> separate mallocs. I understand that this will reduce the number of 
>> mallocs we do, but is that really the problem? The CR says that we 
>> run out of memory due to the fact that the GC threads allocate too 
>> much memory. We will still allocate the same amount of memory just 
>> mmapped instead of malloced, right? Do we have any test cases that 
>> fail before your fix but pass now?
> We didn't run out of memory - we ran out of C heap.
>
> There is an issue on Solaris (I have to check whether Ramki's email 
> describes the underlying problem) where by we asked for a 26Gb heap 
> (which we got) but the C heap was only given 2Gb. Vladimir saw the 
> issue during COOPs testing. In this situation we ran out of C heap 
> trying to allocate the work queues for the marking threads.
>
> Azeem submitted an issue a few weeks ago as well that ran into the 
> same problem (this time with ParallelGC/ParallelOld) and the process 
> died while trying to allocate the PSPromotionManager instances (and 
> their internal work queue) - see CR 7167969. I believe that 7197666 is 
> similar.
>
> A real reduction in memory use will come from reducing the task queue 
> size. I want to do that in a separate CR (for some or all of the 
> collectors)  provided there is no real performance difference.
>
>>
>> In fact, isn't the risk higher (at least on 32 bit platforms) that we 
>> fail to allocate the bitmaps now that we try to allocate them from 
>> one consecutive chunk of memory instead of several smaller ones? I'm 
>> thinking that if the memory is fragmented we might not get the 
>> contiguous memory we need for the VirtualSpace. But I am definitely 
>> no expert in this.
>
> Good question and I wish I knew the answer. The occupancy of the task 
> card bitmaps depends on the # of GC threads and the heap size (1 bit 
> per card) - I guess it might be possible. Should I then only be 
> allocating out of the backing store in a 64-bit JVM?
>>
>> With the above reservation I think your change looks good. Here are a 
>> couple of minor comments:
>>
>> CMMarkStack::allocate(size_t size)
>> "size" is kind of an overloaded name for an "allocate" method. Could 
>> we call it "capacity" or "number_of_entries"?
>
> Sure. Done. I renamed 'size' to 'capacity' - which matches the field 
> name. But you bring up a good point about this confusion. If we look 
> at the CMS version of the same routine:
>
> bool CMSMarkStack::allocate(size_t size) {
>   // allocate a stack of the requisite depth
>   ReservedSpace rs(ReservedSpace::allocation_align_size_up(
>                    size * sizeof(oop)));
>   if (!rs.is_reserved()) {
>     warning("CMSMarkStack allocation failure");
>     return false;
>   }
>   if (!_virtual_space.initialize(rs, rs.size())) {
>     warning("CMSMarkStack backing store failure");
>     return false;
>   }
>   assert(_virtual_space.committed_size() == rs.size(),
>          "didn't reserve backing store for all of CMS stack?");
>   _base = (oop*)(_virtual_space.low());
>   _index = 0;
>   _capacity = size;
>   NOT_PRODUCT(_max_depth = 0);
>   return true;
> }
>
> it used the parameter as the real size in bytes of the marking stack. 
> In G1, since we used NEW_C_HEAP_ARRAY, the size was multiplied by the 
> size of an oop and we got a larger marking stack than requested. 
> Instead of a 16 Mb stack (128 * 128K), we got a 128Mb stack (8 * 128 * 
> 128K). Basically we asked for the equivalent of the task queues for 
> another 128 threads:
>
> dr-evil{jcuthber}:265> ./test.sh -d64 -XX:-ZapUnusedHeapArea 
> -XX:CICompilerCount=1 -XX:ParallelGCThreads=10 -Xms20g -Xmx20g 
> -XX:+UseG1GC -XX:+PrintMallocStatistics
> Using java runtime at: 
> /net/jre.us.oracle.com/p/v42/jdk/7/fcs/b147/binaries/solaris-sparcv9/jre
> size: 16777216, MarkStackSize: 16777216, TASKQUEUE_SIZE: 131072
> os::malloc 134217728 bytes --> 0x00000001010709e8
> 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-b03-internal-fastdebug, 
> mixed mode)
> allocation stats: 24489 mallocs (212MB), 1147 frees (0MB), 4MB resrc
>
> Mimicking CMS is probably the way to go here.
>>
>>
>> Snippet In ConcurrentMark::ConcurrentMark() we use both shifting and 
>> division to accomplish the same thing on the lines after each other. 
>> Could we maybe use the same style for both cases?
>>
>>   // Card liveness bitmap size (in bits)
>>   BitMap::idx_t card_bm_size = (heap_rs.size() + 
>> CardTableModRefBS::card_size - 1)
>>                                 >> CardTableModRefBS::card_shift;
>>   // Card liveness bitmap size (in bytes)
>>   size_t card_bm_size_bytes = (card_bm_size + (BitsPerByte - 1)) / 
>> BitsPerByte;
>
> Sure. Changed the latter one to use LogBitsPerByte.
>
>> Also in ConcurrentMark::ConcurrentMark() I think  that 
>> "marked_bytes_size_bytes" is not such a great name. Probably we could 
>> skip the first "bytes" in "marked_bytes_size" and just call 
>> "marked_bytes_size_bytes" for "marked_size_bytes".
>
> OK. What about just marked_bytes_size?
>>
>> I think it would be nice to factor some of the new stuff in 
>> ConcurrentMark::ConcurrentMark() out into methods. Both the 
>> calculations of the sizes and the creation/setting of the bitmaps. 
>> But I admit that this is just a style issue.
>
> OK. I'll try a few things to pretty it up.
>
> Expect a new webrev soon.
>
> JohnC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120927/3559d4ad/attachment.htm>

From vitalyd at gmail.com  Thu Sep 27 19:41:02 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 27 Sep 2012 15:41:02 -0400
Subject: TLAB and NUMA aware allocator
In-Reply-To: <5063DC2A.6000807@oracle.com>
References: <CAHjP37GkqDqeN+L2X8vMWEERmfmKTixb6_fRFtCqQvV8-sb3mQ@mail.gmail.com>
	<CAHjP37HXd0AZJUSSv1K87hZGX8NdfV9qmLQ_qJmrLsGrw1qLqg@mail.gmail.com>
	<CAHjP37GBT9Y0Rt_JPAwENrYt6k7Wc+9ohgy3VUquYMfYNq1BBw@mail.gmail.com>
	<CAHjP37EQ5++nUdr60rf3s8Sz0-D7qkOPskKS1o0=WakRqFNwrQ@mail.gmail.com>
	<CAHjP37FYjjJasq_6Os3Jvu6kSrt9m0MqxcmSSBmex7Dn9+4LHw@mail.gmail.com>
	<5063DC2A.6000807@oracle.com>
Message-ID: <CAHjP37EZ2sXZ5qFWbdBsbuD-JfyQWobbwDc_Gg7z9L80PCb+=Q@mail.gmail.com>

Thanks Jon -- that blog entry was useful.

Vitaly

On Thu, Sep 27, 2012 at 12:55 AM, Jon Masamitsu <jon.masamitsu at oracle.com>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<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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120927/be59569d/attachment.htm>

From jon.masamitsu at oracle.com  Thu Sep 27 19:56:39 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 27 Sep 2012 12:56:39 -0700
Subject: Request for review (s) - 7198873
In-Reply-To: <50647292.7090808@oracle.com>
References: <5060D4C7.9080306@oracle.com> <5061BE52.2020902@oracle.com>
	<5061DA7B.2000804@oracle.com> <5061F34A.9000307@oracle.com>
	<506330D7.5070504@oracle.com> <5063FFF8.50608@oracle.com>
	<50646F94.5090101@oracle.com> <50647292.7090808@oracle.com>
Message-ID: <5064AF77.1050400@oracle.com>



On 09/27/12 08:36, Mikael Gerdin wrote:
> Jon,
>
> On 2012-09-27 17:24, Jon Masamitsu wrote:
>> Mikael,
>>
>> I like the idea of having some way to make CMS do a full
>> collection (or a CMS concurrent collection with class unloading)
>> for metadata but don't know how to do it.
>
> Isn't
> "heap->collect_as_vm_thread(GCCause::_metadata_GC_threshold);"
> exactly what causes CMS to do a STW full collection (which includes 
> unloading classes)?

Yes, but the code should only call that after an attempt to expand
and allocate from the Metaspace has failed.  At that point we should
be out of native memory.

>
>> This is a case where
>> the users has told CMS not to unload classes.In the case where
>> that a safe thing to do, we don't want to hit the application with
>> class unloading periodically.  Doing that behind users' backs
>> drive them crazy.   Seems like we would want to do this for
>> the user who has said not to unload classes when the user
>> should really do class unloading.  How do we help the latter
>> user without punishing the former?
>
> But the net effect will be that before perm removal CMS did unload 
> classes without +CMSClassUnloadingEnabled but did it as a STW full gc.

Yes.

> Now that won't happen until we've used up a lot of machine resources, 
> which we then don't return because we don't hand back memory for 
> unused chunks to the OS, right?
Correct but I hope to mitigate that to some degree.

> To tell the VM to not unload classses at all would be to use 
> -ClassUnloading (or -Xnoclassgc).
> Hitting the user with class unloading should only need to happen 
> periodically if the user loads a lot of new classes after "warmup".

Are you saying that if the user has -CMSClassUnloadingEnabled
and has loaded a lot of new classes after warmup, the VM should
still unload classes periodically?


> If the user then deems it unacceptable to get STW full gcs when 
> loading/unloading a lot of classes he can enable 
> +CMSClassUnloadingEnabled.

Yes, that's what they have to do now.

Jon

>
>
>>
>> I think that a good case can be made for making CMS do
>> class unloading by default.   I think it was a bad decision to
>> make it off by default and this is a good time to fix it.
>> It may not even have a visible effect.  When we first
>> decided to make it off by default the remark phase was
>> serial and now it is parallel (by default).
>
> Agreed, but it seems like a larger effort to measure the impact of 
> that setting.
>
> /Mikael
>
>>
>> Jon
>>
>> On 09/27/12 00:27, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2012-09-26 18:44, Jon Masamitsu wrote:
>>>> Mikael,
>>>>
>>>> Do you want a default value (less than max uint) for MaxMetaspaceSize
>>>> before
>>>> this change goes back?
>>>
>>> While I see a value in setting some sort of "sensible" value for
>>> MaxMetaspaceSize this is not really the exact issue I was worried 
>>> about.
>>>
>>> Consider this scenario:
>>>
>>> * Person runs a Java app server/container with +UseConcMarkSweepGC
>>> (but without +CMSClassUnloadingEnabled).
>>> * Some app is repeatedly deployed and un-deployed from the instance,
>>> every time an app is un-deployed its class loader and classes are made
>>> unreachable.
>>>
>>> In this case CMS would not opt to unload classes until
>>> MaxMetaspaceSize is hit or the process/system runs out of memory.
>>>
>>> Maybe there could be some sort of threshold for when to trigger a full
>>> collection (which includes class unloading) without that threshold
>>> value being a limit on the amount of memory available for meta data?
>>>
>>> I know this is a complicated policy issue, and I agree that it would
>>> be good if we could enable +CMSClassUnloadingEnabled and get rid of
>>> the issue altogether. The question is whether or not performance
>>> testing resources are available to evaluate that.
>>>
>>> /Mikael
>>>
>>>>
>>>> Jon
>>>>
>>>> On 9/25/2012 11:09 AM, Mikael Gerdin wrote:
>>>>> On 2012-09-25 18:23, Jon Masamitsu wrote:
>>>>>> Mikael,
>>>>>>
>>>>>> Thanks for the review.
>>>>>>
>>>>>> The expand_and_allocate() does not do a GC.  It expands
>>>>>> the Metaspace and does an allocation from the expanded
>>>>>> space.  Only if that fails does the CMS case fall through to
>>>>>> the full GC.
>>>>>
>>>>> Yes.
>>>>>
>>>>>>
>>>>>> The policy for CMS is
>>>>>>
>>>>>> 1) Hitting the HWM should start a concurrent collection if
>>>>>> CMS is doing class unloading.
>>>>>> 2) Always  expand the Metaspace and allocate from
>>>>>> the expanded space.
>>>>>> 3) If expanding the Metaspace does not provide any free
>>>>>> space, do a full GC to reclaim classloaders and class metadata
>>>>>> and then retry the allocation.
>>>>>
>>>>> But at what point does expanding the Metaspace not provide any free
>>>>> space? Is there some sort of back-off so that we don't just go ahead
>>>>> and allocate all available memory and then try to do a full gc when
>>>>> we've filled up the address space?
>>>>> I'm kind of concerned about the case with CMS without
>>>>> CMSClassUnloadingEnabled. What I'm mainly worried about is slow leaks
>>>>> and cases where an application loads a bunch of classes and then
>>>>> releases the java level references to them but does not unload them
>>>>> since we don't get to the expand_and_allocate returning null.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> On 09/25/12 07:23, Mikael Gerdin wrote:
>>>>>>> Jon,
>>>>>>>
>>>>>>> On 2012-09-24 23:46, Jon Masamitsu wrote:
>>>>>>>> NPG: VM Does not unload classes with UseConcMarkSweepGC
>>>>>>>>
>>>>>>>> If CMS is not doing class unloading, don't start a concurrent
>>>>>>>> collection for classloader (and metadata) collection (since
>>>>>>>> it won't happen without class unloading).
>>>>>>>
>>>>>>> It looks like you still unconditionally call expand_and_allocate 
>>>>>>> when
>>>>>>> running with CMS, no matter the value of CMSClassUnloadingEnabled.
>>>>>>> I think that the code:
>>>>>>>
>>>>>>>  213       // For CMS expand since the collection is going to be
>>>>>>> concurrent.
>>>>>>>  214       _result =
>>>>>>>  215 _loader_data->metaspace_non_null()->expand_and_allocate(_size,
>>>>>>> _mdtype);
>>>>>>>
>>>>>>> Should be inside the "if (CMSClassUnloadingEnabled)" and if running
>>>>>>> without it set then CMS users will have to take the hit of a stw 
>>>>>>> full
>>>>>>> gc when running into the metadata threshold.
>>>>>>>
>>>>>>> /Mikael
>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jmasa/7198873/webrev.00/
>>>>>>>>
>>>>>>>> Also, refactored the code for readability and guarded extra
>>>>>>>> output with Verbose.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Jon
>>>>>>>
>>>>>
>>>
>


From bernd-2012 at eckenfels.net  Thu Sep 27 21:16:10 2012
From: bernd-2012 at eckenfels.net (Bernd Eckenfels)
Date: Thu, 27 Sep 2012 23:16:10 +0200
Subject: Erratic(?) CMS behaviour after 5d
Message-ID: <op.wlbb08pr06c450@eckenfels02.seeburger.de>

Hello,

I have talked about this before, however I had no good trace file. Now I
have a verbose GC log.

In the attached log you see a system where CMS and ParNew are running more
or less fine and stable. But then after 5d suddenly the CMS goes wild and
shows heavy activity. I dont think it looks like the traffic/usage pattern
has changed and the old heap is pretty empty. This has been happening
repeatedly, always after 5-6d the GC goes wild and the overall system
performance drops.

The permgen is used to 75%, so I dont think it is the issue here. Here is
a jmap -heap output of the system at the end of that GC log timeframe:

Attaching to process ID 46008, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.8-b03
using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC
Heap Configuration:
      MinHeapFreeRatio = 40
      MaxHeapFreeRatio = 70
      MaxHeapSize      = 51539607552 (49152.0MB)
      NewSize          = 1310720 (1.25MB)
      MaxNewSize       = 17592186044415 MB
      OldSize          = 5439488 (5.1875MB)
      NewRatio         = 1
      SurvivorRatio    = 8
      PermSize         = 104857600 (100.0MB)
      MaxPermSize      = 314572800 (300.0MB)
Heap Usage:
New Generation (Eden + 1 Survivor Space):
      capacity = 23192862720 (22118.4375MB)
      used     = 19142525576 (18255.734992980957MB)
      free     = 4050337144 (3862.702507019043MB)
      82.5362776777562% used
Eden Space:
      capacity = 20615921664 (19660.875MB)
      used     = 18511946216 (17654.367652893066MB)
      free     = 2103975448 (2006.5073471069336MB)
      89.79441481059753% used
   From Space:
      capacity = 2576941056 (2457.5625MB)
      used     = 630579360 (601.3673400878906MB)
      free     = 1946361696 (1856.1951599121094MB)
      24.47007309429122% used
To Space:
      capacity = 2576941056 (2457.5625MB)
      used     = 0 (0.0MB)
      free     = 2576941056 (2457.5625MB)
      0.0% used
concurrent mark-sweep generation:
      capacity = 25769803776 (24576.0MB)
      used     = 1704634416 (1625.6660614013672MB)
      free     = 24065169360 (22950.333938598633MB)
      6.614852137863636% used
Perm Generation:
      capacity = 314572800 (300.0MB)
      used     = 238131048 (227.0994644165039MB)
      free     = 76441752 (72.9005355834961MB)
      75.69982147216797% used


(note that "heap configuration" seems to be broken, I specified
NewRatio=1, but the NewSize and MaxNewSize displayed by jmap are way off)

Any Idea what can cause the GC go wild, here is an  excerpt (note that
ParNew happens only every 300s, after 10 of those one CMS happens, etc):


God NewGC/CMS/NewGC Cycle:

14586.770: [GC 14586.772: [ParNew: 1991511K->319572K(22649280K), 0.0489290
secs] 3229450K->1573413K(47815104K), 0.0513610 secs] [Times: user=1.29
sys=0.01, real=0.05 secs]
14586.834: [GC [1 CMS-initial-mark: 1253840K(25165824K)]
1573413K(47815104K), 0.2554070 secs] [Times: user=0.26 sys=0.00, real=0.26
secs]
14587.091: [CMS-concurrent-mark-start]
14587.506: [CMS-concurrent-mark: 0.276/0.415 secs] [Times: user=4.29
sys=0.06, real=0.41 secs]
14587.507: [CMS-concurrent-preclean-start]
14587.592: [CMS-concurrent-preclean: 0.085/0.085 secs] [Times: user=0.13
sys=0.03, real=0.09 secs]
14587.592: [CMS-concurrent-abortable-preclean-start]
    CMS: abort preclean due to time 14592.774:
[CMS-concurrent-abortable-preclean: 5.180/5.182 secs] [Times: user=7.45
sys=0.42, real=5.18 secs]
14592.786: [GC[YG occupancy: 860025 K (22649280 K)]14592.787: [Rescan
(parallel) , 0.1106510 secs]14592.898: [weak refs processing, 0.0009520
secs]14592.899: [class unloading, 0.0440260 secs]14592.943: [scrub symbol
& string tables, 0.0386660 secs] [1 CMS-remark: 1253840K(25165824K)]
2113866K(47815104K), 0.2091080 secs] [Times: user=5.65 sys=0.02, real=0.21
secs]
14592.997: [CMS-concurrent-sweep-start]
14594.081: [CMS-concurrent-sweep: 1.084/1.084 secs] [Times: user=1.43
sys=0.10, real=1.09 secs]
14594.081: [CMS-concurrent-reset-start]
14594.190: [CMS-concurrent-reset: 0.108/0.108 secs] [Times: user=0.17
sys=0.00, real=0.11 secs]
15041.297: [GC 15041.299: [ParNew: 20452429K->555085K(22649280K),
0.3904490 secs] 21375098K->1485221K(47815104K), 0.3937640 secs] [Times:
user=2.23 sys=0.04, real=0.39 secs]
15041.706: [GC 15041.707: [ParNew: 598821K->603384K(22649280K), 0.0499560
secs] 1528957K->1542532K(47815104K), 0.0520930 secs] [Times: user=1.88
sys=0.01, real=0.05 secs]
15583.968: [GC 15583.970: [ParNew: 20736120K->479921K(22649280K),
0.3162220 secs] 21675269K->1438894K(47815104K), 0.3195300 secs] [Times:
user=1.66 sys=0.02, real=0.32 secs]
15952.644: [GC 15952.646: [ParNew: 20612657K->469661K(22649280K),
0.2957950 secs] 21571630K->1429526K(47815104K), 0.2989230 secs] [Times:
user=1.73 sys=0.01, real=0.30 secs]
16324.194: [GC 16324.196: [ParNew: 20602397K->394671K(22649280K),
0.3984460 secs] 21562262K->1388556K(47815104K), 0.4017930 secs] [Times:
user=2.08 sys=0.04, real=0.40 secs]
16686.481: [GC 16686.484: [ParNew: 20527410K->515765K(22649280K),
0.2218350 secs] 21521295K->1509652K(47815104K), 0.2252750 secs] [Times:
user=1.90 sys=0.03, real=0.23 secs]
16988.880: [GC 16988.882: [ParNew: 20649063K->617925K(22649280K),
0.4101530 secs] 21642950K->1638935K(47815104K), 0.4135050 secs] [Times:
user=2.38 sys=0.02, real=0.41 secs]
16989.316: [GC 16989.317: [ParNew: 796218K->679931K(22649280K), 0.0544170
secs] 1817228K->1718567K(47815104K), 0.0566550 secs] [Times: user=1.92
sys=0.04, real=0.06 secs]
17292.082: [GC 17292.085: [ParNew: 20812672K->520352K(22649280K),
0.3049860 secs] 21851308K->1566872K(47815104K), 0.3082490 secs] [Times:
user=1.57 sys=0.02, real=0.30 secs]
17564.795: [GC 17564.797: [ParNew: 20653088K->473652K(22649280K),
0.3699550 secs] 21699608K->1572756K(47815104K), 0.3731990 secs] [Times:
user=2.03 sys=0.05, real=0.37 secs]
17974.219: [GC 17974.221: [ParNew: 20606388K->423143K(22649280K),
0.3992190 secs] 21705492K->1572876K(47815104K), 0.4026250 secs] [Times:
user=1.71 sys=0.03, real=0.40 secs]
18194.094: [GC 18194.096: [ParNew: 13619215K->538306K(22649280K),
0.2371980 secs] 14768948K->1688055K(47815104K), 0.2400000 secs] [Times:
user=2.16 sys=0.03, real=0.24 secs]


Here it becomes wild after 5d:

467312.874: [GC 467312.876: [ParNew: 20650041K->551029K(22649280K),
0.4254210 secs] 22325555K->2243659K(47815104K), 0.4291600 secs] [Times:
user=2.61 sys=0.04, real=0.44 secs]
467519.696: [GC 467519.698: [ParNew: 20683765K->513430K(22649280K),
0.2666780 secs] 22376395K->2210010K(47815104K), 0.2703630 secs] [Times:
user=2.39 sys=0.02, real=0.27 secs]
467523.989: [GC [1 CMS-initial-mark: 1696579K(25165824K)]
2728951K(47815104K), 0.7737110 secs] [Times: user=0.77 sys=0.00, real=0.78
secs]
467524.765: [CMS-concurrent-mark-start]
467525.201: [CMS-concurrent-mark: 0.420/0.436 secs] [Times: user=6.69
sys=0.08, real=0.44 secs]
467525.201: [CMS-concurrent-preclean-start]
467525.314: [CMS-concurrent-preclean: 0.111/0.113 secs] [Times: user=0.31
sys=0.01, real=0.11 secs]
467525.315: [CMS-concurrent-abortable-preclean-start]
    CMS: abort preclean due to time 467531.001:
[CMS-concurrent-abortable-preclean: 5.664/5.687 secs] [Times: user=10.99
sys=0.46, real=5.69 secs]
467531.022: [GC[YG occupancy: 1673737 K (22649280 K)]467531.024: [Rescan
(parallel) , 0.5323440 secs]467531.556: [weak refs processing, 0.0010300
secs]467531.557: [class unloading, 0.0550310 secs]467531.612: [scrub
symbol & string tables, 0.0447430 secs] [1 CMS-remark:
1696579K(25165824K)] 3370316K(47815104K), 0.6511260 secs] [Times:
user=25.71 sys=0.07, real=0.65 secs]
467531.676: [CMS-concurrent-sweep-start]
467534.168: [CMS-concurrent-sweep: 2.492/2.492 secs] [Times: user=6.17
sys=0.33, real=2.49 secs]
467534.168: [CMS-concurrent-reset-start]
467534.278: [CMS-concurrent-reset: 0.110/0.110 secs] [Times: user=0.23
sys=0.02, real=0.11 secs]
467581.647: [GC [1 CMS-initial-mark: 1352729K(25165824K)]
7579835K(47815104K), 5.2493880 secs] [Times: user=5.24 sys=0.01, real=5.25
secs]
467586.898: [CMS-concurrent-mark-start]
467587.639: [CMS-concurrent-mark: 0.455/0.740 secs] [Times: user=7.50
sys=0.17, real=0.74 secs]
467587.639: [CMS-concurrent-preclean-start]
467587.801: [CMS-concurrent-preclean: 0.153/0.162 secs] [Times: user=0.32
sys=0.02, real=0.16 secs]
467587.802: [CMS-concurrent-abortable-preclean-start]
    CMS: abort preclean due to time 467593.476:
[CMS-concurrent-abortable-preclean: 5.671/5.674 secs] [Times: user=20.61
sys=0.75, real=5.68 secs]
467593.497: [GC[YG occupancy: 7185297 K (22649280 K)]467593.499: [Rescan
(parallel) , 4.9687880 secs]467598.468: [weak refs processing, 0.0000570
secs]467598.468: [class unloading, 0.0540020 secs]467598.522: [scrub
symbol & string tables, 0.0434850 secs] [1 CMS-remark:
1352729K(25165824K)] 8538026K(47815104K), 5.0845650 secs] [Times:
user=235.75 sys=0.66, real=5.08 secs]
467598.584: [CMS-concurrent-sweep-start]
467601.429: [CMS-concurrent-sweep: 2.801/2.845 secs] [Times: user=11.65
sys=0.42, real=2.85 secs]
467601.429: [CMS-concurrent-reset-start]
467601.539: [CMS-concurrent-reset: 0.109/0.109 secs] [Times: user=0.20
sys=0.01, real=0.11 secs]
467603.561: [GC [1 CMS-initial-mark: 1352455K(25165824K)]
9474109K(47815104K), 7.1588640 secs] [Times: user=7.14 sys=0.01, real=7.16
secs]
467610.722: [CMS-concurrent-mark-start]
467611.120: [CMS-concurrent-mark: 0.397/0.398 secs] [Times: user=7.28
sys=0.16, real=0.40 secs]
467611.120: [CMS-concurrent-preclean-start]
467611.224: [CMS-concurrent-preclean: 0.102/0.104 secs] [Times: user=0.58
sys=0.03, real=0.11 secs]
467611.225: [CMS-concurrent-abortable-preclean-start]
    CMS: abort preclean due to time 467617.031:
[CMS-concurrent-abortable-preclean: 5.667/5.806 secs] [Times: user=13.49
sys=0.50, real=5.80 secs]
467617.052: [GC[YG occupancy: 8991850 K (22649280 K)]467617.053: [Rescan
(parallel) , 6.1182390 secs]467623.172: [weak refs processing, 0.0000610
secs]467623.172: [class unloading, 0.1001680 secs]467623.272: [scrub
symbol & string tables, 0.0434510 secs] [1 CMS-remark:
1352455K(25165824K)] 10344305K(47815104K), 6.2801570 secs] [Times:
user=288.78 sys=0.80, real=6.28 secs]
467623.334: [CMS-concurrent-sweep-start]
467625.074: [CMS-concurrent-sweep: 1.706/1.740 secs] [Times: user=3.86
sys=0.20, real=1.74 secs]
467625.074: [CMS-concurrent-reset-start]
467625.184: [CMS-concurrent-reset: 0.110/0.110 secs] [Times: user=0.27
sys=0.01, real=0.12 secs]
467627.206: [GC [1 CMS-initial-mark: 1352264K(25165824K)]
10644634K(47815104K), 8.0760290 secs] [Times: user=8.06 sys=0.00,
real=8.07 secs]
467635.284: [CMS-concurrent-mark-start]
467635.710: [CMS-concurrent-mark: 0.404/0.427 secs] [Times: user=6.72
sys=0.23, real=0.42 secs]
467635.711: [CMS-concurrent-preclean-start]
467635.814: [CMS-concurrent-preclean: 0.101/0.103 secs] [Times: user=0.33
sys=0.03, real=0.10 secs]
467635.814: [CMS-concurrent-abortable-preclean-start]
    CMS: abort preclean due to time 467641.531:
[CMS-concurrent-abortable-preclean: 5.690/5.717 secs] [Times: user=17.67
sys=0.85, real=5.73 secs]
467641.552: [GC[YG occupancy: 10330198 K (22649280 K)]467641.554: [Rescan
(parallel) , 7.7808590 secs]467649.335: [weak refs processing, 0.0001180
secs]467649.335: [class unloading, 0.1016250 secs]467649.437: [scrub
symbol & string tables, 0.0437740 secs] [1 CMS-remark:
1352264K(25165824K)] 11682462K(47815104K), 7.9447800 secs] [Times:
user=368.46 sys=1.14, real=7.94 secs]
467649.499: [CMS-concurrent-sweep-start]
467651.175: [CMS-concurrent-sweep: 1.595/1.676 secs] [Times: user=10.23
sys=0.41, real=1.68 secs]
467651.176: [CMS-concurrent-reset-start]
467651.285: [CMS-concurrent-reset: 0.109/0.109 secs] [Times: user=0.58
sys=0.00, real=0.11 secs]
467652.306: [GC [1 CMS-initial-mark: 1352044K(25165824K)]
12914694K(47815104K), 10.0236240 secs] [Times: user=10.01 sys=0.01,
real=10.02 secs]
467662.332: [CMS-concurrent-mark-start]

You can find the GC log (1.6MB) here:

https://mft.seeburger.de/portal-seefx/~public/46ed46f6-69f8-4f05-929a-5af9ab19b57f?download

Greetings
Bernd


From john.cuthbertson at oracle.com  Thu Sep 27 22:06:02 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 27 Sep 2012 15:06:02 -0700
Subject: RFR(M): 7188263: G1: Excessive c_heap (malloc) consumption
In-Reply-To: <5064A8DE.2070509@oracle.com>
References: <505B6B65.1060201@oracle.com> <505C76EC.5030902@oracle.com>
	<506247DF.80709@oracle.com> <5064A8DE.2070509@oracle.com>
Message-ID: <5064CDCA.6030102@oracle.com>

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.

>
> 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?

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.

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.

Regards,

JohnC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120927/a6300b6e/attachment.htm>

From john.cuthbertson at oracle.com  Fri Sep 28 01:36:05 2012
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Fri, 28 Sep 2012 01:36:05 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7200261: G1: Liveness counting
	inconsistencies during marking verification
Message-ID: <20120928013611.3DFF6470D7@hg.openjdk.java.net>

Changeset: 988bf00cc564
Author:    johnc
Date:      2012-09-27 15:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/988bf00cc564

7200261: G1: Liveness counting inconsistencies during marking verification
Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures.
Reviewed-by: brutisso, jwilhelm, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp



From azeem.jiva at oracle.com  Fri Sep 28 13:18:07 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Fri, 28 Sep 2012 08:18:07 -0500
Subject: Erratic(?) CMS behaviour after 5d
In-Reply-To: <op.wlbb08pr06c450@eckenfels02.seeburger.de>
References: <op.wlbb08pr06c450@eckenfels02.seeburger.de>
Message-ID: <5065A38F.4080202@oracle.com>

You're seeing concurrent mode failures (see attached graph).  I'd 
recommend trying these flags:

-XX:CMSInitiatingOccupancyFraction=60 (or something smaller, experiment 
here)

It's also possible you are running out of old gen space, try increasing 
your old gen size as well.


On 09/27/2012 04:16 PM, Bernd Eckenfels wrote:
> Hello,
>
> I have talked about this before, however I had no good trace file. Now I
> have a verbose GC log.
>
> In the attached log you see a system where CMS and ParNew are running 
> more
> or less fine and stable. But then after 5d suddenly the CMS goes wild and
> shows heavy activity. I dont think it looks like the traffic/usage 
> pattern
> has changed and the old heap is pretty empty. This has been happening
> repeatedly, always after 5-6d the GC goes wild and the overall system
> performance drops.
>
> The permgen is used to 75%, so I dont think it is the issue here. Here is
> a jmap -heap output of the system at the end of that GC log timeframe:
>
> Attaching to process ID 46008, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 20.8-b03
> using parallel threads in the new generation.
> using thread-local object allocation.
> Concurrent Mark-Sweep GC
> Heap Configuration:
>      MinHeapFreeRatio = 40
>      MaxHeapFreeRatio = 70
>      MaxHeapSize      = 51539607552 (49152.0MB)
>      NewSize          = 1310720 (1.25MB)
>      MaxNewSize       = 17592186044415 MB
>      OldSize          = 5439488 (5.1875MB)
>      NewRatio         = 1
>      SurvivorRatio    = 8
>      PermSize         = 104857600 (100.0MB)
>      MaxPermSize      = 314572800 (300.0MB)
> Heap Usage:
> New Generation (Eden + 1 Survivor Space):
>      capacity = 23192862720 (22118.4375MB)
>      used     = 19142525576 (18255.734992980957MB)
>      free     = 4050337144 (3862.702507019043MB)
>      82.5362776777562% used
> Eden Space:
>      capacity = 20615921664 (19660.875MB)
>      used     = 18511946216 (17654.367652893066MB)
>      free     = 2103975448 (2006.5073471069336MB)
>      89.79441481059753% used
>   From Space:
>      capacity = 2576941056 (2457.5625MB)
>      used     = 630579360 (601.3673400878906MB)
>      free     = 1946361696 (1856.1951599121094MB)
>      24.47007309429122% used
> To Space:
>      capacity = 2576941056 (2457.5625MB)
>      used     = 0 (0.0MB)
>      free     = 2576941056 (2457.5625MB)
>      0.0% used
> concurrent mark-sweep generation:
>      capacity = 25769803776 (24576.0MB)
>      used     = 1704634416 (1625.6660614013672MB)
>      free     = 24065169360 (22950.333938598633MB)
>      6.614852137863636% used
> Perm Generation:
>      capacity = 314572800 (300.0MB)
>      used     = 238131048 (227.0994644165039MB)
>      free     = 76441752 (72.9005355834961MB)
>      75.69982147216797% used
>
>
> (note that "heap configuration" seems to be broken, I specified
> NewRatio=1, but the NewSize and MaxNewSize displayed by jmap are way off)
>
> Any Idea what can cause the GC go wild, here is an  excerpt (note that
> ParNew happens only every 300s, after 10 of those one CMS happens, etc):
>
>
> God NewGC/CMS/NewGC Cycle:
>
> 14586.770: [GC 14586.772: [ParNew: 1991511K->319572K(22649280K), 
> 0.0489290
> secs] 3229450K->1573413K(47815104K), 0.0513610 secs] [Times: user=1.29
> sys=0.01, real=0.05 secs]
> 14586.834: [GC [1 CMS-initial-mark: 1253840K(25165824K)]
> 1573413K(47815104K), 0.2554070 secs] [Times: user=0.26 sys=0.00, 
> real=0.26
> secs]
> 14587.091: [CMS-concurrent-mark-start]
> 14587.506: [CMS-concurrent-mark: 0.276/0.415 secs] [Times: user=4.29
> sys=0.06, real=0.41 secs]
> 14587.507: [CMS-concurrent-preclean-start]
> 14587.592: [CMS-concurrent-preclean: 0.085/0.085 secs] [Times: user=0.13
> sys=0.03, real=0.09 secs]
> 14587.592: [CMS-concurrent-abortable-preclean-start]
>    CMS: abort preclean due to time 14592.774:
> [CMS-concurrent-abortable-preclean: 5.180/5.182 secs] [Times: user=7.45
> sys=0.42, real=5.18 secs]
> 14592.786: [GC[YG occupancy: 860025 K (22649280 K)]14592.787: [Rescan
> (parallel) , 0.1106510 secs]14592.898: [weak refs processing, 0.0009520
> secs]14592.899: [class unloading, 0.0440260 secs]14592.943: [scrub symbol
> & string tables, 0.0386660 secs] [1 CMS-remark: 1253840K(25165824K)]
> 2113866K(47815104K), 0.2091080 secs] [Times: user=5.65 sys=0.02, 
> real=0.21
> secs]
> 14592.997: [CMS-concurrent-sweep-start]
> 14594.081: [CMS-concurrent-sweep: 1.084/1.084 secs] [Times: user=1.43
> sys=0.10, real=1.09 secs]
> 14594.081: [CMS-concurrent-reset-start]
> 14594.190: [CMS-concurrent-reset: 0.108/0.108 secs] [Times: user=0.17
> sys=0.00, real=0.11 secs]
> 15041.297: [GC 15041.299: [ParNew: 20452429K->555085K(22649280K),
> 0.3904490 secs] 21375098K->1485221K(47815104K), 0.3937640 secs] [Times:
> user=2.23 sys=0.04, real=0.39 secs]
> 15041.706: [GC 15041.707: [ParNew: 598821K->603384K(22649280K), 0.0499560
> secs] 1528957K->1542532K(47815104K), 0.0520930 secs] [Times: user=1.88
> sys=0.01, real=0.05 secs]
> 15583.968: [GC 15583.970: [ParNew: 20736120K->479921K(22649280K),
> 0.3162220 secs] 21675269K->1438894K(47815104K), 0.3195300 secs] [Times:
> user=1.66 sys=0.02, real=0.32 secs]
> 15952.644: [GC 15952.646: [ParNew: 20612657K->469661K(22649280K),
> 0.2957950 secs] 21571630K->1429526K(47815104K), 0.2989230 secs] [Times:
> user=1.73 sys=0.01, real=0.30 secs]
> 16324.194: [GC 16324.196: [ParNew: 20602397K->394671K(22649280K),
> 0.3984460 secs] 21562262K->1388556K(47815104K), 0.4017930 secs] [Times:
> user=2.08 sys=0.04, real=0.40 secs]
> 16686.481: [GC 16686.484: [ParNew: 20527410K->515765K(22649280K),
> 0.2218350 secs] 21521295K->1509652K(47815104K), 0.2252750 secs] [Times:
> user=1.90 sys=0.03, real=0.23 secs]
> 16988.880: [GC 16988.882: [ParNew: 20649063K->617925K(22649280K),
> 0.4101530 secs] 21642950K->1638935K(47815104K), 0.4135050 secs] [Times:
> user=2.38 sys=0.02, real=0.41 secs]
> 16989.316: [GC 16989.317: [ParNew: 796218K->679931K(22649280K), 0.0544170
> secs] 1817228K->1718567K(47815104K), 0.0566550 secs] [Times: user=1.92
> sys=0.04, real=0.06 secs]
> 17292.082: [GC 17292.085: [ParNew: 20812672K->520352K(22649280K),
> 0.3049860 secs] 21851308K->1566872K(47815104K), 0.3082490 secs] [Times:
> user=1.57 sys=0.02, real=0.30 secs]
> 17564.795: [GC 17564.797: [ParNew: 20653088K->473652K(22649280K),
> 0.3699550 secs] 21699608K->1572756K(47815104K), 0.3731990 secs] [Times:
> user=2.03 sys=0.05, real=0.37 secs]
> 17974.219: [GC 17974.221: [ParNew: 20606388K->423143K(22649280K),
> 0.3992190 secs] 21705492K->1572876K(47815104K), 0.4026250 secs] [Times:
> user=1.71 sys=0.03, real=0.40 secs]
> 18194.094: [GC 18194.096: [ParNew: 13619215K->538306K(22649280K),
> 0.2371980 secs] 14768948K->1688055K(47815104K), 0.2400000 secs] [Times:
> user=2.16 sys=0.03, real=0.24 secs]
>
>
> Here it becomes wild after 5d:
>
> 467312.874: [GC 467312.876: [ParNew: 20650041K->551029K(22649280K),
> 0.4254210 secs] 22325555K->2243659K(47815104K), 0.4291600 secs] [Times:
> user=2.61 sys=0.04, real=0.44 secs]
> 467519.696: [GC 467519.698: [ParNew: 20683765K->513430K(22649280K),
> 0.2666780 secs] 22376395K->2210010K(47815104K), 0.2703630 secs] [Times:
> user=2.39 sys=0.02, real=0.27 secs]
> 467523.989: [GC [1 CMS-initial-mark: 1696579K(25165824K)]
> 2728951K(47815104K), 0.7737110 secs] [Times: user=0.77 sys=0.00, 
> real=0.78
> secs]
> 467524.765: [CMS-concurrent-mark-start]
> 467525.201: [CMS-concurrent-mark: 0.420/0.436 secs] [Times: user=6.69
> sys=0.08, real=0.44 secs]
> 467525.201: [CMS-concurrent-preclean-start]
> 467525.314: [CMS-concurrent-preclean: 0.111/0.113 secs] [Times: user=0.31
> sys=0.01, real=0.11 secs]
> 467525.315: [CMS-concurrent-abortable-preclean-start]
>    CMS: abort preclean due to time 467531.001:
> [CMS-concurrent-abortable-preclean: 5.664/5.687 secs] [Times: user=10.99
> sys=0.46, real=5.69 secs]
> 467531.022: [GC[YG occupancy: 1673737 K (22649280 K)]467531.024: [Rescan
> (parallel) , 0.5323440 secs]467531.556: [weak refs processing, 0.0010300
> secs]467531.557: [class unloading, 0.0550310 secs]467531.612: [scrub
> symbol & string tables, 0.0447430 secs] [1 CMS-remark:
> 1696579K(25165824K)] 3370316K(47815104K), 0.6511260 secs] [Times:
> user=25.71 sys=0.07, real=0.65 secs]
> 467531.676: [CMS-concurrent-sweep-start]
> 467534.168: [CMS-concurrent-sweep: 2.492/2.492 secs] [Times: user=6.17
> sys=0.33, real=2.49 secs]
> 467534.168: [CMS-concurrent-reset-start]
> 467534.278: [CMS-concurrent-reset: 0.110/0.110 secs] [Times: user=0.23
> sys=0.02, real=0.11 secs]
> 467581.647: [GC [1 CMS-initial-mark: 1352729K(25165824K)]
> 7579835K(47815104K), 5.2493880 secs] [Times: user=5.24 sys=0.01, 
> real=5.25
> secs]
> 467586.898: [CMS-concurrent-mark-start]
> 467587.639: [CMS-concurrent-mark: 0.455/0.740 secs] [Times: user=7.50
> sys=0.17, real=0.74 secs]
> 467587.639: [CMS-concurrent-preclean-start]
> 467587.801: [CMS-concurrent-preclean: 0.153/0.162 secs] [Times: user=0.32
> sys=0.02, real=0.16 secs]
> 467587.802: [CMS-concurrent-abortable-preclean-start]
>    CMS: abort preclean due to time 467593.476:
> [CMS-concurrent-abortable-preclean: 5.671/5.674 secs] [Times: user=20.61
> sys=0.75, real=5.68 secs]
> 467593.497: [GC[YG occupancy: 7185297 K (22649280 K)]467593.499: [Rescan
> (parallel) , 4.9687880 secs]467598.468: [weak refs processing, 0.0000570
> secs]467598.468: [class unloading, 0.0540020 secs]467598.522: [scrub
> symbol & string tables, 0.0434850 secs] [1 CMS-remark:
> 1352729K(25165824K)] 8538026K(47815104K), 5.0845650 secs] [Times:
> user=235.75 sys=0.66, real=5.08 secs]
> 467598.584: [CMS-concurrent-sweep-start]
> 467601.429: [CMS-concurrent-sweep: 2.801/2.845 secs] [Times: user=11.65
> sys=0.42, real=2.85 secs]
> 467601.429: [CMS-concurrent-reset-start]
> 467601.539: [CMS-concurrent-reset: 0.109/0.109 secs] [Times: user=0.20
> sys=0.01, real=0.11 secs]
> 467603.561: [GC [1 CMS-initial-mark: 1352455K(25165824K)]
> 9474109K(47815104K), 7.1588640 secs] [Times: user=7.14 sys=0.01, 
> real=7.16
> secs]
> 467610.722: [CMS-concurrent-mark-start]
> 467611.120: [CMS-concurrent-mark: 0.397/0.398 secs] [Times: user=7.28
> sys=0.16, real=0.40 secs]
> 467611.120: [CMS-concurrent-preclean-start]
> 467611.224: [CMS-concurrent-preclean: 0.102/0.104 secs] [Times: user=0.58
> sys=0.03, real=0.11 secs]
> 467611.225: [CMS-concurrent-abortable-preclean-start]
>    CMS: abort preclean due to time 467617.031:
> [CMS-concurrent-abortable-preclean: 5.667/5.806 secs] [Times: user=13.49
> sys=0.50, real=5.80 secs]
> 467617.052: [GC[YG occupancy: 8991850 K (22649280 K)]467617.053: [Rescan
> (parallel) , 6.1182390 secs]467623.172: [weak refs processing, 0.0000610
> secs]467623.172: [class unloading, 0.1001680 secs]467623.272: [scrub
> symbol & string tables, 0.0434510 secs] [1 CMS-remark:
> 1352455K(25165824K)] 10344305K(47815104K), 6.2801570 secs] [Times:
> user=288.78 sys=0.80, real=6.28 secs]
> 467623.334: [CMS-concurrent-sweep-start]
> 467625.074: [CMS-concurrent-sweep: 1.706/1.740 secs] [Times: user=3.86
> sys=0.20, real=1.74 secs]
> 467625.074: [CMS-concurrent-reset-start]
> 467625.184: [CMS-concurrent-reset: 0.110/0.110 secs] [Times: user=0.27
> sys=0.01, real=0.12 secs]
> 467627.206: [GC [1 CMS-initial-mark: 1352264K(25165824K)]
> 10644634K(47815104K), 8.0760290 secs] [Times: user=8.06 sys=0.00,
> real=8.07 secs]
> 467635.284: [CMS-concurrent-mark-start]
> 467635.710: [CMS-concurrent-mark: 0.404/0.427 secs] [Times: user=6.72
> sys=0.23, real=0.42 secs]
> 467635.711: [CMS-concurrent-preclean-start]
> 467635.814: [CMS-concurrent-preclean: 0.101/0.103 secs] [Times: user=0.33
> sys=0.03, real=0.10 secs]
> 467635.814: [CMS-concurrent-abortable-preclean-start]
>    CMS: abort preclean due to time 467641.531:
> [CMS-concurrent-abortable-preclean: 5.690/5.717 secs] [Times: user=17.67
> sys=0.85, real=5.73 secs]
> 467641.552: [GC[YG occupancy: 10330198 K (22649280 K)]467641.554: [Rescan
> (parallel) , 7.7808590 secs]467649.335: [weak refs processing, 0.0001180
> secs]467649.335: [class unloading, 0.1016250 secs]467649.437: [scrub
> symbol & string tables, 0.0437740 secs] [1 CMS-remark:
> 1352264K(25165824K)] 11682462K(47815104K), 7.9447800 secs] [Times:
> user=368.46 sys=1.14, real=7.94 secs]
> 467649.499: [CMS-concurrent-sweep-start]
> 467651.175: [CMS-concurrent-sweep: 1.595/1.676 secs] [Times: user=10.23
> sys=0.41, real=1.68 secs]
> 467651.176: [CMS-concurrent-reset-start]
> 467651.285: [CMS-concurrent-reset: 0.109/0.109 secs] [Times: user=0.58
> sys=0.00, real=0.11 secs]
> 467652.306: [GC [1 CMS-initial-mark: 1352044K(25165824K)]
> 12914694K(47815104K), 10.0236240 secs] [Times: user=10.01 sys=0.01,
> real=10.02 secs]
> 467662.332: [CMS-concurrent-mark-start]
>
> You can find the GC log (1.6MB) here:
>
> https://mft.seeburger.de/portal-seefx/~public/46ed46f6-69f8-4f05-929a-5af9ab19b57f?download 
>
>
> Greetings
> Bernd

-- 
Azeem Jiva
@javawithjiva

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2012-09-28 08:16:35.png
Type: image/png
Size: 33938 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120928/d830e2a7/35.png>

From stefan.karlsson at oracle.com  Fri Sep 28 13:49:52 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 28 Sep 2012 15:49:52 +0200
Subject: Review request: 8000230: Change os::print_location to be more
	descriptive when a location is pointing into an object
Message-ID: <5065AB00.5020903@oracle.com>

http://cr.openjdk.java.net/~stefank/8000230/webrev/

 From the bug:
---
When printing the "Register to memory mapping:" hs_err section, it's 
easy to get fooled when a register points into an object.

For example:
R13=0xfffffd7fcf900064 is an oop
[Ljava.lang.Object;
  - klass: 'java/lang/Object'[]
  - length: 327680

seems to indicate that an object starts at address 0xfffffd7fcf900064. 
In this case the real object start was at address 0xfffffd7fcf900000.

I propose that we change this line to:
R13=0xfffffd7fcf900064 is pointing into object: 0xfffffd7fcf900000
[Ljava.lang.Object;
  - klass: 'java/lang/Object'[]
  - length: 327680

If the address seems to be pointing at the start of an object, the old 
output can still be used.
---

StefanK


From mikael.gerdin at oracle.com  Fri Sep 28 14:11:50 2012
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 28 Sep 2012 16:11:50 +0200
Subject: Review request: 8000230: Change os::print_location to be more
	descriptive when a location is pointing into an object
In-Reply-To: <5065AB00.5020903@oracle.com>
References: <5065AB00.5020903@oracle.com>
Message-ID: <5065B026.20408@oracle.com>

Stefan,

On 2012-09-28 15:49, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8000230/webrev/

Looks good to me.

/Mikael

>
>  From the bug:
> ---
> When printing the "Register to memory mapping:" hs_err section, it's
> easy to get fooled when a register points into an object.
>
> For example:
> R13=0xfffffd7fcf900064 is an oop
> [Ljava.lang.Object;
>   - klass: 'java/lang/Object'[]
>   - length: 327680
>
> seems to indicate that an object starts at address 0xfffffd7fcf900064.
> In this case the real object start was at address 0xfffffd7fcf900000.
>
> I propose that we change this line to:
> R13=0xfffffd7fcf900064 is pointing into object: 0xfffffd7fcf900000
> [Ljava.lang.Object;
>   - klass: 'java/lang/Object'[]
>   - length: 327680
>
> If the address seems to be pointing at the start of an object, the old
> output can still be used.
> ---
>
> StefanK

-- 
Mikael Gerdin
Java SE VM SQE Stockholm


From christian.thalinger at oracle.com  Fri Sep 28 16:10:27 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 28 Sep 2012 09:10:27 -0700
Subject: Review request: 8000230: Change os::print_location to be more
	descriptive when a location is pointing into an object
In-Reply-To: <5065AB00.5020903@oracle.com>
References: <5065AB00.5020903@oracle.com>
Message-ID: <2993425A-EAA9-4743-8373-36806B7319F6@oracle.com>


On Sep 28, 2012, at 6:49 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:

> http://cr.openjdk.java.net/~stefank/8000230/webrev/
> 
> From the bug:
> ---
> When printing the "Register to memory mapping:" hs_err section, it's easy to get fooled when a register points into an object.
> 
> For example:
> R13=0xfffffd7fcf900064 is an oop
> [Ljava.lang.Object;
> - klass: 'java/lang/Object'[]
> - length: 327680
> 
> seems to indicate that an object starts at address 0xfffffd7fcf900064. In this case the real object start was at address 0xfffffd7fcf900000.
> 
> I propose that we change this line to:
> R13=0xfffffd7fcf900064 is pointing into object: 0xfffffd7fcf900000
> [Ljava.lang.Object;
> - klass: 'java/lang/Object'[]
> - length: 327680
> 
> If the address seems to be pointing at the start of an object, the old output can still be used.

Yes, that's helpful.  Thanks.  Looks good.  -- Chris

> ---
> 
> StefanK


From azeem.jiva at oracle.com  Fri Sep 28 18:08:53 2012
From: azeem.jiva at oracle.com (Azeem Jiva)
Date: Fri, 28 Sep 2012 13:08:53 -0500
Subject: Getting the Heap virtual addresses?
Message-ID: <5065E7B5.5080904@oracle.com>

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



From andreas.eriksson at oracle.com  Fri Sep 28 10:01:33 2012
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Fri, 28 Sep 2012 12:01:33 +0200
Subject: Review request (S): 7176220: 'Full GC' events miss date stamp
	information occasionally
Message-ID: <5065757D.9060102@oracle.com>

Hi,

Can I have some reviews for the following change please:
http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ 
<http://cr.openjdk.java.net/%7Ebrutisso/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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120928/1edcc12a/attachment.htm>

From mark.reinhold at oracle.com  Sat Sep 29 00:24:10 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 28 Sep 2012 17:24:10 -0700 (PDT)
Subject: JEP 163: Enable NUMA Mode by Default When Appropriate
Message-ID: <20120929002410.95A90C23@eggemoggin.niobe.net>

Posted: http://openjdk.java.net/jeps/163

- Mark


From ysr1729 at gmail.com  Sat Sep 29 07:32:52 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Sat, 29 Sep 2012 00:32:52 -0700
Subject: Getting the Heap virtual addresses?
In-Reply-To: <5065E7B5.5080904@oracle.com>
References: <5065E7B5.5080904@oracle.com>
Message-ID: <CABzyjynhkDf+iiTV426-Qkz6detU3ncriQkUyh98FTi0vR9j_g@mail.gmail.com>

Azeem, Doesn't look like JVMTI nor the GC/Memory Mbeans allow you to get at
the VA for the java heap. As you noted, plus +PrintHeapAtGC will also print
the info at each gc.

-- ramki

On Fri, Sep 28, 2012 at 11:08 AM, Azeem Jiva <azeem.jiva at oracle.com> 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120929/57ce4a24/attachment.htm>

From kirk at kodewerk.com  Sat Sep 29 10:02:22 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Sat, 29 Sep 2012 12:02:22 +0200
Subject: GC logging (again)
In-Reply-To: <CAHjP37EZ2sXZ5qFWbdBsbuD-JfyQWobbwDc_Gg7z9L80PCb+=Q@mail.gmail.com>
References: <CAHjP37GkqDqeN+L2X8vMWEERmfmKTixb6_fRFtCqQvV8-sb3mQ@mail.gmail.com>
	<CAHjP37HXd0AZJUSSv1K87hZGX8NdfV9qmLQ_qJmrLsGrw1qLqg@mail.gmail.com>
	<CAHjP37GBT9Y0Rt_JPAwENrYt6k7Wc+9ohgy3VUquYMfYNq1BBw@mail.gmail.com>
	<CAHjP37EQ5++nUdr60rf3s8Sz0-D7qkOPskKS1o0=WakRqFNwrQ@mail.gmail.com>
	<CAHjP37FYjjJasq_6Os3Jvu6kSrt9m0MqxcmSSBmex7Dn9+4LHw@mail.gmail.com>
	<5063DC2A.6000807@oracle.com>
	<CAHjP37EZ2sXZ5qFWbdBsbuD-JfyQWobbwDc_Gg7z9L80PCb+=Q@mail.gmail.com>
Message-ID: <53610E3F-D313-43C9-8432-BA3EAE850D76@kodewerk.com>

Hi,

I've just noticed that in the latest builds of the 1.6.0 and the 1.7.0 that there are new combinations/corruption of ParNew and CMS logs suggesting something has changed in the logging. I didn't see anything in the lists but...

I've also got this combination of records...

57.535: [GC 57.535: [ParNew
Desired survivor size 1081344 bytes, new threshold 1 (max 4)
- age   1:    2154184 bytes,    2154184 total
: 19136K->2112K(19136K), 0.0291977 secs] 101261K->97883K(126912K), 0.0292664 secs] [Times: user=0.10 sys=0.00, real=0.03 secs] 
57.584: [GC 57.584: [ParNew: 19136K->19136K(19136K), 0.0000203 secs]57.584: [CMS: 95771K->72786K(107776K), 0.2469877 secs] 114907K->72786K(126912K), [CMS Perm : 14265K->14262K(24092K)], 0.2471242 secs] [Times: user=0.24 sys=0.00, real=0.25 secs] 
57.834: [GC [1 CMS-initial-mark: 72786K(107776K)] 73371K(126912K), 0.0013167 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 

Note that the 57.584 is a new corruption that I've not seen before. I assume that the second record is a full gc.

has there been any changes with logging?

Regards,
Kirk

On 2012-09-27, at 9:41 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Thanks Jon -- that blog entry was useful.
> 
> Vitaly
> 
> On Thu, Sep 27, 2012 at 12:55 AM, Jon Masamitsu <jon.masamitsu at oracle.com> 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120929/fefdf080/attachment.htm>

From bernd-2012 at eckenfels.net  Sat Sep 29 21:03:12 2012
From: bernd-2012 at eckenfels.net (Bernd Eckenfels)
Date: Sat, 29 Sep 2012 23:03:12 +0200
Subject: Erratic(?) CMS behaviour after 5d
In-Reply-To: <5065A38F.4080202@oracle.com>
Message-ID: <20120929210312.GA97305@neskaya.eckenfels.net>

Hello,

> You're seeing concurrent mode failures (see attached graph)

The graph is cool, how do you create it. But I am not sure about the 
concurrent Mode failure theory, there is no such message in the log, the
old heap is nearly empty and no FullGC are happening.

> i'd recommend trying these flags:
> -XX:CMSInitiatingOccupancyFraction=60

Yes, currently it is much smaller by auto tuning (I guess I will use 10%
and shrink the heap. AFAIK it needs to be combined with
-XX:+UseCMSInitiatingOccupancyOnly?

> It's also possible you are running out of old gen space,
> try increasing your old gen size as well.

Do you know if it is visible in jstat -gccause if Perm is the reason? According
to jstat -heap it was only 75% filled, but I also treat it as a likely
candidate.

> > concurrent mark-sweep generation:
> >      capacity = 25769803776 (24576.0MB)
> >      used     = 1704634416 (1625.6660614013672MB)
> >      free     = 24065169360 (22950.333938598633MB)
> >      6.614852137863636% used
> > Perm Generation:
> >      capacity = 314572800 (300.0MB)
> >      used     = 238131048 (227.0994644165039MB)
> >      free     = 76441752 (72.9005355834961MB)
> >      75.69982147216797% used

Greetings
Bernd

PS: lets discuss that in -use list.