From ycraig at cysystems.com  Mon Jan  5 12:17:30 2009
From: ycraig at cysystems.com (craig yeldell)
Date: Mon, 5 Jan 2009 15:17:30 -0500
Subject: 1.6 jdk CMSPermGenSweepingEnbaled 
Message-ID: <245065D7-8408-47AD-AA9E-9A9C98A810EE@cysystems.com>

I have run into some PermGen OOM issues, and thought I remember  
reading that the following args are enabled in the 1.6 jdk.  Does  
anyone know where I can find the info on the default settings?

CMSPermGenSweepingEnabled
CMSClassUnloadingEnabled


1.6.0_10 64bit

Regards,
Craig
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


From Y.S.Ramakrishna at Sun.COM  Mon Jan  5 12:29:35 2009
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Mon, 05 Jan 2009 12:29:35 -0800
Subject: 1.6 jdk CMSPermGenSweepingEnbaled
In-Reply-To: <245065D7-8408-47AD-AA9E-9A9C98A810EE@cysystems.com>
References: <245065D7-8408-47AD-AA9E-9A9C98A810EE@cysystems.com>
Message-ID: <fa11b47a2e88.4961fd2f@sun.com>

Hi Craig -- No, they are not enabled by default (even in 6.0),
so you'll need to explicitly enable +CMSClassUnloadingEnabled
to get the perm gen to be collected by CMS (as of
6.0 CMSPermGenSweepingEnabled became a no-op with a
suitable warning issued).

If you know the name of a specific JVM option,
i think there's some way you can have jconsole give you
the value from a running JVM. Others on this list might
be able to provide details on how to get jconsole to
reveal these secrets. (One would hope jinfo might have
a flag/query/option for such as well.)

I'm cross-posting into the serviceability alias
where the latter part of this discussion likely belongs
and where you'll get more concrete information than
my musings above.

-- ramki

----- Original Message -----
From: craig yeldell <ycraig at cysystems.com>
Date: Monday, January 5, 2009 12:18 pm
Subject: 1.6 jdk CMSPermGenSweepingEnbaled
To: hotspot-gc-use at openjdk.java.net


> I have run into some PermGen OOM issues, and thought I remember  
> reading that the following args are enabled in the 1.6 jdk.  Does  
> anyone know where I can find the info on the default settings?
> 
> CMSPermGenSweepingEnabled
> CMSClassUnloadingEnabled
> 
> 
> 1.6.0_10 64bit
> 
> Regards,
> Craig
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


From jon.masamitsu at sun.com  Tue Jan  6 09:57:32 2009
From: jon.masamitsu at sun.com (jon.masamitsu at sun.com)
Date: Tue, 06 Jan 2009 17:57:32 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6689653: JMapPerm fails with
	UseConcMarkSweepIncGC and compressed oops off
Message-ID: <20090106175733.F24C7D144@hg.openjdk.java.net>

Changeset: e9be0e04635a
Author:    jmasa
Date:      2009-01-06 07:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e9be0e04635a

6689653: JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off
Summary: Added safe_object_iterate() for use by JMapPerm.
Reviewed-by: tonyp

! 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/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/services/heapDumper.cpp



From jon.masamitsu at sun.com  Sun Jan 11 19:20:08 2009
From: jon.masamitsu at sun.com (jon.masamitsu at sun.com)
Date: Mon, 12 Jan 2009 03:20:08 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6692899: CMS: many
	vm.parallel_class_loading tests fail with assert "missing
	Printezis mark"
Message-ID: <20090112032010.96117D44B@hg.openjdk.java.net>

Changeset: 0af8b0718fc9
Author:    jmasa
Date:      2009-01-11 16:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0af8b0718fc9

6692899: CMS: many vm.parallel_class_loading tests fail with assert "missing Printezis mark"
Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition.
Reviewed-by: ysr, dcubed

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/memory/space.cpp
! src/share/vm/oops/constMethodKlass.cpp
! src/share/vm/oops/constMethodKlass.hpp
! src/share/vm/oops/constMethodOop.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolKlass.hpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp



From prashant.kumar at agnity.com  Mon Jan 12 00:59:21 2009
From: prashant.kumar at agnity.com (prashant Kumar)
Date: Mon, 12 Jan 2009 14:29:21 +0530
Subject: Major GC happening before suggested CMSInitiatingOccupancyFraction
In-Reply-To: <003001c93e3b$a1c51490$1f12fea9@idc.genband.com>
References: <003001c93e3b$a1c51490$1f12fea9@idc.genband.com>
Message-ID: <001801c97494$10f89c40$3504200a@idc.genband.com>

Hi There,

 

I am using below mentioned options for my server. The issue is that I have
set CMSInitiatingOccupancyFraction=65 but major GC is happening at a lower
value of heap used (approximately 50%) though it should happen at around
65%. Due to this CPU utilization increases to a very high value. I am not
able to find out the reason of major GC.

 

P.S. Logs are attached with the mail.

 

Options:

 

-Xdebug -Xnoagent -debug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n,stdalloc=y
-Xmx2048m -Xms2048m -XX:NewSize=96m -XX:MaxNewSize=96m -XX:+UseTLAB
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=65 -XX:+DisableExplicitGC -verbose:gc
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintTenuringDistribution
-XX:PrintCMSStatistics=1 -XX:PrintFLSStatistics=1 -XX:+PrintHeapAtGC
-XX:PermSize=64m -XX:MaxPermSize=64m

 

 

This is the output of the logs:

 

Desired survivor size 32768 bytes, new threshold 0 (max 0)

: 98176K->0K(98240K), 0.1769591 secs] 1093934K->1003680K(2097088K)Statistics
for BinaryTreeDictionary:

------------------------------------

Total Free Space: 252988590

Max   Chunk Size: 252988590

Number of Blocks: 1

Av.  Block  Size: 252988590

Tree      Height: 1

Statistics for BinaryTreeDictionary:

------------------------------------

Total Free Space: 0

Max   Chunk Size: 0

Number of Blocks: 0

Tree      Height: 0

 Heap after GC invocations=447:

Heap

 par new generation   total 98240K, used 0K [0x75800000, 0x7b800000,
0x7b800000)

  eden space 98176K,   0% used [0x75800000, 0x75800000, 0x7b7e0000)

  from space 64K,   0% used [0x7b7f0000, 0x7b7f0000, 0x7b800000)

  to   space 64K,   0% used [0x7b7e0000, 0x7b7e0000, 0x7b7f0000)

 concurrent mark-sweep generation total 1998848K, used 1003680K [0x7b800000,
0xf5800000, 0xf5800000)

 concurrent-mark-sweep perm gen total 65536K, used 16879K [0xf5800000,
0xf9800000, 0xf9800000)

} , 0.1779375 secs]

After GC:

After GC:

8784.678: [GC [1 CMS-initial-mark: 1003680K(1998848K)] 1003698K(2097088K),
0.0052064 secs]

8784.684: [CMS-concurrent-mark-start]

8787.045: [CMS-concurrent-mark: 2.361/2.361 secs]

 (CMS-concurrent-mark yielded 0 times)

8787.046: [CMS-concurrent-preclean-start]

 (cardTable: 2726 cards, re-scanned 2726 cards, 1 iterations)

8788.370: [CMS-concurrent-preclean: 1.320/1.324 secs]

 (CMS-concurrent-preclean yielded 0 times)

8788.371: [GC8788.371: [Rescan (parallel) , 0.3424891 secs]8788.714: [weak
refs processing, 0.0569442 secs] [1 CMS-remark: 1003680K(1998848K)]
1055351K(2097088K), 0.4066270 secs]

8788.799: [CMS-concurrent-sweep-start]

8791.891: [GC  {Heap before GC invocations=447:

Heap

 par new generation   total 98240K, used 98176K [0x75800000, 0x7b800000,
0x7b800000)

  eden space 98176K, 100% used [0x75800000, 0x7b7e0000, 0x7b7e0000)

  from space 64K,   0% used [0x7b7f0000, 0x7b7f0000, 0x7b800000)

  to   space 64K,   0% used [0x7b7e0000, 0x7b7e0000, 0x7b7f0000)

 concurrent mark-sweep generation total 1998848K, used 742483K [0x7b800000,
0xf5800000, 0xf5800000)

 concurrent-mark-sweep perm gen total 65536K, used 16879K [0xf5800000,
0xf9800000, 0xf9800000)

Statistics for BinaryTreeDictionary:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090112/66a3c1bf/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logs.txt
Url: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090112/66a3c1bf/attachment.txt 

From Jon.Masamitsu at Sun.COM  Mon Jan 12 07:05:47 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Mon, 12 Jan 2009 07:05:47 -0800
Subject: Major GC happening before suggested CMSInitiatingOccupancyFraction
In-Reply-To: <001801c97494$10f89c40$3504200a@idc.genband.com>
References: <003001c93e3b$a1c51490$1f12fea9@idc.genband.com>
	<001801c97494$10f89c40$3504200a@idc.genband.com>
Message-ID: <496B5C4B.6020700@sun.com>

Which  version of the JDK are you using?

It does seem curious that the CMS collection are starting so
early.  CMS uses different criteria for deciding when to start
a concurrent collection.  The occupancy of the CMS generation
(the tenured generation) is only one of the criteria.
You can add the flag -XX:+UseCMSInitiatingOccupancyOnly
which tells CMS to only use the occupancy of the CMS
generation in deciding when to start.

When you say you are seeing high cpu utilization, I assume
you mean during the CMS concurrent collection?  In
the example below between

8784.678: [GC [1 CMS-initial-mark: 1003680K(1998848K)]
1003698K(2097088K), 0.0052064 secs]

and

8798.633: [CMS-concurrent-sweep: 9.686/9.834 secs]

(about a 14 second period)?



prashant Kumar wrote On 01/12/09 00:59,:

> Hi There,
>
>  
>
> I am using below mentioned options for my server. The issue is that I
> have set CMSInitiatingOccupancyFraction=65 but major GC is happening
> at a lower value of heap used (approximately 50%) though it should
> happen at around 65%. Due to this CPU utilization increases to a very
> high value. I am not able to find out the reason of major GC.
>
>  
>
> P.S. Logs are attached with the mail.
>
>  
>
> *Options:*
>
> * *
>
> -Xdebug -Xnoagent -debug
> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n,stdalloc=y
> -Xmx2048m -Xms2048m -XX:NewSize=96m -XX:MaxNewSize=96m -XX:+UseTLAB
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
> -XX:CMSInitiatingOccupancyFraction=65 -XX:+DisableExplicitGC
> -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
> -XX:+PrintTenuringDistribution -XX:PrintCMSStatistics=1
> -XX:PrintFLSStatistics=1 -XX:+PrintHeapAtGC -XX:PermSize=64m
> -XX:MaxPermSize=64m
>
>  
>
>  
>
> *This is the output of the logs:*
>
>  
>
> Desired survivor size 32768 bytes, new threshold 0 (max 0)
>
> : 98176K->0K(98240K), 0.1769591 secs]
> 1093934K->1003680K(2097088K)Statistics for BinaryTreeDictionary:
>
> ------------------------------------
>
> Total Free Space: 252988590
>
> Max   Chunk Size: 252988590
>
> Number of Blocks: 1
>
> Av.  Block  Size: 252988590
>
> Tree      Height: 1
>
> Statistics for BinaryTreeDictionary:
>
> ------------------------------------
>
> Total Free Space: 0
>
> Max   Chunk Size: 0
>
> Number of Blocks: 0
>
> Tree      Height: 0
>
>  Heap after GC invocations=447:
>
> Heap
>
>  par new generation   total 98240K, used 0K [0x75800000, 0x7b800000,
> 0x7b800000)
>
>   eden space 98176K,   0% used [0x75800000, 0x75800000, 0x7b7e0000)
>
>   from space 64K,   0% used [0x7b7f0000, 0x7b7f0000, 0x7b800000)
>
>   to   space 64K,   0% used [0x7b7e0000, 0x7b7e0000, 0x7b7f0000)
>
>  concurrent mark-sweep generation total 1998848K, used 1003680K
> [0x7b800000, 0xf5800000, 0xf5800000)
>
>  concurrent-mark-sweep perm gen total 65536K, used 16879K [0xf5800000,
> 0xf9800000, 0xf9800000)
>
> } , 0.1779375 secs]
>
> After GC:
>
> After GC:
>
> 8784.678: [GC [1 CMS-initial-mark: 1003680K(1998848K)]
> 1003698K(2097088K), 0.0052064 secs]
>
> 8784.684: [CMS-concurrent-mark-start]
>
> 8787.045: [CMS-concurrent-mark: 2.361/2.361 secs]
>
>  (CMS-concurrent-mark yielded 0 times)
>
> 8787.046: [CMS-concurrent-preclean-start]
>
>  (cardTable: 2726 cards, re-scanned 2726 cards, 1 iterations)
>
> 8788.370: [CMS-concurrent-preclean: 1.320/1.324 secs]
>
>  (CMS-concurrent-preclean yielded 0 times)
>
> 8788.371: [GC8788.371: [Rescan (parallel) , 0.3424891 secs]8788.714:
> [weak refs processing, 0.0569442 secs] [1 CMS-remark:
> 1003680K(1998848K)] 1055351K(2097088K), 0.4066270 secs]
>
> 8788.799: [CMS-concurrent-sweep-start]
>
> 8791.891: [GC  {Heap before GC invocations=447:
>
> Heap
>
>  par new generation   total 98240K, used 98176K [0x75800000,
> 0x7b800000, 0x7b800000)
>
>   eden space 98176K, 100% used [0x75800000, 0x7b7e0000, 0x7b7e0000)
>
>   from space 64K,   0% used [0x7b7f0000, 0x7b7f0000, 0x7b800000)
>
>   to   space 64K,   0% used [0x7b7e0000, 0x7b7e0000, 0x7b7f0000)
>
>  concurrent mark-sweep generation total 1998848K, used 742483K
> [0x7b800000, 0xf5800000, 0xf5800000)
>
>  concurrent-mark-sweep perm gen total 65536K, used 16879K [0xf5800000,
> 0xf9800000, 0xf9800000)
>
> Statistics for BinaryTreeDictionary:
>
>------------------------------------------------------------------------
>
>
>  
>



From john.coomes at sun.com  Wed Jan 14 21:21:54 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Thu, 15 Jan 2009 05:21:54 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 16 new changesets
Message-ID: <20090115052229.12345D82C@hg.openjdk.java.net>

Changeset: ad8c8ca4ab0f
Author:    xdono
Date:      2008-12-15 16:55 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ad8c8ca4ab0f

6785258: Update copyright year
Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008
Reviewed-by: katleman, ohair, tbell

! src/cpu/x86/vm/vm_version_x86_32.hpp
! src/cpu/x86/vm/vm_version_x86_64.hpp
! src/os/linux/launcher/java.c
! src/os/linux/launcher/java.h
! src/os/linux/launcher/java_md.c
! src/os/linux/vm/globals_linux.hpp
! src/os/solaris/launcher/java.c
! src/os/solaris/launcher/java.h
! src/os/solaris/launcher/java_md.c
! src/os/solaris/vm/globals_solaris.hpp
! src/os/windows/vm/globals_windows.hpp
! src/os/windows/vm/os_windows.hpp
! src/os_cpu/linux_x86/vm/linux_x86_32.ad
! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java
! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java
! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java
! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java
! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java
! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java
! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/filebuff.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/ptrQueue.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
! src/share/vm/interpreter/bytecodeStream.cpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/memory/referencePolicy.cpp
! src/share/vm/memory/referencePolicy.hpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/phase.cpp
! src/share/vm/opto/phase.hpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jniCheck.hpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/prims/jvmtiTrace.cpp
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/javaCalls.hpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/perfMemory.hpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/services/threadService.hpp
! src/share/vm/utilities/array.hpp
! src/share/vm/utilities/constantTag.hpp
! src/share/vm/utilities/growableArray.hpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/taskqueue.cpp

Changeset: 5e5faba1ac11
Author:    xdono
Date:      2008-12-18 21:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5e5faba1ac11

Added tag jdk7-b42 for changeset ad8c8ca4ab0f

! .hgtags

Changeset: 569b3b226089
Author:    trims
Date:      2008-12-20 09:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/569b3b226089

Merge

! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/adlparse.hpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp

Changeset: 26bc4770e671
Author:    trims
Date:      2008-12-20 09:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/26bc4770e671

Merge

! src/share/vm/runtime/javaCalls.cpp

Changeset: fc6a5ae3fef5
Author:    trims
Date:      2008-12-20 09:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fc6a5ae3fef5

6787832: Bump Hotspot build number to 08
Summary: Update the HS14 build number to 08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3cd5c5b027b1
Author:    trims
Date:      2008-12-23 19:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3cd5c5b027b1

6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM
Summary: fork Hotspot 15 - redo verisoning numbers
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 6d8fc951eb25
Author:    kvn
Date:      2008-12-22 15:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6d8fc951eb25

6778657: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined C++ behaviour
Summary: Replaces SharedRuntime::f2i et al with versions that should work
Reviewed-by: never
Contributed-by: gbenson at redhat.com

! src/share/vm/runtime/sharedRuntime.cpp
+ test/compiler/6778657/Test.java

Changeset: 9656bebe85a7
Author:    kvn
Date:      2008-12-22 16:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9656bebe85a7

6778662: fixes 64-bits libraries directory search paths on linux
Summary: Fixes 64-bits libraries directory search paths.
Reviewed-by: never
Contributed-by: langel at redhat.com

! src/os/linux/vm/os_linux.cpp

Changeset: 1a767c61ad01
Author:    never
Date:      2009-01-06 16:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1a767c61ad01

Merge


Changeset: dabd8d202164
Author:    coleenp
Date:      2008-12-23 06:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/dabd8d202164

4997835: RFE: crash dump will only be created when running w/ -XX:+ShowMessageBoxOnError
Summary: Using UseOSErrorReporting will provide both an hs_err file and a crash dump or debug launch and works better.
Reviewed-by: xlu, acorn, poonam

! src/share/vm/utilities/vmError.cpp

Changeset: db4caa99ef11
Author:    xlu
Date:      2008-12-24 13:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/db4caa99ef11

6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t
Summary: Avoid casting between int32_t and intptr_t specifically for MasmAssembler::movptr in 32 bit platforms.
Reviewed-by: jrose, kvn

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/runtime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp

Changeset: 2328d1d3f8cf
Author:    xlu
Date:      2008-12-24 19:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2328d1d3f8cf

6781583: Hotspot build fails on linux 64 bit platform with gcc 4.3.2
Summary: Fixed the wrong cast between types since more restrictions are imposed by gcc 4.3.2
Reviewed-by: jcoomes, acorn, phh, never

! src/cpu/sparc/vm/jni_sparc.h
! src/cpu/x86/vm/jni_x86.h
! src/os/linux/vm/os_linux.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/libadt/port.hpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/memprofiler.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/vmError.hpp

Changeset: c81d2ef51ca3
Author:    acorn
Date:      2009-01-05 13:44 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c81d2ef51ca3

4670071: loadClassInternal is too restrictive.
Summary: VM support for deadlock fix. Library fix in 4735126. See API proposal.
Reviewed-by: dholmes, blacklion

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/globals.hpp

Changeset: a0401dc51d0b
Author:    acorn
Date:      2009-01-08 16:27 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a0401dc51d0b

6791656: nsk defclass0 asserts handles.hpp
Reviewed-by: phh, xlu

! src/share/vm/classfile/systemDictionary.cpp

Changeset: fc7ab6287598
Author:    coleenp
Date:      2009-01-09 14:39 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fc7ab6287598

Merge

! src/os/linux/vm/os_linux.cpp
! src/share/vm/oops/constantPoolOop.cpp

Changeset: 65de26b5ea82
Author:    jcoomes
Date:      2009-01-14 14:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/65de26b5ea82

Merge

! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp



From tewk at cs.utah.edu  Wed Jan 14 20:56:04 2009
From: tewk at cs.utah.edu (Kevin Tew)
Date: Wed, 14 Jan 2009 21:56:04 -0700
Subject: Iterating to a safe point
Message-ID: <496EC1E4.6070801@cs.utah.edu>

I remember reading in a paper that said that the Java VM used safe 
points so that when a stop the world condition needed to occur, all 
threads could be stepped forward to a safe point within a fixed amount 
of instructions.

Is that the case still?

Any pointer where I could look in the openjdk code base to find out more?

Kevin Tew


From Jon.Masamitsu at Sun.COM  Thu Jan 15 07:11:48 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Thu, 15 Jan 2009 07:11:48 -0800
Subject: Iterating to a safe point
In-Reply-To: <496EC1E4.6070801@cs.utah.edu>
References: <496EC1E4.6070801@cs.utah.edu>
Message-ID: <496F5234.9030309@Sun.COM>

Look in

share/vm/runtime/safepoint.cpp

starting with SafepointSynchronize::begin().  There's
a nice comment there that says

// Roll all threads forward to a safepoint and suspend them all

Best to look at the code to see exactly what that means
with regard to your question about "fixed amount of instructions".


On 01/14/09 20:56, Kevin Tew wrote:
> I remember reading in a paper that said that the Java VM used safe 
> points so that when a stop the world condition needed to occur, all 
> threads could be stepped forward to a safe point within a fixed amount 
> of instructions.
> 
> Is that the case still?
> 
> Any pointer where I could look in the openjdk code base to find out more?
> 
> Kevin Tew


From Y.S.Ramakrishna at Sun.COM  Thu Jan 15 09:44:26 2009
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Thu, 15 Jan 2009 09:44:26 -0800
Subject: Extremely long parallel rescan
In-Reply-To: <bae1306e0901150927m6465f5ffs878e28c5126a9dd2@mail.gmail.com>
References: <bae1306e0901150927m6465f5ffs878e28c5126a9dd2@mail.gmail.com>
Message-ID: <fccca5176304.496f057a@sun.com>


Can you run with -XX:PrintCMSStatistics=2 and send me the output?

I suspect a performance badness related to code for
manipulating overflow lists that we recently discovered
and which is being fixed under:

6786503 Overflow list performance can be improved
6787254 Work queue capacity can be increased substantially on some platforms

We can get you a fix verification binary
through your support channels once it is established
that work queue overflow is the issue here (and it
sounds very much like it is).

-- ramki

----- Original Message -----
From: Hi Guava <higuava at gmail.com>
Date: Thursday, January 15, 2009 9:27 am
Subject: Extremely long parallel rescan
To: hotspot-gc-use at openjdk.java.net


> We have been having problem with CMS collector for a long time. The rescan
> phase of CMS takes very very long time (20 minutes to several hours). 
> We
> tried searching on Internet, asking in Sun's developer forum, etc. No 
> one
> seems know what's going on.
> 
> The typical hardware has 4 to 8 cpu/cores with 20 GB to 64GB of 
> memory. It
> happens on both Windows and Linux version of 64-bit JVMs.
> The GC parameters that we usually use are: -XX:+UseConcMarkSweepGC
> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
> 
> The following is an example of the problem.
> Hardware: 2 dual-core CPUs (4 core in total) with 28 GB memory.
> JVM: Java HotSpot(TM) 64-Bit Server VM Version 1.5.0_17-b04 from Sun
> Microsystems Inc. on Windows XP Version 5.2 on amd64
> Settings: -Xms20000m -Xmx20000m -XX:NewSize=500m
> -XX:+CMSPermGenSweepingEnabled -XX:+DisableExplicitGC
> -XX:CMSMarkStackSize=2M -XX:CMSMarkStackSizeMax=8M -XX:+UseConcMarkSweepGC
> -XX:CMSInitiatingOccupancyFraction=30 -XX:+PrintGCDetails
> -XX:+PrintGCTimeStamps
> Note that we set many other GC parameters in this particular example.
> Usually we only use -XX:+UseConcMarkSweepGC.
> 
> 910.659: [GC [1 CMS-initial-mark: 6465020K(19968000K)] 6679872K(20479552K),
> 0.3206026 secs]
> 910.980: [CMS-concurrent-mark-start]
> 919.131: [GC 919.131: [ParNew: 511104K->0K(511552K), 0.6801310 secs]
> 6976124K->6657978K(20479552K), 0.6802201 secs]
> 933.413: [CMS-concurrent-mark: 21.739/22.433 secs]
> 933.413: [CMS-concurrent-preclean-start]
> 934.813: [CMS-concurrent-preclean: 1.348/1.400 secs]
> 934.813: [CMS-concurrent-abortable-preclean-start]
>  CMS: abort preclean due to time 935.929:
> [CMS-concurrent-abortable-preclean: 0.662/1.116 secs]
> 935.933: [GC[YG occupancy: 443765 K (511552 K)]935.933: [Rescan (parallel)
> , 3533.9840087 secs]4469.917: [weak refs processing, 0.0620489 secs] [1
> CMS-remark: 6657978K(19968000K)] 7101744K(20479552K), 3534.0462074 secs]
> 4469.980: [CMS-concurrent-sweep-start]
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


From john.coomes at sun.com  Fri Jan 16 00:52:47 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 08:52:47 +0000
Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b43 for changeset 848e684279d2
Message-ID: <20090116085247.878C7DA6F@hg.openjdk.java.net>

Changeset: a395e3aac474
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/a395e3aac474

Added tag jdk7-b43 for changeset 848e684279d2

! .hgtags



From john.coomes at sun.com  Fri Jan 16 00:54:55 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 08:54:55 +0000
Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b43 for changeset
	9cd740d48a48
Message-ID: <20090116085456.ED221DA74@hg.openjdk.java.net>

Changeset: 9803dac72540
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/9803dac72540

Added tag jdk7-b43 for changeset 9cd740d48a48

! .hgtags



From john.coomes at sun.com  Fri Jan 16 00:59:14 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 08:59:14 +0000
Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b43 for changeset
	96fe28d4a913
Message-ID: <20090116085916.8F86EDA79@hg.openjdk.java.net>

Changeset: b203df0741af
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/b203df0741af

Added tag jdk7-b43 for changeset 96fe28d4a913

! .hgtags



From john.coomes at sun.com  Fri Jan 16 01:01:27 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:01:27 +0000
Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b43 for changeset
	1ad2f51564db
Message-ID: <20090116090130.33E78DA7E@hg.openjdk.java.net>

Changeset: 344485a03674
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/344485a03674

Added tag jdk7-b43 for changeset 1ad2f51564db

! .hgtags



From john.coomes at sun.com  Fri Jan 16 01:06:23 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:06:23 +0000
Subject: hg: jdk7/hotspot-gc/jdk: 53 new changesets
Message-ID: <20090116091651.3147FDA83@hg.openjdk.java.net>

Changeset: 4e0e690373fc
Author:    wetmore
Date:      2008-12-02 14:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4e0e690373fc

6778613: Update javax.crypto.Cipher.getMaxAllowedKeyLength to point to proper Appendix after doc reorg
Reviewed-by: mullan

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

Changeset: a99a2d2f3249
Author:    dfuchs
Date:      2008-12-04 17:58 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a99a2d2f3249

6319823: new mbean register/unregister notification for groups of mbeans
6779698: Merge error caused duplicate example code in MBeanServerNotification
Reviewed-by: emcmanus

! src/share/classes/javax/management/MBeanServerNotification.java

Changeset: 87170fc5a587
Author:    mchung
Date:      2008-12-05 10:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/87170fc5a587

6764062: Revise usage of java.io.*.close
Summary: Handle closing multiple open I/O streams in case close() throws IOException
Reviewed-by: ksrini

! src/share/classes/com/sun/servicetag/Installer.java
! src/share/classes/com/sun/servicetag/SunConnection.java
! src/share/classes/com/sun/servicetag/Util.java
! src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java

Changeset: baa10242c544
Author:    mchung
Date:      2008-12-05 10:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/baa10242c544

6750389: The cpuManufactorer does not correctly recognized for Solaris 10
Summary: Fix the correct SMBIOS type (4) to obtain CPU manufacturer
Reviewed-by: ksrini

! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java

Changeset: ea43ec07a878
Author:    tbell
Date:      2008-12-05 21:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ea43ec07a878

Merge


Changeset: b4bf1806ee66
Author:    emcmanus
Date:      2008-12-09 12:01 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b4bf1806ee66

6774918: @NotificationInfo is ineffective on MBeans that cannot send notifications
Reviewed-by: jfdenise

! src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java
! src/share/classes/javax/management/NotificationInfo.java
! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java

Changeset: 95f828533592
Author:    jfdenise
Date:      2008-12-09 14:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/95f828533592

6501362: DescriptorSupport(String) could recognize "name=value" as well as XML format
Reviewed-by: emcmanus

! src/share/classes/javax/management/modelmbean/DescriptorSupport.java
+ test/javax/management/descriptor/DescriptorConstructorTest.java

Changeset: 8d7117d71fc7
Author:    jfdenise
Date:      2008-12-09 15:36 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8d7117d71fc7

6250014: MBeanOperationInfo Descriptor field for exceptions
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java
! src/share/classes/javax/management/Descriptor.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
+ test/javax/management/Introspector/ExceptionsDescriptorTest.java

Changeset: f8c2f3b5c0ff
Author:    jfdenise
Date:      2008-12-09 15:57 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f8c2f3b5c0ff

6675526: Define an Annotation to name registered MBeans
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java
! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/javax/management/Descriptor.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/MBeanServerConnection.java
+ src/share/classes/javax/management/ObjectNameTemplate.java
+ test/javax/management/Introspector/ObjectNameTemplateTest.java

Changeset: ab4d12886aaf
Author:    jfdenise
Date:      2008-12-09 16:14 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ab4d12886aaf

6450834: RFE: allow StandardMBean to call MBeanRegistration methods on its wrapped resource
6373143: MonitorNotification should have a public constructor
Reviewed-by: emcmanus

! src/share/classes/javax/management/StandardMBean.java
! src/share/classes/javax/management/monitor/MonitorNotification.java
+ test/javax/management/monitor/InstantiateMonitorNotificationTest.java
+ test/javax/management/standardmbean/RegistrationTest.java

Changeset: 3d822c99e3ab
Author:    jfdenise
Date:      2008-12-09 16:26 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3d822c99e3ab

6287328: Add methods to StandardMBean to retrieve a method based on MBean{Attribute|Operation}Info
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java
! src/share/classes/javax/management/StandardMBean.java
+ test/javax/management/standardmbean/FindMethodTest.java

Changeset: 6eec8be80bfe
Author:    sjiang
Date:      2008-12-09 17:41 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6eec8be80bfe

6405891: MLet: could be improved to load a native lib
Reviewed-by: emcmanus

! src/share/classes/javax/management/loading/MLet.java

Changeset: 30239cf868b0
Author:    sjiang
Date:      2008-12-09 17:41 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/30239cf868b0

Merge


Changeset: 0b1c7f982cc0
Author:    emcmanus
Date:      2008-12-09 18:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0b1c7f982cc0

6780803: Wrong parameter name in description of EventClient::addListeners()
6470295: Misleading exception message says context classloader when it isn't
6714954: Description of MBeanPermission checking in MBeanServer javadoc is inaccurate
6732037: Event Service spec needs more detail about Executor use
6740900: Specify that listeners invoked via SendNotification should not block
6778436: Typo in @NotificationInfos spec
Reviewed-by: dfuchs

! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java
! src/share/classes/javax/management/MBeanRegistration.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/event/EventClient.java
! src/share/classes/javax/management/event/FetchingEventRelay.java

Changeset: 23738109351f
Author:    sjiang
Date:      2008-12-09 18:42 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/23738109351f

6760712: Provide a connector server option that causes it not to prevent the VM from exiting
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java
! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java
+ test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java

Changeset: 0dc9fc01e5d6
Author:    sjiang
Date:      2008-12-09 18:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0dc9fc01e5d6

Merge


Changeset: 4951fee90769
Author:    sjiang
Date:      2008-12-09 19:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4951fee90769

6332907: Add ability for connector server to close individual connections
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java
! src/share/classes/javax/management/remote/JMXConnectorServer.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java
+ test/javax/management/remote/mandatory/connectorServer/CloseConnectionTest.java

Changeset: 61e73bc43e72
Author:    dfuchs
Date:      2008-12-09 20:20 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/61e73bc43e72

6768935: Clarify the behaviour of ObjectName pattern matching with regards to namespaces
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java
! src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java
! src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java
! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java
! src/share/classes/com/sun/jmx/mbeanserver/Util.java
! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java
! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java
! src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java
! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java
! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java
! src/share/classes/javax/management/MBeanServer.java
! src/share/classes/javax/management/MBeanServerConnection.java
! src/share/classes/javax/management/ObjectName.java
! src/share/classes/javax/management/namespace/JMXDomain.java
! src/share/classes/javax/management/namespace/JMXNamespacePermission.java
! src/share/classes/javax/management/namespace/JMXNamespaces.java
! src/share/classes/javax/management/namespace/package-info.java
! test/javax/management/namespace/LeadingSeparatorsTest.java
! test/javax/management/namespace/NullDomainObjectNameTest.java
! test/javax/management/namespace/NullObjectNameTest.java
! test/javax/management/namespace/QueryNamesTest.java

Changeset: 7aa035fdd97d
Author:    sjiang
Date:      2008-12-09 20:50 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7aa035fdd97d

6336980: NotificationBroadcasterSupport: to tell whether there are listeners and to do clear
Reviewed-by: emcmanus

! src/share/classes/javax/management/NotificationBroadcasterSupport.java
+ test/javax/management/notification/SupportClearTest.java

Changeset: 3f226f477d56
Author:    sjiang
Date:      2008-12-09 20:51 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3f226f477d56

Merge


Changeset: c8db1ddbdba4
Author:    emcmanus
Date:      2008-12-10 11:59 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c8db1ddbdba4

6456269: Add a GenericMBeanException so clients don't have to have server's exception classes present
Reviewed-by: jfdenise, dfuchs

! src/share/classes/javax/management/Descriptor.java
+ src/share/classes/javax/management/GenericMBeanException.java
! src/share/classes/javax/management/MBeanException.java
+ test/javax/management/interop/MBeanExceptionInteropTest.java
+ test/javax/management/openmbean/GenericMBeanExceptionTest.java

Changeset: b89ba9a6d9a6
Author:    sherman
Date:      2008-12-10 14:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b89ba9a6d9a6

6642323: Speeding up Single Byte Decoders
6642328: Speeding up Single Byte Encoders
Summary: re-implementation of mapping based sbcs charts
Reviewed-by: alanb

! make/java/nio/FILES_java.gmk
! make/java/nio/Makefile
! make/sun/nio/FILES_java.gmk
! make/sun/nio/Makefile
+ make/tools/CharsetMapping/IBM037.c2b
+ make/tools/CharsetMapping/IBM037.map
+ make/tools/CharsetMapping/IBM037.nr
+ make/tools/CharsetMapping/IBM1006.map
+ make/tools/CharsetMapping/IBM1025.c2b
+ make/tools/CharsetMapping/IBM1025.map
+ make/tools/CharsetMapping/IBM1025.nr
+ make/tools/CharsetMapping/IBM1026.c2b
+ make/tools/CharsetMapping/IBM1026.map
+ make/tools/CharsetMapping/IBM1026.nr
+ make/tools/CharsetMapping/IBM1046.map
+ make/tools/CharsetMapping/IBM1047.map
+ make/tools/CharsetMapping/IBM1097.map
+ make/tools/CharsetMapping/IBM1098.map
+ make/tools/CharsetMapping/IBM1112.c2b
+ make/tools/CharsetMapping/IBM1112.map
+ make/tools/CharsetMapping/IBM1112.nr
+ make/tools/CharsetMapping/IBM1122.c2b
+ make/tools/CharsetMapping/IBM1122.map
+ make/tools/CharsetMapping/IBM1122.nr
+ make/tools/CharsetMapping/IBM1123.c2b
+ make/tools/CharsetMapping/IBM1123.map
+ make/tools/CharsetMapping/IBM1123.nr
+ make/tools/CharsetMapping/IBM1124.map
+ make/tools/CharsetMapping/IBM1140.c2b
+ make/tools/CharsetMapping/IBM1140.map
+ make/tools/CharsetMapping/IBM1141.c2b
+ make/tools/CharsetMapping/IBM1141.map
+ make/tools/CharsetMapping/IBM1142.c2b
+ make/tools/CharsetMapping/IBM1142.map
+ make/tools/CharsetMapping/IBM1143.c2b
+ make/tools/CharsetMapping/IBM1143.map
+ make/tools/CharsetMapping/IBM1144.c2b
+ make/tools/CharsetMapping/IBM1144.map
+ make/tools/CharsetMapping/IBM1145.c2b
+ make/tools/CharsetMapping/IBM1145.map
+ make/tools/CharsetMapping/IBM1146.c2b
+ make/tools/CharsetMapping/IBM1146.map
+ make/tools/CharsetMapping/IBM1147.c2b
+ make/tools/CharsetMapping/IBM1147.map
+ make/tools/CharsetMapping/IBM1148.c2b
+ make/tools/CharsetMapping/IBM1148.map
+ make/tools/CharsetMapping/IBM1149.c2b
+ make/tools/CharsetMapping/IBM1149.map
+ make/tools/CharsetMapping/IBM273.c2b
+ make/tools/CharsetMapping/IBM273.map
+ make/tools/CharsetMapping/IBM273.nr
+ make/tools/CharsetMapping/IBM277.c2b
+ make/tools/CharsetMapping/IBM277.map
+ make/tools/CharsetMapping/IBM277.nr
+ make/tools/CharsetMapping/IBM278.c2b
+ make/tools/CharsetMapping/IBM278.map
+ make/tools/CharsetMapping/IBM278.nr
+ make/tools/CharsetMapping/IBM280.c2b
+ make/tools/CharsetMapping/IBM280.map
+ make/tools/CharsetMapping/IBM280.nr
+ make/tools/CharsetMapping/IBM284.c2b
+ make/tools/CharsetMapping/IBM284.map
+ make/tools/CharsetMapping/IBM284.nr
+ make/tools/CharsetMapping/IBM285.c2b
+ make/tools/CharsetMapping/IBM285.map
+ make/tools/CharsetMapping/IBM285.nr
+ make/tools/CharsetMapping/IBM297.c2b
+ make/tools/CharsetMapping/IBM297.map
+ make/tools/CharsetMapping/IBM297.nr
+ make/tools/CharsetMapping/IBM420.c2b
+ make/tools/CharsetMapping/IBM420.map
+ make/tools/CharsetMapping/IBM420.nr
+ make/tools/CharsetMapping/IBM424.c2b
+ make/tools/CharsetMapping/IBM424.map
+ make/tools/CharsetMapping/IBM424.nr
+ make/tools/CharsetMapping/IBM437.map
+ make/tools/CharsetMapping/IBM500.c2b
+ make/tools/CharsetMapping/IBM500.map
+ make/tools/CharsetMapping/IBM500.nr
+ make/tools/CharsetMapping/IBM737.map
+ make/tools/CharsetMapping/IBM775.map
+ make/tools/CharsetMapping/IBM838.c2b
+ make/tools/CharsetMapping/IBM838.map
+ make/tools/CharsetMapping/IBM838.nr
+ make/tools/CharsetMapping/IBM850.map
+ make/tools/CharsetMapping/IBM852.map
+ make/tools/CharsetMapping/IBM855.map
+ make/tools/CharsetMapping/IBM856.map
+ make/tools/CharsetMapping/IBM857.map
+ make/tools/CharsetMapping/IBM858.map
+ make/tools/CharsetMapping/IBM860.map
+ make/tools/CharsetMapping/IBM861.map
+ make/tools/CharsetMapping/IBM862.map
+ make/tools/CharsetMapping/IBM863.map
+ make/tools/CharsetMapping/IBM864.map
+ make/tools/CharsetMapping/IBM865.map
+ make/tools/CharsetMapping/IBM866.map
+ make/tools/CharsetMapping/IBM868.map
+ make/tools/CharsetMapping/IBM869.map
+ make/tools/CharsetMapping/IBM870.c2b
+ make/tools/CharsetMapping/IBM870.map
+ make/tools/CharsetMapping/IBM870.nr
+ make/tools/CharsetMapping/IBM871.c2b
+ make/tools/CharsetMapping/IBM871.map
+ make/tools/CharsetMapping/IBM871.nr
+ make/tools/CharsetMapping/IBM874.map
+ make/tools/CharsetMapping/IBM874.nr
+ make/tools/CharsetMapping/IBM875.c2b
+ make/tools/CharsetMapping/IBM875.map
+ make/tools/CharsetMapping/IBM875.nr
+ make/tools/CharsetMapping/IBM918.c2b
+ make/tools/CharsetMapping/IBM918.map
+ make/tools/CharsetMapping/IBM918.nr
+ make/tools/CharsetMapping/IBM921.map
+ make/tools/CharsetMapping/IBM922.map
+ make/tools/CharsetMapping/ISO_8859_11.map
+ make/tools/CharsetMapping/ISO_8859_13.map
+ make/tools/CharsetMapping/ISO_8859_15.map
+ make/tools/CharsetMapping/ISO_8859_2.map
+ make/tools/CharsetMapping/ISO_8859_3.map
+ make/tools/CharsetMapping/ISO_8859_4.map
+ make/tools/CharsetMapping/ISO_8859_5.map
+ make/tools/CharsetMapping/ISO_8859_6.map
+ make/tools/CharsetMapping/ISO_8859_7.map
+ make/tools/CharsetMapping/ISO_8859_8.map
+ make/tools/CharsetMapping/ISO_8859_9.map
+ make/tools/CharsetMapping/JIS_X_0201.map
+ make/tools/CharsetMapping/KOI8_R.map
+ make/tools/CharsetMapping/KOI8_U.map
+ make/tools/CharsetMapping/MS1250.map
+ make/tools/CharsetMapping/MS1251.map
+ make/tools/CharsetMapping/MS1252.map
+ make/tools/CharsetMapping/MS1253.map
+ make/tools/CharsetMapping/MS1254.map
+ make/tools/CharsetMapping/MS1255.map
+ make/tools/CharsetMapping/MS1256.map
+ make/tools/CharsetMapping/MS1257.map
+ make/tools/CharsetMapping/MS1258.map
+ make/tools/CharsetMapping/MS874.map
+ make/tools/CharsetMapping/MacArabic.map
+ make/tools/CharsetMapping/MacCentralEurope.map
+ make/tools/CharsetMapping/MacCroatian.map
+ make/tools/CharsetMapping/MacCyrillic.map
+ make/tools/CharsetMapping/MacDingbat.map
+ make/tools/CharsetMapping/MacGreek.map
+ make/tools/CharsetMapping/MacHebrew.map
+ make/tools/CharsetMapping/MacIceland.map
+ make/tools/CharsetMapping/MacRoman.map
+ make/tools/CharsetMapping/MacRomania.map
+ make/tools/CharsetMapping/MacSymbol.map
+ make/tools/CharsetMapping/MacThai.map
+ make/tools/CharsetMapping/MacTurkish.map
+ make/tools/CharsetMapping/MacUkraine.map
+ make/tools/CharsetMapping/SingleByte-X.java
+ make/tools/CharsetMapping/TIS_620.map
+ make/tools/CharsetMapping/extsbcs
+ make/tools/CharsetMapping/sbcs
! make/tools/src/build/tools/charsetmapping/GenerateMapping.java
+ make/tools/src/build/tools/charsetmapping/GenerateSBCS.java
! src/share/classes/sun/io/ByteToCharCp850.java
! src/share/classes/sun/io/CharToByteJIS0201.java
! src/share/classes/sun/io/CharToByteSingleByte.java
- src/share/classes/sun/nio/cs/IBM437.java
- src/share/classes/sun/nio/cs/IBM737.java
- src/share/classes/sun/nio/cs/IBM775.java
- src/share/classes/sun/nio/cs/IBM850.java
- src/share/classes/sun/nio/cs/IBM852.java
- src/share/classes/sun/nio/cs/IBM855.java
- src/share/classes/sun/nio/cs/IBM857.java
- src/share/classes/sun/nio/cs/IBM858.java
- src/share/classes/sun/nio/cs/IBM862.java
- src/share/classes/sun/nio/cs/IBM866.java
- src/share/classes/sun/nio/cs/IBM874.java
- src/share/classes/sun/nio/cs/ISO_8859_13.java
- src/share/classes/sun/nio/cs/ISO_8859_15.java
- src/share/classes/sun/nio/cs/ISO_8859_2.java
- src/share/classes/sun/nio/cs/ISO_8859_4.java
- src/share/classes/sun/nio/cs/ISO_8859_5.java
- src/share/classes/sun/nio/cs/ISO_8859_7.java
- src/share/classes/sun/nio/cs/ISO_8859_9.java
- src/share/classes/sun/nio/cs/KOI8_R.java
- src/share/classes/sun/nio/cs/KOI8_U.java
- src/share/classes/sun/nio/cs/MS1250.java
- src/share/classes/sun/nio/cs/MS1251.java
- src/share/classes/sun/nio/cs/MS1252.java
- src/share/classes/sun/nio/cs/MS1253.java
- src/share/classes/sun/nio/cs/MS1254.java
- src/share/classes/sun/nio/cs/MS1257.java
+ src/share/classes/sun/nio/cs/SingleByte.java
- src/share/classes/sun/nio/cs/ext/IBM037.java
- src/share/classes/sun/nio/cs/ext/IBM1006.java
- src/share/classes/sun/nio/cs/ext/IBM1025.java
- src/share/classes/sun/nio/cs/ext/IBM1026.java
- src/share/classes/sun/nio/cs/ext/IBM1046.java
- src/share/classes/sun/nio/cs/ext/IBM1047.java
- src/share/classes/sun/nio/cs/ext/IBM1097.java
- src/share/classes/sun/nio/cs/ext/IBM1098.java
- src/share/classes/sun/nio/cs/ext/IBM1112.java
- src/share/classes/sun/nio/cs/ext/IBM1122.java
- src/share/classes/sun/nio/cs/ext/IBM1123.java
- src/share/classes/sun/nio/cs/ext/IBM1124.java
- src/share/classes/sun/nio/cs/ext/IBM1140.java
- src/share/classes/sun/nio/cs/ext/IBM1141.java
- src/share/classes/sun/nio/cs/ext/IBM1142.java
- src/share/classes/sun/nio/cs/ext/IBM1143.java
- src/share/classes/sun/nio/cs/ext/IBM1144.java
- src/share/classes/sun/nio/cs/ext/IBM1145.java
- src/share/classes/sun/nio/cs/ext/IBM1146.java
- src/share/classes/sun/nio/cs/ext/IBM1147.java
- src/share/classes/sun/nio/cs/ext/IBM1148.java
- src/share/classes/sun/nio/cs/ext/IBM1149.java
- src/share/classes/sun/nio/cs/ext/IBM273.java
- src/share/classes/sun/nio/cs/ext/IBM277.java
- src/share/classes/sun/nio/cs/ext/IBM278.java
- src/share/classes/sun/nio/cs/ext/IBM280.java
- src/share/classes/sun/nio/cs/ext/IBM284.java
- src/share/classes/sun/nio/cs/ext/IBM285.java
- src/share/classes/sun/nio/cs/ext/IBM297.java
- src/share/classes/sun/nio/cs/ext/IBM420.java
- src/share/classes/sun/nio/cs/ext/IBM424.java
- src/share/classes/sun/nio/cs/ext/IBM500.java
- src/share/classes/sun/nio/cs/ext/IBM838.java
- src/share/classes/sun/nio/cs/ext/IBM856.java
- src/share/classes/sun/nio/cs/ext/IBM860.java
- src/share/classes/sun/nio/cs/ext/IBM861.java
- src/share/classes/sun/nio/cs/ext/IBM863.java
- src/share/classes/sun/nio/cs/ext/IBM864.java
- src/share/classes/sun/nio/cs/ext/IBM865.java
- src/share/classes/sun/nio/cs/ext/IBM868.java
- src/share/classes/sun/nio/cs/ext/IBM869.java
- src/share/classes/sun/nio/cs/ext/IBM870.java
- src/share/classes/sun/nio/cs/ext/IBM871.java
- src/share/classes/sun/nio/cs/ext/IBM875.java
- src/share/classes/sun/nio/cs/ext/IBM918.java
- src/share/classes/sun/nio/cs/ext/IBM921.java
- src/share/classes/sun/nio/cs/ext/IBM922.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_11.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_3.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_6.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_8.java
- src/share/classes/sun/nio/cs/ext/MS1255.java
- src/share/classes/sun/nio/cs/ext/MS1256.java
- src/share/classes/sun/nio/cs/ext/MS1258.java
- src/share/classes/sun/nio/cs/ext/MS874.java
- src/share/classes/sun/nio/cs/ext/MacArabic.java
- src/share/classes/sun/nio/cs/ext/MacCentralEurope.java
- src/share/classes/sun/nio/cs/ext/MacCroatian.java
- src/share/classes/sun/nio/cs/ext/MacCyrillic.java
- src/share/classes/sun/nio/cs/ext/MacDingbat.java
- src/share/classes/sun/nio/cs/ext/MacGreek.java
- src/share/classes/sun/nio/cs/ext/MacHebrew.java
- src/share/classes/sun/nio/cs/ext/MacIceland.java
- src/share/classes/sun/nio/cs/ext/MacRoman.java
- src/share/classes/sun/nio/cs/ext/MacRomania.java
- src/share/classes/sun/nio/cs/ext/MacSymbol.java
- src/share/classes/sun/nio/cs/ext/MacThai.java
- src/share/classes/sun/nio/cs/ext/MacTurkish.java
- src/share/classes/sun/nio/cs/ext/MacUkraine.java
- src/share/classes/sun/nio/cs/ext/TIS_620.java

Changeset: 18ab3173fcec
Author:    tbell
Date:      2008-12-19 10:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/18ab3173fcec

Merge

! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java

Changeset: 94bcd3503668
Author:    bae
Date:      2008-07-25 14:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/94bcd3503668

6687968: PNGImageReader leaks native memory through an Inflater.
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java

Changeset: e62bc7b05b8a
Author:    igor
Date:      2008-08-04 18:50 +0400
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e62bc7b05b8a

4356282: RFE: T2K should be used to rasterize CID/CFF fonts
Reviewed-by: bae, prr

! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/windows/native/sun/font/fontpath.c

Changeset: a56641c1f54e
Author:    tdv
Date:      2008-08-04 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a56641c1f54e

6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque destination
Reviewed-by: campbell

! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
+ test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java

Changeset: b2413144d908
Author:    tdv
Date:      2008-08-04 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b2413144d908

6717988: D3D: rendering problems with JConsole on [Nvidia FX 5200]
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 06a02adcba4e
Author:    tdv
Date:      2008-08-05 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/06a02adcba4e

6733718: test /java/awt/FullScreen/UninitializedDisplayModeChangeTest/ fails
Reviewed-by: igor

+ test/java/awt/FullScreen/UninitializedDisplayModeChangeTest/DisplayModeChanger.java

Changeset: 15be3e891e97
Author:    jgodinez
Date:      2008-08-07 11:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/15be3e891e97

6731937: javax/print/CheckDupFlavor.java fails
Reviewed-by: campbell, tdv

! src/solaris/classes/sun/print/IPPPrintService.java
+ test/javax/print/CheckDupFlavor.java

Changeset: 3c4561f955f3
Author:    lana
Date:      2008-08-07 22:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3c4561f955f3

Merge

- make/tools/winver/Makefile
- make/tools/winver/bin/winver.exe
- make/tools/winver/src/StdAfx.cpp
- make/tools/winver/src/StdAfx.h
- make/tools/winver/src/winver.cpp
- src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java
- src/share/classes/javax/management/ToQueryString.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/solaris/classes/sun/print/IPPPrintService.java
- test/javax/management/Introspector/LegacyIntrospectorTest.java

Changeset: 3d3ef4073bdd
Author:    jgodinez
Date:      2008-08-19 16:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3d3ef4073bdd

6731826: race condition in UnixPrintServiceLookup
Reviewed-by: campbell, tdv

! src/solaris/classes/sun/print/IPPPrintService.java
+ test/javax/print/TestRaceCond.java

Changeset: cd88b4ad7f25
Author:    tdv
Date:      2008-08-28 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cd88b4ad7f25

6739267: D3D/OGL: add missing ThreeByteBgr to texture upload blit loop
Reviewed-by: campbell, flar

! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.c
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h

Changeset: b8f91ea2fb33
Author:    tdv
Date:      2008-09-12 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b8f91ea2fb33

6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal
Reviewed-by: prr, tdv
Contributed-by: rkennke at kennke.org

! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/share/classes/sun/swing/SwingUtilities2.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/native/sun/awt/fontpath.c
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java

Changeset: 41ff3f84cd96
Author:    prr
Date:      2008-09-24 11:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/41ff3f84cd96

6751621: TextLayout.getBounds() doesn't account for strike through
Reviewed-by: igor, dougfelt

! src/share/classes/sun/font/Decoration.java
! src/share/classes/sun/font/Underline.java
+ test/java/awt/font/TextLayout/DecorationBoundsTest.java

Changeset: 3bc4d79d8123
Author:    tdv
Date:      2008-10-09 17:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3bc4d79d8123

6749060: LCD AA text rendered incorrectly when destination is non opaque (sw pipeline only)
Reviewed-by: campbell, prr

! src/share/classes/sun/java2d/SurfaceData.java
! test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java

Changeset: 9a6094d65d28
Author:    jgodinez
Date:      2008-10-13 15:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9a6094d65d28

6732647: isAttributeValueSupported() is not consistant with getSupportedValues() for Copies, TEXT flavor
Reviewed-by: tdv, prr

! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintService.java
! test/javax/print/attribute/PSCopiesFlavorTest.java

Changeset: 22d965ed3b93
Author:    prr
Date:      2008-10-16 06:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/22d965ed3b93

6751616: outline for underline in TextLayout with underline is off rasterized underline
Reviewed-by: dougfelt, igor

! src/share/classes/sun/font/Decoration.java
+ test/java/awt/font/TextLayout/UnderlinePositionTest.java

Changeset: 665850610378
Author:    lana
Date:      2008-10-20 11:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/665850610378

Merge

- make/ASSEMBLY_EXCEPTION
- make/LICENSE
- make/README
- make/README-builds.html
- make/README.html
- make/THIRD_PARTY_README
- make/java/nio/spp.sh
- make/tools/auto_multi/Makefile
- make/tools/src/build/tools/automulti/AutoMulti.java
- make/tools/src/build/tools/automulti/README.txt
- make/tools/src/build/tools/automulti/TestALFGenerator.java
- make/tools/src/build/tools/automulti/TestALFLookAndFeel.java
- src/share/classes/java/nio/channels/package.html
- src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java
- src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java
- src/share/classes/javax/swing/colorchooser/SyntheticImage.java
- src/share/classes/org/jcp/xml/dsig/internal/package.html
- src/share/classes/sun/launcher/LauncherHelp.java
- src/share/classes/sun/nio/ch/OptionAdaptor.java
- src/share/classes/sun/nio/ch/SocketOpts.java
- src/share/classes/sun/nio/ch/SocketOptsImpl.java
- src/share/classes/sun/nio/ch/exceptions
! src/share/classes/sun/swing/SwingUtilities2.java
- src/share/javavm/include/opcodes.h
- src/share/javavm/include/opcodes.length
- src/share/javavm/include/opcodes.list
- src/share/javavm/include/opcodes.weight
- src/share/javavm/include/opcodes.wide
- src/share/javavm/include/sys_api.h
- src/share/javavm/include/typedefs.h
- src/solaris/classes/sun/awt/motif/MButtonPeer.java
- src/solaris/classes/sun/awt/motif/MCanvasPeer.java
- src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java
- src/solaris/classes/sun/awt/motif/MCheckboxPeer.java
- src/solaris/classes/sun/awt/motif/MChoicePeer.java
- src/solaris/classes/sun/awt/motif/MComponentPeer.java
- src/solaris/classes/sun/awt/motif/MCustomCursor.java
- src/solaris/classes/sun/awt/motif/MDataTransferer.java
- src/solaris/classes/sun/awt/motif/MDialogPeer.java
- src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java
- src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java
- src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java
- src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java
- src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java
- src/solaris/classes/sun/awt/motif/MFileDialogPeer.java
- src/solaris/classes/sun/awt/motif/MFramePeer.java
- src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java
- src/solaris/classes/sun/awt/motif/MInputMethod.java
- src/solaris/classes/sun/awt/motif/MInputMethodControl.java
- src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java
- src/solaris/classes/sun/awt/motif/MLabelPeer.java
- src/solaris/classes/sun/awt/motif/MListPeer.java
- src/solaris/classes/sun/awt/motif/MMenuBarPeer.java
- src/solaris/classes/sun/awt/motif/MMenuItemPeer.java
- src/solaris/classes/sun/awt/motif/MMenuPeer.java
- src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java
- src/solaris/classes/sun/awt/motif/MPanelPeer.java
- src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java
- src/solaris/classes/sun/awt/motif/MRobotPeer.java
- src/solaris/classes/sun/awt/motif/MScrollPanePeer.java
- src/solaris/classes/sun/awt/motif/MScrollbarPeer.java
- src/solaris/classes/sun/awt/motif/MTextAreaPeer.java
- src/solaris/classes/sun/awt/motif/MTextFieldPeer.java
- src/solaris/classes/sun/awt/motif/MWindowPeer.java
- src/solaris/classes/sun/awt/motif/X11Clipboard.java
- src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java
- src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java
- src/solaris/classes/sun/awt/motif/X11Selection.java
- src/solaris/classes/sun/awt/motif/X11SelectionHolder.java
- src/solaris/javavm/include/typedefs_md.h
- src/solaris/native/sun/awt/awt_Button.c
- src/solaris/native/sun/awt/awt_Canvas.c
- src/solaris/native/sun/awt/awt_Checkbox.c
- src/solaris/native/sun/awt/awt_Choice12.c
- src/solaris/native/sun/awt/awt_Choice21.c
- src/solaris/native/sun/awt/awt_Component.c
- src/solaris/native/sun/awt/awt_Cursor.c
- src/solaris/native/sun/awt/awt_DataTransferer.c
- src/solaris/native/sun/awt/awt_DataTransferer.h
- src/solaris/native/sun/awt/awt_FileDialog.c
- src/solaris/native/sun/awt/awt_GlobalCursorManager.c
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.c
- src/solaris/native/sun/awt/awt_Label.c
- src/solaris/native/sun/awt/awt_List.c
- src/solaris/native/sun/awt/awt_Menu.c
- src/solaris/native/sun/awt/awt_Menu.h
- src/solaris/native/sun/awt/awt_MenuBar.c
- src/solaris/native/sun/awt/awt_MenuBar.h
- src/solaris/native/sun/awt/awt_MenuComponent.c
- src/solaris/native/sun/awt/awt_MenuItem.c
- src/solaris/native/sun/awt/awt_PopupMenu.c
- src/solaris/native/sun/awt/awt_ScrollPane.c
- src/solaris/native/sun/awt/awt_Scrollbar.c
- src/solaris/native/sun/awt/awt_Selection.c
- src/solaris/native/sun/awt/awt_TextArea.c
- src/solaris/native/sun/awt/awt_TextArea.h
- src/solaris/native/sun/awt/awt_TextField.c
- src/solaris/native/sun/awt/awt_TextField.h
- src/solaris/native/sun/awt/awt_TopLevel.c
- src/solaris/native/sun/awt/awt_XmDnD.c
- src/solaris/native/sun/awt/awt_XmDnD.h
- src/solaris/native/sun/awt/awt_dnd.c
- src/solaris/native/sun/awt/awt_dnd.h
- src/solaris/native/sun/awt/awt_dnd_ds.c
- src/solaris/native/sun/awt/awt_dnd_dt.c
- src/solaris/native/sun/awt/awt_motif.c
- src/solaris/native/sun/awt/awt_motif12.c
- src/solaris/native/sun/awt/awt_motif21.c
- src/solaris/native/sun/awt/awt_xembed.c
- src/solaris/native/sun/awt/canvas.c
- src/solaris/native/sun/awt/cursor.c
- src/windows/javavm/include/typedefs_md.h
- test/javax/swing/JFileChooser/4252173/bug4252173.java
- test/javax/swing/JFileChooser/6524424/bug6524424.html
- test/javax/swing/JFileChooser/6524424/bug6524424.java
- test/sun/net/www/http/ChunkedInputStream/test.txt
- test/tools/launcher/Arrrghs.sh

Changeset: 452c58b2f533
Author:    tdv
Date:      2008-10-21 08:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/452c58b2f533

6755274: 6u10b33 2d tests fails on sles10x64 with jvm crash
Reviewed-by: campbell

! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java

Changeset: c739feb28074
Author:    prr
Date:      2008-10-28 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c739feb28074

6764543: SIGSEGV in libfontconfig.so starting from jdk7b33
Reviewed-by: campbell, igor

! src/solaris/native/sun/awt/fontpath.c

Changeset: 594c52582b21
Author:    tdv
Date:      2008-10-28 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/594c52582b21

6764257: D3D/OGL: color is not reset properly after save/restoreState() [RSL]
Reviewed-by: campbell

! src/share/classes/sun/java2d/pipe/BufferedContext.java
+ test/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java

Changeset: 9cdababf6179
Author:    igor
Date:      2008-10-29 01:52 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9cdababf6179

6761856: OpenJDK: vertical text metrics may be significanly different from those returned by Sun JDK
Reviewed-by: bae, prr

! src/share/native/sun/font/freetypeScaler.c
! test/java/awt/font/TextLayout/TextLayoutBounds.java

Changeset: 3a9d06af8830
Author:    bae
Date:      2008-11-01 20:42 +0300
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3a9d06af8830

6541476: PNG imageio plugin incorrectly handles iTXt chunk
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
+ test/javax/imageio/plugins/png/ITXtTest.java

Changeset: 8eb24fc88242
Author:    tdv
Date:      2008-11-18 17:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8eb24fc88242

6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage
Reviewed-by: campbell, flar

! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
+ test/sun/java2d/DirectX/OpaqueImageToSurfaceBlitTest/OpaqueImageToSurfaceBlitTest.java

Changeset: 3fea7e660a8f
Author:    tdv
Date:      2008-11-18 18:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3fea7e660a8f

6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
! src/windows/native/sun/java2d/d3d/D3DContext.cpp

Changeset: be363ea85cb4
Author:    jgodinez
Date:      2008-11-25 14:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/be363ea85cb4

6653384: Variable "initialized" in class CUPSPrinter is static by mistake
Reviewed-by: tdv, prr

! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
+ test/java/awt/print/PrinterJob/GetMediasTest.java

Changeset: c8eea39734e8
Author:    jgodinez
Date:      2008-12-04 10:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c8eea39734e8

6587245: Import declaration not used in sun.print.*
Reviewed-by: tdv, prr

! src/share/classes/javax/print/Doc.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDocPrintService.java
! src/share/classes/javax/print/PrintServiceLookup.java
! src/share/classes/javax/print/attribute/URISyntax.java
! src/share/classes/javax/print/event/PrintServiceAttributeEvent.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PrintJobAttributeException.java
! src/share/classes/sun/print/SunMinMaxPage.java
! src/share/classes/sun/print/SunPageSelection.java

Changeset: 15435c60c751
Author:    tdv
Date:      2008-12-04 11:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/15435c60c751

6708580: Java applications slow when EXA enabled
Reviewed-by: prr, tdv
Contributed-by: ceisserer <linuxhippy at gmail.com>

! make/sun/awt/mapfile-mawt-vers
! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c

Changeset: b0c446712fae
Author:    jgodinez
Date:      2008-12-08 10:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b0c446712fae

6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown
Reviewed-by: tdv, prr

! src/share/classes/java/awt/print/PrinterJob.java

Changeset: b163d898f83f
Author:    tdv
Date:      2008-12-08 17:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b163d898f83f

6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: bf5dd3128c6a
Author:    lana
Date:      2008-12-08 19:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bf5dd3128c6a

Merge


Changeset: 50c67678b0d1
Author:    lana
Date:      2009-01-06 16:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/50c67678b0d1

Merge

! src/share/classes/sun/swing/SwingUtilities2.java

Changeset: 8dcc06d43798
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8dcc06d43798

Added tag jdk7-b43 for changeset 50c67678b0d1

! .hgtags



From john.coomes at sun.com  Fri Jan 16 01:23:39 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:23:39 +0000
Subject: hg: jdk7/hotspot-gc/langtools: 4 new changesets
Message-ID: <20090116092347.3E10ADA88@hg.openjdk.java.net>

Changeset: 8db0c5fd6e99
Author:    jjg
Date:      2008-12-02 14:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8db0c5fd6e99

6778638: javadoc regression tests require tabs
Reviewed-by: darcy

! test/com/sun/javadoc/testSourceTab/DoubleTab/C.java
! test/com/sun/javadoc/testSourceTab/SingleTab/C.java
! test/com/sun/javadoc/testSourceTab/TestSourceTab.java

Changeset: 4efd44aa85ff
Author:    tbell
Date:      2008-12-05 21:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4efd44aa85ff

Merge


Changeset: e2f8f6daee9d
Author:    tbell
Date:      2008-12-19 10:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e2f8f6daee9d

Merge


Changeset: 05b47447cbcf
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/05b47447cbcf

Added tag jdk7-b43 for changeset e2f8f6daee9d

! .hgtags



From antonios.printezis at sun.com  Fri Jan 16 20:15:23 2009
From: antonios.printezis at sun.com (antonios.printezis at sun.com)
Date: Sat, 17 Jan 2009 04:15:23 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6484956: G1: improve evacuation pause
	efficiency
Message-ID: <20090117041528.E658EDB37@hg.openjdk.java.net>

Changeset: 818efdefcc99
Author:    tonyp
Date:      2009-01-16 13:02 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/818efdefcc99

6484956: G1: improve evacuation pause efficiency
Summary: A bunch of performance optimizations to decrease GC pause times in G1.
Reviewed-by: apetrusenko, jmasa, iveresov

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/includeDB_gc_shared



From john.coomes at sun.com  Thu Jan 22 14:52:52 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Thu, 22 Jan 2009 22:52:52 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 7 new changesets
Message-ID: <20090122225305.4B90FDE32@hg.openjdk.java.net>

Changeset: 52a431267315
Author:    coleenp
Date:      2009-01-13 14:41 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/52a431267315

6791168: Fix invalid code in bytecodeInterpreter that can cause gcc ICE
Summary: Fix compilation errors from latest gcc in CC_INTERP including offending missing void* cast.
Reviewed-by: xlu

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/bytecodeInterpreter.hpp

Changeset: 4db4e58c16bd
Author:    xlu
Date:      2009-01-13 12:08 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4db4e58c16bd

6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms when initializing direct buffer support
Summary: Place the state transition inside the loop so that the VMThread could proceed for safepoint
Reviewed-by: dholmes, never, acorn

! src/share/vm/prims/jni.cpp

Changeset: 9250583801d2
Author:    xlu
Date:      2009-01-13 12:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9250583801d2

Merge


Changeset: 2ddbaf7b8e1c
Author:    xlu
Date:      2009-01-13 14:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2ddbaf7b8e1c

Merge


Changeset: c9004fe53695
Author:    xlu
Date:      2009-01-13 17:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c9004fe53695

6792301: StackAlignmentInBytes not honored for compiled native methods
Summary: Fixed the stack misalignment when generate_native_wrapper is called.
Reviewed-by: never, kamg, kvn, phh

! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp

Changeset: f6c0827e5919
Author:    coleenp
Date:      2009-01-15 12:44 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f6c0827e5919

Merge


Changeset: 2b1de1db9a9d
Author:    jcoomes
Date:      2009-01-21 13:40 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2b1de1db9a9d

Merge




From john.coomes at sun.com  Thu Jan 22 21:27:48 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 05:27:48 +0000
Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b44 for changeset a395e3aac474
Message-ID: <20090123052748.AFD25DEFE@hg.openjdk.java.net>

Changeset: 99846f001ca2
Author:    xdono
Date:      2009-01-22 14:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/99846f001ca2

Added tag jdk7-b44 for changeset a395e3aac474

! .hgtags



From john.coomes at sun.com  Thu Jan 22 21:30:00 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 05:30:00 +0000
Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b44 for changeset
	9803dac72540
Message-ID: <20090123053002.6C8C0DF03@hg.openjdk.java.net>

Changeset: 68814aa5b44b
Author:    xdono
Date:      2009-01-22 14:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/68814aa5b44b

Added tag jdk7-b44 for changeset 9803dac72540

! .hgtags



From john.coomes at sun.com  Thu Jan 22 21:35:07 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 05:35:07 +0000
Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b44 for changeset
	b203df0741af
Message-ID: <20090123053510.5BAE2DF08@hg.openjdk.java.net>

Changeset: 0f113667880d
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/0f113667880d

Added tag jdk7-b44 for changeset b203df0741af

! .hgtags



From john.coomes at sun.com  Thu Jan 22 21:37:36 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 05:37:36 +0000
Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b44 for changeset
	344485a03674
Message-ID: <20090123053739.39EE6DF0D@hg.openjdk.java.net>

Changeset: dea7753d7139
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/dea7753d7139

Added tag jdk7-b44 for changeset 344485a03674

! .hgtags



From john.coomes at sun.com  Thu Jan 22 21:40:20 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 05:40:20 +0000
Subject: hg: jdk7/hotspot-gc/jdk: 17 new changesets
Message-ID: <20090123054347.B1A61DF12@hg.openjdk.java.net>

Changeset: 57dc40ece164
Author:    sherman
Date:      2008-12-17 22:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/57dc40ece164

6496274: jar seems to use more CPU than it should
Summary: boost jar creating performance especially for the large jar file
Reviewed-by: martin

! src/share/classes/sun/tools/jar/Main.java

Changeset: 85fe3cd9d6f9
Author:    wetmore
Date:      2008-12-19 10:35 +0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/85fe3cd9d6f9

6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider
Summary: This is the JSSE portion of the fix. Main part is in PKCS11.
Reviewed-by: valeriep, xuelei

! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: 850d381fa9aa
Author:    tbell
Date:      2008-12-19 22:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/850d381fa9aa

Merge


Changeset: 3d09cc6c4ea9
Author:    alanb
Date:      2008-12-22 19:28 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3d09cc6c4ea9

6787009: (attach) Stub injection potentially unsafe on windows-x64
Reviewed-by: mchung

! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c

Changeset: 37a9442e3203
Author:    tbell
Date:      2009-01-09 21:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/37a9442e3203

Merge


Changeset: 0bd360988b3a
Author:    thurka
Date:      2009-01-07 14:06 +0100
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0bd360988b3a

6790467: Add test for setInterval() for local MonitoredHost and local MonitoredVm
Summary: test for MonitoredHost.setInterval() and MonitoredVm.setInterval() added
Reviewed-by: swamyv

+ test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java

Changeset: ff572b4f1ca4
Author:    martin
Date:      2009-01-07 11:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ff572b4f1ca4

6788196: (porting) Bounds checks in io_util.c rely on undefined behaviour
Reviewed-by: alanb
Contributed-by: gbenson at redhat.com

! src/share/native/java/io/io_util.c
! test/java/io/readBytes/ReadBytesBounds.java

Changeset: 0272e442cc5b
Author:    martin
Date:      2009-01-08 14:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0272e442cc5b

6791458: FileInputStream/RandomAccessFile.read leaks memory if invoked on closed stream with len > 8k
Reviewed-by: alanb
Contributed-by: jeremymanson at google.com

! src/share/native/java/io/io_util.c
+ test/java/io/readBytes/MemoryLeak.java

Changeset: f6c105e60186
Author:    bpatel
Date:      2009-01-07 16:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f6c105e60186

6790217: Javadoc HTML WCAG 2.0 accessibility issues in jdk docs makefile - Bold tags should be strong
Reviewed-by: jjg

! make/docs/Makefile

Changeset: 71a6cd33d365
Author:    bpatel
Date:      2009-01-08 14:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/71a6cd33d365

Merge


Changeset: f5062c0ae8d5
Author:    bpatel
Date:      2009-01-08 15:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f5062c0ae8d5

Merge


Changeset: 961ea5a46a0c
Author:    martin
Date:      2009-01-09 16:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/961ea5a46a0c

6792066: src/share/native/java/io/io_util.c clean-ups
Reviewed-by: alanb

! src/share/native/java/io/io_util.c
! src/share/native/java/io/io_util.h

Changeset: 5c39d920b488
Author:    tbell
Date:      2009-01-09 22:01 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5c39d920b488

Merge


Changeset: 4dab1a24dca2
Author:    tbell
Date:      2009-01-16 10:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4dab1a24dca2

Merge


Changeset: 6dce6ac0929e
Author:    tbell
Date:      2009-01-14 21:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6dce6ac0929e

6754862: jdk/src/windows/bin/java_md.c: hardcoded reference to msvcr71.dll
6779412: VS2008 errors compiling jdk sources
Summary: Update Makefiles to tolerate newer Visual Studio releases and runtimes.
Reviewed-by: ohair

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/shared/Compiler-msvc.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/java/main/java/Makefile
! make/java/main/javaw/Makefile
! make/java/redist/Makefile
! src/share/bin/main.c
! src/windows/bin/java_md.c

Changeset: d8eb2738db6b
Author:    xdono
Date:      2009-01-20 09:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d8eb2738db6b

Merge

- src/share/classes/sun/nio/cs/IBM437.java
- src/share/classes/sun/nio/cs/IBM737.java
- src/share/classes/sun/nio/cs/IBM775.java
- src/share/classes/sun/nio/cs/IBM850.java
- src/share/classes/sun/nio/cs/IBM852.java
- src/share/classes/sun/nio/cs/IBM855.java
- src/share/classes/sun/nio/cs/IBM857.java
- src/share/classes/sun/nio/cs/IBM858.java
- src/share/classes/sun/nio/cs/IBM862.java
- src/share/classes/sun/nio/cs/IBM866.java
- src/share/classes/sun/nio/cs/IBM874.java
- src/share/classes/sun/nio/cs/ISO_8859_13.java
- src/share/classes/sun/nio/cs/ISO_8859_15.java
- src/share/classes/sun/nio/cs/ISO_8859_2.java
- src/share/classes/sun/nio/cs/ISO_8859_4.java
- src/share/classes/sun/nio/cs/ISO_8859_5.java
- src/share/classes/sun/nio/cs/ISO_8859_7.java
- src/share/classes/sun/nio/cs/ISO_8859_9.java
- src/share/classes/sun/nio/cs/KOI8_R.java
- src/share/classes/sun/nio/cs/KOI8_U.java
- src/share/classes/sun/nio/cs/MS1250.java
- src/share/classes/sun/nio/cs/MS1251.java
- src/share/classes/sun/nio/cs/MS1252.java
- src/share/classes/sun/nio/cs/MS1253.java
- src/share/classes/sun/nio/cs/MS1254.java
- src/share/classes/sun/nio/cs/MS1257.java
- src/share/classes/sun/nio/cs/ext/IBM037.java
- src/share/classes/sun/nio/cs/ext/IBM1006.java
- src/share/classes/sun/nio/cs/ext/IBM1025.java
- src/share/classes/sun/nio/cs/ext/IBM1026.java
- src/share/classes/sun/nio/cs/ext/IBM1046.java
- src/share/classes/sun/nio/cs/ext/IBM1047.java
- src/share/classes/sun/nio/cs/ext/IBM1097.java
- src/share/classes/sun/nio/cs/ext/IBM1098.java
- src/share/classes/sun/nio/cs/ext/IBM1112.java
- src/share/classes/sun/nio/cs/ext/IBM1122.java
- src/share/classes/sun/nio/cs/ext/IBM1123.java
- src/share/classes/sun/nio/cs/ext/IBM1124.java
- src/share/classes/sun/nio/cs/ext/IBM1140.java
- src/share/classes/sun/nio/cs/ext/IBM1141.java
- src/share/classes/sun/nio/cs/ext/IBM1142.java
- src/share/classes/sun/nio/cs/ext/IBM1143.java
- src/share/classes/sun/nio/cs/ext/IBM1144.java
- src/share/classes/sun/nio/cs/ext/IBM1145.java
- src/share/classes/sun/nio/cs/ext/IBM1146.java
- src/share/classes/sun/nio/cs/ext/IBM1147.java
- src/share/classes/sun/nio/cs/ext/IBM1148.java
- src/share/classes/sun/nio/cs/ext/IBM1149.java
- src/share/classes/sun/nio/cs/ext/IBM273.java
- src/share/classes/sun/nio/cs/ext/IBM277.java
- src/share/classes/sun/nio/cs/ext/IBM278.java
- src/share/classes/sun/nio/cs/ext/IBM280.java
- src/share/classes/sun/nio/cs/ext/IBM284.java
- src/share/classes/sun/nio/cs/ext/IBM285.java
- src/share/classes/sun/nio/cs/ext/IBM297.java
- src/share/classes/sun/nio/cs/ext/IBM420.java
- src/share/classes/sun/nio/cs/ext/IBM424.java
- src/share/classes/sun/nio/cs/ext/IBM500.java
- src/share/classes/sun/nio/cs/ext/IBM838.java
- src/share/classes/sun/nio/cs/ext/IBM856.java
- src/share/classes/sun/nio/cs/ext/IBM860.java
- src/share/classes/sun/nio/cs/ext/IBM861.java
- src/share/classes/sun/nio/cs/ext/IBM863.java
- src/share/classes/sun/nio/cs/ext/IBM864.java
- src/share/classes/sun/nio/cs/ext/IBM865.java
- src/share/classes/sun/nio/cs/ext/IBM868.java
- src/share/classes/sun/nio/cs/ext/IBM869.java
- src/share/classes/sun/nio/cs/ext/IBM870.java
- src/share/classes/sun/nio/cs/ext/IBM871.java
- src/share/classes/sun/nio/cs/ext/IBM875.java
- src/share/classes/sun/nio/cs/ext/IBM918.java
- src/share/classes/sun/nio/cs/ext/IBM921.java
- src/share/classes/sun/nio/cs/ext/IBM922.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_11.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_3.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_6.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_8.java
- src/share/classes/sun/nio/cs/ext/MS1255.java
- src/share/classes/sun/nio/cs/ext/MS1256.java
- src/share/classes/sun/nio/cs/ext/MS1258.java
- src/share/classes/sun/nio/cs/ext/MS874.java
- src/share/classes/sun/nio/cs/ext/MacArabic.java
- src/share/classes/sun/nio/cs/ext/MacCentralEurope.java
- src/share/classes/sun/nio/cs/ext/MacCroatian.java
- src/share/classes/sun/nio/cs/ext/MacCyrillic.java
- src/share/classes/sun/nio/cs/ext/MacDingbat.java
- src/share/classes/sun/nio/cs/ext/MacGreek.java
- src/share/classes/sun/nio/cs/ext/MacHebrew.java
- src/share/classes/sun/nio/cs/ext/MacIceland.java
- src/share/classes/sun/nio/cs/ext/MacRoman.java
- src/share/classes/sun/nio/cs/ext/MacRomania.java
- src/share/classes/sun/nio/cs/ext/MacSymbol.java
- src/share/classes/sun/nio/cs/ext/MacThai.java
- src/share/classes/sun/nio/cs/ext/MacTurkish.java
- src/share/classes/sun/nio/cs/ext/MacUkraine.java
- src/share/classes/sun/nio/cs/ext/TIS_620.java

Changeset: 527b426497a2
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/527b426497a2

Added tag jdk7-b44 for changeset d8eb2738db6b

! .hgtags



From john.coomes at sun.com  Thu Jan 22 21:48:50 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 05:48:50 +0000
Subject: hg: jdk7/hotspot-gc/langtools: 9 new changesets
Message-ID: <20090123054904.CD927DF17@hg.openjdk.java.net>

Changeset: 7a595d92e252
Author:    jjg
Date:      2009-01-07 14:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/7a595d92e252

6512707: "incompatible types" after (unrelated) annotation processing
Reviewed-by: darcy
Contributed-by: prunge at velocitynet.com.au

! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/processing/6512707/T6512707.java
+ test/tools/javac/processing/6512707/TestAnnotation.java
+ test/tools/javac/processing/6512707/TestEnum.java

Changeset: 47a62d8d98b4
Author:    bpatel
Date:      2009-01-08 16:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/47a62d8d98b4

6786028: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Bold tags should be strong
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java
! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java
! test/com/sun/javadoc/AuthorDD/AuthorDD.java
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testClassTree/TestClassTree.java
! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java
! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHeadings/TestHeadings.java
! test/com/sun/javadoc/testHelpOption/TestHelpOption.java
! test/com/sun/javadoc/testHref/TestHref.java
+ test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java
+ test/com/sun/javadoc/testHtmlStrongTag/pkg1/C1.java
+ test/com/sun/javadoc/testHtmlStrongTag/pkg2/C2.java
! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java
! test/com/sun/javadoc/testLinkOption/TestLinkOption.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNavagation/TestNavagation.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java
! test/com/sun/javadoc/testPackagePage/TestPackagePage.java
! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java
! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java

Changeset: dbe9e82f9d25
Author:    bpatel
Date:      2009-01-08 16:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/dbe9e82f9d25

Merge

! test/com/sun/javadoc/AuthorDD/AuthorDD.java

Changeset: 905e151a185a
Author:    mcimadamore
Date:      2009-01-13 13:27 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/905e151a185a

6765045: Remove rawtypes warnings from langtools
Summary: Removed all occurrences of rawtypes warnings from langtools
Reviewed-by: jjg, bpatel

! make/build.properties
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! src/share/classes/com/sun/tools/javac/Main.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java
! src/share/classes/com/sun/tools/javac/util/Context.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
! src/share/classes/com/sun/tools/javah/Gen.java
! src/share/classes/com/sun/tools/javah/LLNI.java
! src/share/classes/com/sun/tools/javah/TypeSignature.java
! src/share/classes/sun/tools/javap/FieldData.java
! src/share/classes/sun/tools/javap/JavapPrinter.java
! src/share/classes/sun/tools/javap/MethodData.java

Changeset: d57378c34fdb
Author:    mcimadamore
Date:      2009-01-13 13:28 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d57378c34fdb

6665356: Cast not allowed when both qualifying type and inner class are parameterized
Summary: Fixed parser and cats conversion in order to allow cast between generic inner classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/cast/6665356/T6665356.java
+ test/tools/javac/cast/6665356/T6665356.out
+ test/tools/javac/generics/rare/6665356/T6665356.java
+ test/tools/javac/generics/rare/6665356/T6665356.out

Changeset: 09eb1acc9610
Author:    mcimadamore
Date:      2009-01-13 13:28 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/09eb1acc9610

6723444: javac fails to substitute type variables into a constructor's throws clause
Summary: Added constructor's actual type info to NewClass AST node
Reviewed-by: jjg
Contributed-by: mark at twistedbanana.demon.co.uk

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/generics/6723444/T6723444.java
+ test/tools/javac/generics/6723444/T6723444.out

Changeset: e157bd68dfc5
Author:    mcimadamore
Date:      2009-01-13 13:31 +0000
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e157bd68dfc5

6558559: Extra "unchecked" diagnostic
Summary: Fixed Types.sideCast in order to suppress redundant unchecked warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6558559/T6558559a.java
+ test/tools/javac/cast/6558559/T6558559b.java

Changeset: 28f0b10d6c1a
Author:    tbell
Date:      2009-01-16 10:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/28f0b10d6c1a

Merge


Changeset: 30db5e0aaf83
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/30db5e0aaf83

Added tag jdk7-b44 for changeset 28f0b10d6c1a

! .hgtags



From mail at nmichael.de  Thu Jan 22 23:26:29 2009
From: mail at nmichael.de (Nicolas Michael)
Date: Fri, 23 Jan 2009 07:26:29 GMT
Subject: Number of Parallel GC Threads
Message-ID: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>

Hi,

on server-class machines, you are using the ParallelGC collector as the default
collector. This collector is per default using as many parallel gc threads as
there are cpus in the system. As far as I remember, you are doing this because
you are assuming that people usually just run one JVM on their server, so you're
optimizing for that case -- and telling people to explicitly decrease their
number of gc threads when running multiple JVM's. (As some of you know, we are
doing just that for our "most important" JVM instances we're running.)

However, we also have some little Java-based agents running on our systems which
just use the defaults. On our T5240's and T5440's they end up having 128 resp.
256 parallel gc threads! I'm wondering whether this is really a "reasonable"
default behavior?! Would someone really run just one JVM on such a large system?
Does it make sense to have 256 parallel gc threads as a *default* on such
servers? I was thinking that it may be better to limit the maximum number of
parallel gc threads that are created per default to a more "conservative" number
(whatever this number would be... 16? 32? ...?).

Well, this is just a thought. I could imagine that there are lots of Java-based
tools around (management GUIs, ...) that people run on their servers. And many
of those tools usually don't set any JVM parameters except probably the max heap
size. If I was starting such a tool as an operator, I wouldn't want it to
interrupt my workload by doing garbage collection with 256 threads in parallel.

Another idea: The demand for many gc threads also depends a little on the heap
size. An application with a default 64m heap will most likely not benefit much
from 256 gc threads, while an application with 4g of heap might. So the heap
size could be another indication of how many parallel gc threads would make
sense as a default.

I'd be interested to hear your opinion on that.

Thanks,
Nick.



From Thomas.Viessmann at Sun.COM  Thu Jan 22 23:49:32 2009
From: Thomas.Viessmann at Sun.COM (Thomas Viessmann)
Date: Fri, 23 Jan 2009 08:49:32 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
Message-ID: <4979768C.1060205@sun.com>

Hi Michael,


I totally agree in what you're saying. With the success of the
UltraSparc T1 and T2 processor families, this is becoming more
and more an issue. I'm in the customer service group and
an increasing number of service requests are due to mis-
or non-configuration of the parallel GC threads. Let's see what
the development team thinks about this. Many thanks.



Nicolas Michael wrote:
> Hi,
>
> on server-class machines, you are using the ParallelGC collector as the default
> collector. This collector is per default using as many parallel gc threads as
> there are cpus in the system. As far as I remember, you are doing this because
> you are assuming that people usually just run one JVM on their server, so you're
> optimizing for that case -- and telling people to explicitly decrease their
> number of gc threads when running multiple JVM's. (As some of you know, we are
> doing just that for our "most important" JVM instances we're running.)
>
> However, we also have some little Java-based agents running on our systems which
> just use the defaults. On our T5240's and T5440's they end up having 128 resp.
> 256 parallel gc threads! I'm wondering whether this is really a "reasonable"
> default behavior?! Would someone really run just one JVM on such a large system?
> Does it make sense to have 256 parallel gc threads as a *default* on such
> servers? I was thinking that it may be better to limit the maximum number of
> parallel gc threads that are created per default to a more "conservative" number
> (whatever this number would be... 16? 32? ...?).
>
> Well, this is just a thought. I could imagine that there are lots of Java-based
> tools around (management GUIs, ...) that people run on their servers. And many
> of those tools usually don't set any JVM parameters except probably the max heap
> size. If I was starting such a tool as an operator, I wouldn't want it to
> interrupt my workload by doing garbage collection with 256 threads in parallel.
>
> Another idea: The demand for many gc threads also depends a little on the heap
> size. An application with a default 64m heap will most likely not benefit much
> from 256 gc threads, while an application with 4g of heap might. So the heap
> size could be another indication of how many parallel gc threads would make
> sense as a default.
>
> I'd be interested to hear your opinion on that.
>
> Thanks,
> Nick.
>
>   


-- 
--- 
mit freundlichen Gruessen / with kind regards


Thomas Viessmann

Global Sales and Services - Software Support Engineering

Sun Microsystems GmbH           Phone:  +49 (0)89 46008 2365 / x62365
Sonnenallee 1                   Mobile: +49 (0)174 300 5467
D-85551 Kirchheim-Heimstetten   Pager:  Thomas.Viessmann at sun.itechtool.com
Germany/Deutschland             mailto: Thomas.Viessmann at sun.com
http://www.sun.de 		

Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer:  Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering



From linuxhippy at gmail.com  Fri Jan 23 07:36:23 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 23 Jan 2009 16:36:23 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
Message-ID: <194f62550901230736q102970a3mcee7e74292669529@mail.gmail.com>

Hi Nicolas,

> However, we also have some little Java-based agents running on our systems which
> just use the defaults. On our T5240's and T5440's they end up having 128 resp.
> 256 parallel gc threads! I'm wondering whether this is really a "reasonable"
> default behavior?! Would someone really run just one JVM on such a large system?
> Does it make sense to have 256 parallel gc threads as a *default* on such
> servers?

Well, except a bit of wasted memory (because each thread has its own
private data structures) I think it does not hurt a lot.
It should be a rather rare case that two JVMs running run a gc-cycle
at the same time for which performance will be a bit worse, however
when there are no gc-cycle "collisions" each JVM will have lowest
possible gc pause time.

- Clemens


From Antonios.Printezis at sun.com  Fri Jan 23 07:33:57 2009
From: Antonios.Printezis at sun.com (Tony Printezis)
Date: Fri, 23 Jan 2009 10:33:57 -0500
Subject: Number of Parallel GC Threads
In-Reply-To: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
Message-ID: <4979E365.7000207@sun.com>

Nick,

First, a correction. For very large machines, we don't set the number of 
GC threads to be the same as the CPUs (there are diminishing returns if 
we do that). Currently, you get 1 parallel GC thread per CPU for up to 8 
CPUs, and 5/8 after that (so for 16 CPUs you get: 8 + 5/8 x 8 = 13 GC 
threads).

Now, regarding what we pick for the defaults: whatever we do, someone is 
going to be happy, and someone will not be. I've always seen the 
defaults as trying to do a not-so-embarrassing job for naive users. If 
someone is running several JVMs per box, then I assume that they know 
what they are doing, so playing around with the # of parallel GC threads 
should be straightforward to them! :-) And, incidentally, folks who do 
run more than one JVM per large box typically use processor sets or 
zones to partition the machines; in that case, our algorithm should do 
the right thing.

Tony

Nicolas Michael wrote:
> Hi,
>
> on server-class machines, you are using the ParallelGC collector as the default
> collector. This collector is per default using as many parallel gc threads as
> there are cpus in the system. As far as I remember, you are doing this because
> you are assuming that people usually just run one JVM on their server, so you're
> optimizing for that case -- and telling people to explicitly decrease their
> number of gc threads when running multiple JVM's. (As some of you know, we are
> doing just that for our "most important" JVM instances we're running.)
>
> However, we also have some little Java-based agents running on our systems which
> just use the defaults. On our T5240's and T5440's they end up having 128 resp.
> 256 parallel gc threads! I'm wondering whether this is really a "reasonable"
> default behavior?! Would someone really run just one JVM on such a large system?
> Does it make sense to have 256 parallel gc threads as a *default* on such
> servers? I was thinking that it may be better to limit the maximum number of
> parallel gc threads that are created per default to a more "conservative" number
> (whatever this number would be... 16? 32? ...?).
>
> Well, this is just a thought. I could imagine that there are lots of Java-based
> tools around (management GUIs, ...) that people run on their servers. And many
> of those tools usually don't set any JVM parameters except probably the max heap
> size. If I was starting such a tool as an operator, I wouldn't want it to
> interrupt my workload by doing garbage collection with 256 threads in parallel.
>
> Another idea: The demand for many gc threads also depends a little on the heap
> size. An application with a default 64m heap will most likely not benefit much
> from 256 gc threads, while an application with 4g of heap might. So the heap
> size could be another indication of how many parallel gc threads would make
> sense as a default.
>
> I'd be interested to hear your opinion on that.
>
> Thanks,
> Nick.
>
>   

-- 
----------------------------------------------------------------------
| Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
|                                   | MS BUR02-311                   |
| e-mail: tony.printezis at sun.com    | 35 Network Drive               |
| office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
----------------------------------------------------------------------
e-mail client: Thunderbird (Solaris)




From Jon.Masamitsu at Sun.COM  Fri Jan 23 07:37:02 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 23 Jan 2009 07:37:02 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
Message-ID: <4979E41E.30902@sun.com>

Nick,

The simpliest solution for your problem is to run the
small applications with -client.

This is a basic "one size does not fit all" problem.  For
many years we ran the JVM with -client as the default
and we got plenty of  complaints about poor
performance.  Some of it went along the lines of
"You're running on a huge system, why don't you
use it".

In the latest jdk 6 updates the default number of threads
is less than the number of CPU's.   For  a T5240 (128 hardware
threads) I think it will be about 40 GC threads.
Of course that is still too many for the small applications.

By the way, on a server class machine the default
heap size depends on the amount of physical memory
(use 1/4 of the physical memory as the default maximum
heap size).  So we cannot use the maximum heap size
as a way to decide how many GC threads to use.   A
customer would have to add a different maximum
heap size.  If they are willing to do that, they should
just add -client when appropriate.

When the JVM initializes, it knows nothing about the
application so cannot tell if it is "big" or "small".    We
don't maintain a database of applications in order to
tell what are good numbers to use for each application
and there is no project in the works to do that.

We've wanted to add to the JVM the ability to monitor
the resources of the system that it is running on and
to modify its behavior (i.e., if there are lots of processes
running, reduce the maximum size of the heap and
number of GC threads) but we have no one to work on
it.

Jon


Nicolas Michael wrote On 01/22/09 23:26,:

>Hi,
>
>on server-class machines, you are using the ParallelGC collector as the default
>collector. This collector is per default using as many parallel gc threads as
>there are cpus in the system. As far as I remember, you are doing this because
>you are assuming that people usually just run one JVM on their server, so you're
>optimizing for that case -- and telling people to explicitly decrease their
>number of gc threads when running multiple JVM's. (As some of you know, we are
>doing just that for our "most important" JVM instances we're running.)
>
>However, we also have some little Java-based agents running on our systems which
>just use the defaults. On our T5240's and T5440's they end up having 128 resp.
>256 parallel gc threads! I'm wondering whether this is really a "reasonable"
>default behavior?! Would someone really run just one JVM on such a large system?
>Does it make sense to have 256 parallel gc threads as a *default* on such
>servers? I was thinking that it may be better to limit the maximum number of
>parallel gc threads that are created per default to a more "conservative" number
>(whatever this number would be... 16? 32? ...?).
>
>Well, this is just a thought. I could imagine that there are lots of Java-based
>tools around (management GUIs, ...) that people run on their servers. And many
>of those tools usually don't set any JVM parameters except probably the max heap
>size. If I was starting such a tool as an operator, I wouldn't want it to
>interrupt my workload by doing garbage collection with 256 threads in parallel.
>
>Another idea: The demand for many gc threads also depends a little on the heap
>size. An application with a default 64m heap will most likely not benefit much
>from 256 gc threads, while an application with 4g of heap might. So the heap
>size could be another indication of how many parallel gc threads would make
>sense as a default.
>
>I'd be interested to hear your opinion on that.
>
>Thanks,
>Nick.
>
>  
>



From Jon.Masamitsu at Sun.COM  Fri Jan 23 07:54:10 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 23 Jan 2009 07:54:10 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <4979E365.7000207@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com>
Message-ID: <4979E822.6060001@sun.com>

Tony Printezis wrote On 01/23/09 07:33,:

>Nick,
>
>First, a correction. For very large machines, we don't set the number of 
>GC threads to be the same as the CPUs (there are diminishing returns if 
>we do that). Currently, you get 1 parallel GC thread per CPU for up to 8 
>CPUs, and 5/8 after that (so for 16 CPUs you get: 8 + 5/8 x 8 = 13 GC 
>threads).
>
>  
>
Tony,

This is a bit of embarassment on my part.  What you say is true
for all the collectors except UseParallelGC.  In the early jdk6's
and before,  we used all the cpu's for GC for UseParallelGC
(the default for server-class machines).  That was fixed in
jdk6 update 10 (I believe).

Jon


From kirk at kodewerk.com  Fri Jan 23 09:39:45 2009
From: kirk at kodewerk.com (kirk)
Date: Fri, 23 Jan 2009 18:39:45 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <4979E822.6060001@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>	<4979E365.7000207@sun.com>
	<4979E822.6060001@sun.com>
Message-ID: <497A00E1.4030105@kodewerk.com>

Jon Masamitsu wrote:
> Tony Printezis wrote On 01/23/09 07:33,:
>
>   
>> Nick,
>>
>> First, a correction. For very large machines, we don't set the number of 
>> GC threads to be the same as the CPUs (there are diminishing returns if 
>> we do that). Currently, you get 1 parallel GC thread per CPU for up to 8 
>> CPUs, and 5/8 after that (so for 16 CPUs you get: 8 + 5/8 x 8 = 13 GC 
>> threads).
>>
>>  
>>
>>     
> Tony,
>
> This is a bit of embarassment on my part.  What you say is true
> for all the collectors except UseParallelGC.  In the early jdk6's
> and before,  we used all the cpu's for GC for UseParallelGC
> (the default for server-class machines).  That was fixed in
> jdk6 update 10 (I believe).
>
> Jon
>
>   
I've come into a couple of situations where I need to throttle back on 
GC threads so I think the request to throttle based on the -Xmx setting 
seem reasonable.

Regards,
Kirk


From Jon.Masamitsu at Sun.COM  Fri Jan 23 10:03:30 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 23 Jan 2009 10:03:30 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <4979E41E.30902@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E41E.30902@sun.com>
Message-ID: <497A0672.9030402@sun.com>

Jon Masamitsu wrote On 01/23/09 07:37,:

>...
>
>In the latest jdk 6 updates the default number of threads
>is less than the number of CPU's.   For  a T5240 (128 hardware
>threads) I think it will be about 40 GC threads.
>Of course that is still too many for the small applications.
>
>  
>

So this 40 for 128 hardware threads is not the 5/8's rule as Tony
described.   Niagaras with > 32 hardware threads use a more
conservative 5/16's rule. 


From Jon.Masamitsu at Sun.COM  Fri Jan 23 10:09:42 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 23 Jan 2009 10:09:42 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <497A00E1.4030105@kodewerk.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com>
Message-ID: <497A07E6.4070507@sun.com>

kirk wrote On 01/23/09 09:39,:

> ...
>
>>  
>>    
>>
>I've come into a couple of situations where I need to throttle back on 
>GC threads so I think the request to throttle based on the -Xmx setting 
>seem reasonable.
>  
>

How do you decide the number of GC threads given a maximum heap size?
Do you scale the number of GC threads linearly with the maximum
heap size?


From kirk at kodewerk.com  Fri Jan 23 11:19:47 2009
From: kirk at kodewerk.com (kirk)
Date: Fri, 23 Jan 2009 20:19:47 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <497A07E6.4070507@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
Message-ID: <497A1853.4090508@kodewerk.com>

Jon Masamitsu wrote:
> kirk wrote On 01/23/09 09:39,:
>
>   
>> ...
>>
>>     
>>>  
>>>    
>>>
>>>       
>> I've come into a couple of situations where I need to throttle back on 
>> GC threads so I think the request to throttle based on the -Xmx setting 
>> seem reasonable.
>>  
>>
>>     
>
> How do you decide the number of GC threads given a maximum heap size?
> Do you scale the number of GC threads linearly with the maximum
> heap size?
>
>   
Good question. As Tony pointed out, there seems to be a useful number of 
threads to allocate and so his formulation deviates from linear in cases 
where there are a large number of CPUs. In this case I guess I would cap 
at the min offered by that value and one determined by memory. I don't 
have a good feeling for what that other formula would look like but a 
good starting point could be something like 1 for something like every 
64mb. The actual value could be adjusted using some observations about 
how GC was behaving.

Kirk




From kirk at kodewerk.com  Fri Jan 23 11:22:07 2009
From: kirk at kodewerk.com (kirk)
Date: Fri, 23 Jan 2009 20:22:07 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <497A07E6.4070507@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
Message-ID: <497A18DF.6000608@kodewerk.com>

Jon Masamitsu wrote:
> kirk wrote On 01/23/09 09:39,:
>
>   
>> ...
>>
>>     
>>>  
>>>    
>>>
>>>       
>> I've come into a couple of situations where I need to throttle back on 
>> GC threads so I think the request to throttle based on the -Xmx setting 
>> seem reasonable.
>>  
>>
>>     
>
> How do you decide the number of GC threads given a maximum heap size?
> Do you scale the number of GC threads linearly with the maximum
> heap size?
>
>   
I should add that I think that the bigger problem is that GC doesn't 
play nice when you have many VMs running on the same hardware. (point 
taken about partitioning and all that). Some how it has to figure out if 
it has free reign or if it need to share.

Kirk


From linuxhippy at gmail.com  Fri Jan 23 11:41:54 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 23 Jan 2009 20:41:54 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <497A18DF.6000608@kodewerk.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
	<497A18DF.6000608@kodewerk.com>
Message-ID: <194f62550901231141g59ac4e0fkb49ff56fbcbcc2a@mail.gmail.com>

> I should add that I think that the bigger problem is that GC doesn't play nice
> when you have many VMs running on the same hardware.
> (point taken about partitioning and all that).
> Some how it has to figure out if it has free reign or if it need to share.

In theory there are slowdowns when three or more JVMs run their GC at
exactly the same time, but how often does that happen.
Do you have any evidence that this is a problem in real-world useage?

- Clemens


From Y.S.Ramakrishna at Sun.COM  Fri Jan 23 12:00:56 2009
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Fri, 23 Jan 2009 12:00:56 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <194f62550901231141g59ac4e0fkb49ff56fbcbcc2a@mail.gmail.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
	<497A18DF.6000608@kodewerk.com>
	<194f62550901231141g59ac4e0fkb49ff56fbcbcc2a@mail.gmail.com>
Message-ID: <7470ab133171.4979b178@sun.com>


Depends on how heavy the load is and whether there are
convoying/synchronizing effects between the JVM's.
Typically this will manifest as large variance in the
scavenge times (or if you plot pause distributions
they will be at least bimodal and possibly combinatorially
multi-modal -- you will see a "ringing" tail).
I have seen this when customers do not pbind to psets
and load is heavy. If you use PrintGCStats/CompareGCStats
it'll show up as a larger "std-dev" reading.
When you are concerned about pause times (as Nick is)
the longer, fatter, ringing tail can hurt.

-- ramki

----- Original Message -----
From: Clemens Eisserer <linuxhippy at gmail.com>
Date: Friday, January 23, 2009 11:42 am
Subject: Re: Number of Parallel GC Threads
To: kirk <kirk at kodewerk.com>, hotspot-gc-dev at openjdk.java.net


> > I should add that I think that the bigger problem is that GC doesn't 
> play nice
> > when you have many VMs running on the same hardware.
> > (point taken about partitioning and all that).
> > Some how it has to figure out if it has free reign or if it need to 
> share.
> 
> In theory there are slowdowns when three or more JVMs run their GC at
> exactly the same time, but how often does that happen.
> Do you have any evidence that this is a problem in real-world useage?
> 
> - Clemens


From Jon.Masamitsu at Sun.COM  Fri Jan 23 13:12:25 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Fri, 23 Jan 2009 13:12:25 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <497A1853.4090508@kodewerk.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
	<497A1853.4090508@kodewerk.com>
Message-ID: <497A32B9.7080608@sun.com>

kirk wrote On 01/23/09 11:19,:

>Jon Masamitsu wrote:
>  
>
>>kirk wrote On 01/23/09 09:39,:
>>
>>  
>>    
>>
>>>...
>>>
>>>    
>>>      
>>>
>>>> 
>>>>   
>>>>
>>>>      
>>>>        
>>>>
>>>I've come into a couple of situations where I need to throttle back on 
>>>GC threads so I think the request to throttle based on the -Xmx setting 
>>>seem reasonable.
>>> 
>>>
>>>    
>>>      
>>>
>>How do you decide the number of GC threads given a maximum heap size?
>>Do you scale the number of GC threads linearly with the maximum
>>heap size?
>>
>>  
>>    
>>
>Good question. As Tony pointed out, there seems to be a useful number of 
>threads to allocate and so his formulation deviates from linear in cases 
>where there are a large number of CPUs. In this case I guess I would cap 
>at the min offered by that value and one determined by memory. I don't 
>have a good feeling for what that other formula would look like but a 
>good starting point could be something like 1 for something like every 
>64mb. The actual value could be adjusted using some observations about 
>how GC was behaving.
>  
>

So linear with the max size of the heap (e.g., 8 GC threads for a 512m
max heap)
up to some cap (e.g., using the 5/8's rule Tony described).

What do you mean by GC behavior?  And adjusting for it?



From Y.S.Ramakrishna at Sun.COM  Fri Jan 23 13:29:17 2009
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Fri, 23 Jan 2009 13:29:17 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <497A32B9.7080608@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
	<497A1853.4090508@kodewerk.com> <497A32B9.7080608@sun.com>
Message-ID: <74509f921d4c.4979c62d@sun.com>



> >Good question. As Tony pointed out, there seems to be a useful number 
> of 
> >threads to allocate and so his formulation deviates from linear in 
> cases 
> >where there are a large number of CPUs. In this case I guess I would 
> cap 
> >at the min offered by that value and one determined by memory. I 
> don't 
> >have a good feeling for what that other formula would look like but a 
> 
> >good starting point could be something like 1 for something like 
> every 
> >64mb. The actual value could be adjusted using some observations 
> about 
> >how GC was behaving.
> >  
> >
> 
> So linear with the max size of the heap (e.g., 8 GC threads for a 512m
> max heap)
> up to some cap (e.g., using the 5/8's rule Tony described).
> 
> What do you mean by GC behavior?  And adjusting for it?
> 

Not to answer the question for Kirk, but basically as Tony said
and we all agree, no single function form and coefficients we use
will work well for all applications and all workloads. I am
guessing what Kirk means here is some kind of dynamic learning
and readjustment of the coefficients (or in a model-free case
just using some kind of probing in the vicinity of the current
state (i.e. # gc threads) and based on whether that improved the
performance or not, either move in that direction or back --
basically some kind of reinforcement learning approach towards
finding -- and tracking -- an optimal value dynamically.
If that's what Kirk was getting at, I would expect any such
adjustment to happen slowly and for one to be extremely careful
in large ensembles of such JVMs to keep from getting into
oscillations/instability. I am sure (ok i am guessing)
control theorists have solved this ensemble control problem for simple
(homogeneous) cases, but i fear that it may be difficult to get right at
low cost in the kinds of (non-homogeneous, bursty) situations we would
expect to encounter.

Just some loud thinking ....
-- ramki


From kirk at kodewerk.com  Fri Jan 23 14:52:32 2009
From: kirk at kodewerk.com (kirk)
Date: Fri, 23 Jan 2009 23:52:32 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <194f62550901231141g59ac4e0fkb49ff56fbcbcc2a@mail.gmail.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>	
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>	
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>	
	<497A18DF.6000608@kodewerk.com>
	<194f62550901231141g59ac4e0fkb49ff56fbcbcc2a@mail.gmail.com>
Message-ID: <497A4A30.40202@kodewerk.com>

Clemens Eisserer wrote:
>> I should add that I think that the bigger problem is that GC doesn't play nice
>> when you have many VMs running on the same hardware.
>> (point taken about partitioning and all that).
>> Some how it has to figure out if it has free reign or if it need to share.
>>     
>
> In theory there are slowdowns when three or more JVMs run their GC at
> exactly the same time, but how often does that happen.
> Do you have any evidence that this is a problem in real-world useage?
>
> - Clemens
>
>   
Yes, I do have customers where the only way to solve the problem was to 
"de-tune" gc threads. Sorry NDA prevents me from saying a lot more 
though I can talk in generalities.

Regards,
Kirk


From kirk at kodewerk.com  Fri Jan 23 17:18:37 2009
From: kirk at kodewerk.com (kirk)
Date: Sat, 24 Jan 2009 02:18:37 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <74509f921d4c.4979c62d@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
	<497A1853.4090508@kodewerk.com> <497A32B9.7080608@sun.com>
	<74509f921d4c.4979c62d@sun.com>
Message-ID: <497A6C6D.7020209@kodewerk.com>

Y Srinivas Ramakrishna wrote:
>   
>>> Good question. As Tony pointed out, there seems to be a useful number 
>>>       
>> of 
>>     
>>> threads to allocate and so his formulation deviates from linear in 
>>>       
>> cases 
>>     
>>> where there are a large number of CPUs. In this case I guess I would 
>>>       
>> cap 
>>     
>>> at the min offered by that value and one determined by memory. I 
>>>       
>> don't 
>>     
>>> have a good feeling for what that other formula would look like but a 
>>>       
>>> good starting point could be something like 1 for something like 
>>>       
>> every 
>>     
>>> 64mb. The actual value could be adjusted using some observations 
>>>       
>> about 
>>     
>>> how GC was behaving.
>>>  
>>>
>>>       
>> So linear with the max size of the heap (e.g., 8 GC threads for a 512m
>> max heap)
>> up to some cap (e.g., using the 5/8's rule Tony described).
>>
>> What do you mean by GC behavior?  And adjusting for it?
>>
>>     
>
> Not to answer the question for Kirk, but basically as Tony said
> and we all agree, no single function form and coefficients we use
> will work well for all applications and all workloads. I am
> guessing what Kirk means here is some kind of dynamic learning
> and readjustment of the coefficients (or in a model-free case
> just using some kind of probing in the vicinity of the current
> state (i.e. # gc threads) and based on whether that improved the
> performance or not, either move in that direction or back --
> basically some kind of reinforcement learning approach towards
> finding -- and tracking -- an optimal value dynamically.
> If that's what Kirk was getting at, I would expect any such
> adjustment to happen slowly and for one to be extremely careful
> in large ensembles of such JVMs to keep from getting into
> oscillations/instability. I am sure (ok i am guessing)
> control theorists have solved this ensemble control problem for simple
> (homogeneous) cases, but i fear that it may be difficult to get right at
> low cost in the kinds of (non-homogeneous, bursty) situations we would
> expect to encounter.
>
> Just some loud thinking ....
>   
I didn't know I was so clever ;-)

I was thinking about this a bit but unless you understand what is going 
on with the competing JVMs.... I think that could be a bigger influence. 
At any rate, I'd consider this a gross optimiztion. Trying to fine tune 
it may not make sense.

Regards,
Kirk



From mail at nmichael.de  Sat Jan 24 06:40:58 2009
From: mail at nmichael.de (Nicolas Michael)
Date: Sat, 24 Jan 2009 15:40:58 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <497A6C6D.7020209@kodewerk.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>	<4979E365.7000207@sun.com>
	<4979E822.6060001@sun.com>	<497A00E1.4030105@kodewerk.com>
	<497A07E6.4070507@sun.com>	<497A1853.4090508@kodewerk.com>
	<497A32B9.7080608@sun.com>	<74509f921d4c.4979c62d@sun.com>
	<497A6C6D.7020209@kodewerk.com>
Message-ID: <497B287A.4060307@nmichael.de>

Hi,

I didn't expect to kick off that many emails! :-) So first of all: 
Thanks a lot! I'll try to reply to some of them in this "compound" mail.

I was referring to Java 1.6.0_07 (and some Java 5 builds): With these 
releases, we really *do* have 256 gc threads on our T5440! I didn't know 
that you had changed that in 1.6.0_10. Having "just" 80 gc threads with 
the 5/8 rule sounds already much better, but would still be overkill for 
an Xmx128m process (see below).

Tony wrote:
 > If someone is running several JVMs per box, then I assume that they
 > know what they are doing, so playing around with the # of parallel GC
 > threads should be straightforward to them!

Hmmm... I'll try to explain in a little more detail: You know our 
configuration, and that's exactly what we do: Without going into 
details, we configure the number of parallel gc threads over *all* our 
JVM's that are part of our workload such that they don't exceed the 
number of cpus. Works very well!

But that's just part of the story. Nowadays, you have lots of programs 
that are developed in Java. And you run such programs in the background 
on the same servers you run your workload on. Those programs are not 
necessarily part of your workload, but perform monitoring/administrative 
tasks in the background. They are often not developed by your own 
department, but either in other parts of your company or are coming from 
OEM partners. So you often don't have the possibility to change JVM 
settings for them. (I'm writing this in a very general fashion since 
this is a public list...)

As an example, take the management and supervision tools of Sun's 
StorageTek arrays (CAM software). There's this "Sun StorageTek Fault 
Management Services" process, running Java 1.5.0_11-b03 (of course, it's 
coming with its own JVM...).

$ jinfo 763
java.vm.version = 1.5.0_11-b03
java.vm.name = Java HotSpot(TM) Server VM
VM Flags:
-Xms8m -Xmx128m ...
...

Currently, this FM service agent has been doing 792 Young GC's within 3 
days (that's about once every 6 minutes) -- with 256 parallel gc threads:

$ pstack 763 | grep __1cMGCTaskThreadDrun6M_v_  | wc -l
      256

Clemens wrote:
 > It should be a rather rare case that two JVMs running run a gc-cycle
 > at the same time for which performance will be a bit worse

If a server runs during peak load at high cpu utilizations (there are 
applications that can do this even with 256 cpus in the server...), a 
256-threaded gc cycle of a monitoring agent could be quite disruptive 
for such a workload (especially when it is sensitive to response times).

I'm not saying that we *do* have a critical problem here (in my 
particular case). I was writing my first mail just to point out that in 
my opinion there are situations where JVM's are maybe using too many gc 
threads on large systems. Of course, I totally agree that it's difficult 
(if not even impossible) for the JVM to come up with best default 
settings for *any* imaginable situation. Usually the user will need to 
adjust some of the settings. In some case as I'm describing above, this 
is unfortunately not always possible: Afaik, there is no external 
interface to change the JVM settings for this CAM software agent. (Ok, 
we could consider this the fault of the agent, which could in a startup 
script detect how many cpus there are in the system, and limit its 
number of gc threads to let's say 4 (which should be sufficient for such 
a process with 128m heap). Or use the Client VM instead...) 
Unfortunately, I believe there are many programs around which fail to do 
such things...

Therefore I thought it might help if the JVM would limit the number of 
gc threads or large systems if it is likely that the process would not 
benefit from more gc threads. It's sure difficult to tell, but I've seen 
lots of ideas in these mails. 128m heap certainly don't need 256 gc 
threads (or 80 with the 5/8 rule). Btw, this CAM agent has 274 threads 
in total. Subtracting 256 gc threads leaves 18 threads. I don't know how 
many of them really do anything, but an application with < 18 mutator 
threads, a heap of 128m, minor gc intervals of 6 minutes certainly 
doesn't need many gc threads -- not even on a 256-way system... ;-) Of 
course, number of mutator threads and gc intervals are dynamic 
parameters and can't be determined by the JVM at startup.

Nick.


From Antonios.Printezis at sun.com  Sat Jan 24 14:13:09 2009
From: Antonios.Printezis at sun.com (Tony Printezis)
Date: Sat, 24 Jan 2009 17:13:09 -0500
Subject: Number of Parallel GC Threads
In-Reply-To: <497B287A.4060307@nmichael.de>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E365.7000207@sun.com> <4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com> <497A07E6.4070507@sun.com>
	<497A1853.4090508@kodewerk.com> <497A32B9.7080608@sun.com>
	<74509f921d4c.4979c62d@sun.com> <497A6C6D.7020209@kodewerk.com>
	<497B287A.4060307@nmichael.de>
Message-ID: <497B9275.8020007@sun.com>

Nick,

Hi. You do bring up, as always!!!, a good point. Maybe we can come up 
with some better defaults, but my guess would be that it might deal a 
bit better with a small percentage of cases, but it will not be the 
magic wand that will automagically solve all related issues. We have 
considered doing something like trying to monitor how many JVMs are 
running on a particular machine and increase / decrease the resources 
dedicated to each as needed. But that's not trivial and I don't think 
it's high on our list.

Regarding the CAM agent, you said correctly that they should somehow 
tune its parameters a bit better. And you are right; I would have 
reported it as a bug.

Tony

Nicolas Michael wrote:
> Hi,
>
> I didn't expect to kick off that many emails! :-) So first of all: 
> Thanks a lot! I'll try to reply to some of them in this "compound" mail.
>
> I was referring to Java 1.6.0_07 (and some Java 5 builds): With these 
> releases, we really *do* have 256 gc threads on our T5440! I didn't 
> know that you had changed that in 1.6.0_10. Having "just" 80 gc 
> threads with the 5/8 rule sounds already much better, but would still 
> be overkill for an Xmx128m process (see below).
>
> Tony wrote:
> > If someone is running several JVMs per box, then I assume that they
> > know what they are doing, so playing around with the # of parallel GC
> > threads should be straightforward to them!
>
> Hmmm... I'll try to explain in a little more detail: You know our 
> configuration, and that's exactly what we do: Without going into 
> details, we configure the number of parallel gc threads over *all* our 
> JVM's that are part of our workload such that they don't exceed the 
> number of cpus. Works very well!
>
> But that's just part of the story. Nowadays, you have lots of programs 
> that are developed in Java. And you run such programs in the 
> background on the same servers you run your workload on. Those 
> programs are not necessarily part of your workload, but perform 
> monitoring/administrative tasks in the background. They are often not 
> developed by your own department, but either in other parts of your 
> company or are coming from OEM partners. So you often don't have the 
> possibility to change JVM settings for them. (I'm writing this in a 
> very general fashion since this is a public list...)
>
> As an example, take the management and supervision tools of Sun's 
> StorageTek arrays (CAM software). There's this "Sun StorageTek Fault 
> Management Services" process, running Java 1.5.0_11-b03 (of course, 
> it's coming with its own JVM...).
>
> $ jinfo 763
> java.vm.version = 1.5.0_11-b03
> java.vm.name = Java HotSpot(TM) Server VM
> VM Flags:
> -Xms8m -Xmx128m ...
> ...
>
> Currently, this FM service agent has been doing 792 Young GC's within 
> 3 days (that's about once every 6 minutes) -- with 256 parallel gc 
> threads:
>
> $ pstack 763 | grep __1cMGCTaskThreadDrun6M_v_  | wc -l
>      256
>
> Clemens wrote:
> > It should be a rather rare case that two JVMs running run a gc-cycle
> > at the same time for which performance will be a bit worse
>
> If a server runs during peak load at high cpu utilizations (there are 
> applications that can do this even with 256 cpus in the server...), a 
> 256-threaded gc cycle of a monitoring agent could be quite disruptive 
> for such a workload (especially when it is sensitive to response times).
>
> I'm not saying that we *do* have a critical problem here (in my 
> particular case). I was writing my first mail just to point out that 
> in my opinion there are situations where JVM's are maybe using too 
> many gc threads on large systems. Of course, I totally agree that it's 
> difficult (if not even impossible) for the JVM to come up with best 
> default settings for *any* imaginable situation. Usually the user will 
> need to adjust some of the settings. In some case as I'm describing 
> above, this is unfortunately not always possible: Afaik, there is no 
> external interface to change the JVM settings for this CAM software 
> agent. (Ok, we could consider this the fault of the agent, which could 
> in a startup script detect how many cpus there are in the system, and 
> limit its number of gc threads to let's say 4 (which should be 
> sufficient for such a process with 128m heap). Or use the Client VM 
> instead...) Unfortunately, I believe there are many programs around 
> which fail to do such things...
>
> Therefore I thought it might help if the JVM would limit the number of 
> gc threads or large systems if it is likely that the process would not 
> benefit from more gc threads. It's sure difficult to tell, but I've 
> seen lots of ideas in these mails. 128m heap certainly don't need 256 
> gc threads (or 80 with the 5/8 rule). Btw, this CAM agent has 274 
> threads in total. Subtracting 256 gc threads leaves 18 threads. I 
> don't know how many of them really do anything, but an application 
> with < 18 mutator threads, a heap of 128m, minor gc intervals of 6 
> minutes certainly doesn't need many gc threads -- not even on a 
> 256-way system... ;-) Of course, number of mutator threads and gc 
> intervals are dynamic parameters and can't be determined by the JVM at 
> startup.
>
> Nick.

-- 
----------------------------------------------------------------------
| Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
|                                   | MS BUR02-311                   |
| e-mail: tony.printezis at sun.com    | 35 Network Drive               |
| office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
----------------------------------------------------------------------
e-mail client: Thunderbird (Solaris)




From martinrb at google.com  Sun Jan 25 14:53:58 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 25 Jan 2009 14:53:58 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <497B9275.8020007@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E822.6060001@sun.com> <497A00E1.4030105@kodewerk.com>
	<497A07E6.4070507@sun.com> <497A1853.4090508@kodewerk.com>
	<497A32B9.7080608@sun.com> <74509f921d4c.4979c62d@sun.com>
	<497A6C6D.7020209@kodewerk.com> <497B287A.4060307@nmichael.de>
	<497B9275.8020007@sun.com>
Message-ID: <1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>

On Sat, Jan 24, 2009 at 14:13, Tony Printezis <Antonios.Printezis at sun.com>wrote:

>
> Regarding the CAM agent, you said correctly that they should somehow tune
> its parameters a bit better. And you are right; I would have reported it as
> a bug.
>


It's hard to fault an application for using the defaults.
Tuning should only be necessary to achieve top performance,
not to achieve reasonable performance.
If an application ends up not being a good citizen as a result of
decisions made by  the JVM, that's  a bug in the JVM.

In general, JDK engineers think in terms of peak performance
in benchmark-like settings.  I've been guilty of that myself.
We should try harder to have reasonable performance without
unreasonable resource consumption, by default.
Relatively few apps are in the "take over the machine" category.
Those few apps should be required to ask for such status via
a JVM flag.

I like the GC work done in the past few years by Matthew Hertz,
with an emphasis on finding the right balance for resource use
(particularly memory) by GC, especially adaptively.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090125/55ee162b/attachment.html 

From Antonios.Printezis at sun.com  Mon Jan 26 07:12:28 2009
From: Antonios.Printezis at sun.com (Tony Printezis)
Date: Mon, 26 Jan 2009 10:12:28 -0500
Subject: Number of Parallel GC Threads
In-Reply-To: <1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E822.6060001@sun.com> <497A00E1.4030105@kodewerk.com>
	<497A07E6.4070507@sun.com> <497A1853.4090508@kodewerk.com>
	<497A32B9.7080608@sun.com> <74509f921d4c.4979c62d@sun.com>
	<497A6C6D.7020209@kodewerk.com> <497B287A.4060307@nmichael.de>
	<497B9275.8020007@sun.com>
	<1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
Message-ID: <497DD2DC.4030709@sun.com>

Martin,

Martin Buchholz wrote:
>
>
> On Sat, Jan 24, 2009 at 14:13, Tony Printezis 
> <Antonios.Printezis at sun.com <mailto:Antonios.Printezis at sun.com>> wrote:
>
>
>     Regarding the CAM agent, you said correctly that they should
>     somehow tune its parameters a bit better. And you are right; I
>     would have reported it as a bug.
>
>
>
> It's hard to fault an application for using the defaults. 
> Tuning should only be necessary to achieve top performance,
> not to achieve reasonable performance. 
> If an application ends up not being a good citizen as a result of 
> decisions made by  the JVM, that's  a bug in the JVM.
I don't think so. We need a reasonable balance between giving reasonable 
performance and being a good citizen. Once upon the time we tried to do 
what you are suggesting, i.e., trying to be a good citizen by default 
and requiring tuning for performance. And that was not a big success, as 
users kept complaining why our settings were too conservative, why they 
kept getting OOMs given the small heap, why performance was not the 
best, etc. So, we've been there, done that, it didn't work.
> In general, JDK engineers think in terms of peak performance
> in benchmark-like settings.  I've been guilty of that myself.
> We should try harder to have reasonable performance without
> unreasonable resource consumption, by default.
> Relatively few apps are in the "take over the machine" category.
> Those few apps should be required to ask for such status via
> a JVM flag.
>
> I like the GC work done in the past few years by Matthew Hertz,
> with an emphasis on finding the right balance for resource use
> (particularly memory) by GC, especially adaptively.
Even if we monitor what's happening in the machine and, say, start 
taking resource away from a JVM because the load of the machine is going 
up, we might get users asking why we're taking away resources from the 
"important" JVM in favor of not so important background processes. So I 
still insist: whatever we do, it will not work in some setting and we'll 
have folks complaining.

Tony

-- 
---------------------------------------------------------------------
| Tony Printezis, Staff Engineer   | Sun Microsystems Inc.          |
|                                  | MS UBUR02-311                  |
| e-mail: tony.printezis at sun.com   | 35 Network Drive               |
| office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA |
---------------------------------------------------------------------
e-mail client: Thunderbird (Linux)




From mail at nmichael.de  Mon Jan 26 12:26:18 2009
From: mail at nmichael.de (Nicolas Michael)
Date: Mon, 26 Jan 2009 21:26:18 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <497DD2DC.4030709@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>	<4979E822.6060001@sun.com>
	<497A00E1.4030105@kodewerk.com>	<497A07E6.4070507@sun.com>
	<497A1853.4090508@kodewerk.com>	<497A32B9.7080608@sun.com>
	<74509f921d4c.4979c62d@sun.com>	<497A6C6D.7020209@kodewerk.com>
	<497B287A.4060307@nmichael.de>	<497B9275.8020007@sun.com>	<1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
	<497DD2DC.4030709@sun.com>
Message-ID: <497E1C6A.5030601@nmichael.de>

Hi Tony,

Tony Printezis schrieb:

> Even if we monitor what's happening in the machine and, say, start 
> taking resource away from a JVM because the load of the machine is going 
> up, we might get users asking why we're taking away resources from the 
> "important" JVM in favor of not so important background processes. So I 
> still insist: whatever we do, it will not work in some setting and we'll 
> have folks complaining.

I absolutely agree with you: Such "dynamic" optimizations have a high 
potential of going into the wrong direction. And what I dislike even 
more about them: They make system behavior very difficult to predict. 
When you look at your system, you may find everything working just fine. 
Then you probably have one application going nuts, and suddenly all 
JVM's start adapting their resources. Or you start another JVM (let's 
say, the Sun Studio Analyzer), and suddenly your work-load JVM's reduce 
their GC threads... I wouldn't want to be the poor guy who would have to 
analyze after such a situation what has happened when a customer is 
complaining about a weird system behavior. Or make performance 
predictions when I don't know which strange situations may make the JVM 
to rethink its settings. I'm just imagining a situation where the server 
hits overload because of a burst of incoming requests, and the JVM's 
think "Oh, there's so much load on the server, let's reduce our resource 
usage and kill some of them gc threads." -- and afterwards suffer from 
longer gc pauses which makes it even more difficult for them to keep up 
with the load.

On the other hand, there may be some better default settings that the 
JVM could derive from some "static" parameters. I believe Martin is 
right that most apps are not in the "take over the machine" category, 
especially when it comes to really large servers. Are there really 
people who run just one JVM instance on a 64/128/256 cpu CMT server for 
example?? And even if they do, they certainly have lots of mutator 
threads (otherwise it wouldn't make sense to run just one JVM on such a 
server), so they would have lots of object creation and would need quite 
a large heap for a reasonable operation.

Those "agent" processes that I was referring to (CAM just being one of 
them) are rather "small" processes (128m heap in case of the CAM agent). 
And I would assume that most of those "performance-uncritical background 
processes" that you might run on large servers come with small heaps (I 
sure hope -- I don't want them to use up my memory!). And even 
performance-hungry apps with small heaps don't need too many gc threads 
(and if they are really performance-hungry *and* have small heaps *and* 
run on very large servers, they are likely to be deployed in more than 
one instance... if they run single-instance, they should need *large* 
heaps). So it should be possible for the JVM to come up with an upper 
limit for the number of gc threads depending on the server size (cpus, 
memory) and max heap size of the application. Probably there are even 
other or better indications that I currently don't think of. And 
probably there's more than just the number of gc threads that could be 
sized that way...?


That's all for now, and sorry for my long mails... ;-)

Thanks,
Nick.


From fw at deneb.enyo.de  Mon Jan 26 13:33:16 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 26 Jan 2009 22:33:16 +0100
Subject: Number of Parallel GC Threads
In-Reply-To: <1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
	(Martin Buchholz's message of "Sun, 25 Jan 2009 14:53:58 -0800")
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E822.6060001@sun.com> <497A00E1.4030105@kodewerk.com>
	<497A07E6.4070507@sun.com> <497A1853.4090508@kodewerk.com>
	<497A32B9.7080608@sun.com> <74509f921d4c.4979c62d@sun.com>
	<497A6C6D.7020209@kodewerk.com> <497B287A.4060307@nmichael.de>
	<497B9275.8020007@sun.com>
	<1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
Message-ID: <871vupu50j.fsf@mid.deneb.enyo.de>

* Martin Buchholz:

> In general, JDK engineers think in terms of peak performance
> in benchmark-like settings.  I've been guilty of that myself.
> We should try harder to have reasonable performance without
> unreasonable resource consumption, by default.

I would be happy to have some sort of system daemon mode, which
minimizes footprint while maintaining relatively decent performance
(for things like the occasional TLS handshake).  I think most such
applications wouldn't even need dynamic tuning.

Right now, I fear that I need to put all these system management tasks
into a single VM (MVM-style) because it seems that without lots of
tuning, separate VMs would consume too much resources on some of our
smaller hosts.  (Of course, this is a psychological issue to some
extent, and it's note very likely that the code actually exists before
those machines are phased out. 8-/)


From Y.S.Ramakrishna at Sun.COM  Mon Jan 26 13:37:27 2009
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Mon, 26 Jan 2009 13:37:27 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <871vupu50j.fsf@mid.deneb.enyo.de>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<4979E822.6060001@sun.com> <497A00E1.4030105@kodewerk.com>
	<497A07E6.4070507@sun.com> <497A1853.4090508@kodewerk.com>
	<497A32B9.7080608@sun.com> <74509f921d4c.4979c62d@sun.com>
	<497A6C6D.7020209@kodewerk.com> <497B287A.4060307@nmichael.de>
	<497B9275.8020007@sun.com>
	<1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
	<871vupu50j.fsf@mid.deneb.enyo.de>
Message-ID: <7470f7403d87.497dbc97@sun.com>


As Jon pointed out towards the start of this thread
"-client" may be considered the less resource-hungry
mode that you are looking for below (or at least a close
enough approximation for now).

-- ramki

----- Original Message -----
From: Florian Weimer <fw at deneb.enyo.de>
Date: Monday, January 26, 2009 1:33 pm
Subject: Re: Number of Parallel GC Threads
To: Martin Buchholz <martinrb at google.com>
Cc: hotspot-gc-dev at openjdk.java.net, Tony Printezis <Antonios.Printezis at Sun.COM>


> * Martin Buchholz:
> 
> > In general, JDK engineers think in terms of peak performance
> > in benchmark-like settings.  I've been guilty of that myself.
> > We should try harder to have reasonable performance without
> > unreasonable resource consumption, by default.
> 
> I would be happy to have some sort of system daemon mode, which
> minimizes footprint while maintaining relatively decent performance
> (for things like the occasional TLS handshake).  I think most such
> applications wouldn't even need dynamic tuning.
> 
> Right now, I fear that I need to put all these system management tasks
> into a single VM (MVM-style) because it seems that without lots of
> tuning, separate VMs would consume too much resources on some of our
> smaller hosts.  (Of course, this is a psychological issue to some
> extent, and it's note very likely that the code actually exists before
> those machines are phased out. 8-/)


From martinrb at google.com  Mon Jan 26 14:31:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 26 Jan 2009 14:31:44 -0800
Subject: Number of Parallel GC Threads
In-Reply-To: <497DD2DC.4030709@sun.com>
References: <E1LQGQv-000KbT-Nd@waikiki.ops.eusc.inter.net>
	<497A07E6.4070507@sun.com> <497A1853.4090508@kodewerk.com>
	<497A32B9.7080608@sun.com> <74509f921d4c.4979c62d@sun.com>
	<497A6C6D.7020209@kodewerk.com> <497B287A.4060307@nmichael.de>
	<497B9275.8020007@sun.com>
	<1ccfd1c10901251453r18de9c06jc277edeb19df9876@mail.gmail.com>
	<497DD2DC.4030709@sun.com>
Message-ID: <1ccfd1c10901261431v3033eb53xbc4679da84fd9b33@mail.gmail.com>

On Mon, Jan 26, 2009 at 07:12, Tony Printezis <Antonios.Printezis at sun.com>wrote:

>
>> It's hard to fault an application for using the defaults. Tuning should
>> only be necessary to achieve top performance,
>> not to achieve reasonable performance. If an application ends up not being
>> a good citizen as a result of decisions made by  the JVM, that's  a bug in
>> the JVM.
>>
> I don't think so. We need a reasonable balance between giving reasonable
> performance and being a good citizen. Once upon the time we tried to do what
> you are suggesting, i.e., trying to be a good citizen by default and
> requiring tuning for performance. And that was not a big success, as users
> kept complaining why our settings were too conservative, why they kept
> getting OOMs given the small heap, why performance was not the best, etc.
> So, we've been there, done that, it didn't work.


Being a good citizen does not include failing due to OOME.

Being a good citizen, to me, means things like:
- gc'ing when the heap has grown from previous collection by a factor of
2-3,
  instead of a factor of 20
- using 5 concurrent gc threads instead of 100

In general, don't double resource consumption to get an additional 1%
performance,
by default.

I agree with Tony that customers are going to have
a harder time managing applications the more dynamic
that resource management becomes.
But I think this comes with the territory.
It is much harder to do performance measurement
of Java code in general, because the execution model
with multiple runtimes has become so complex and dynamic.
But that's called progress.  We should be aiming all parts of
our runtimes to be more dynamic in the same way.
Lots of difficult work remaining to be done by VM engineers.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090126/c02ef808/attachment.html 

From y.s.ramakrishna at sun.com  Mon Jan 26 20:43:46 2009
From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com)
Date: Tue, 27 Jan 2009 04:43:46 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6786503: Overflow list performance can
	be improved
Message-ID: <20090127044351.A83A5E1FA@hg.openjdk.java.net>

Changeset: 5cfd8d19e546
Author:    ysr
Date:      2009-01-26 12:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5cfd8d19e546

6786503: Overflow list performance can be improved
Summary: Avoid overflow list walk in CMS & ParNew when it is unnecessary. Fix a couple of correctness issues, including a C-heap leak, in ParNew at the intersection of promotion failure, work queue overflow and object array chunking. Add stress testing option and related assertion checking.
Reviewed-by: jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/includeDB_gc_parNew
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/runtime/globals.hpp



From igor.veresov at sun.com  Tue Jan 27 21:20:08 2009
From: igor.veresov at sun.com (igor.veresov at sun.com)
Date: Wed, 28 Jan 2009 05:20:08 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6783381: NUMA allocator: don't pretouch
	eden space with UseNUMA
Message-ID: <20090128052011.230ABE340@hg.openjdk.java.net>

Changeset: 4e400c36026f
Author:    iveresov
Date:      2009-01-27 18:13 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4e400c36026f

6783381: NUMA allocator: don't pretouch eden space with UseNUMA
Summary: Moved pretouching to MutableSpace. Also MutableSpace now turns on page interleaving for the region it covers.
Reviewed-by: jmasa, jcoomes

! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp
! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp
! src/share/vm/gc_implementation/shared/mutableSpace.cpp
! src/share/vm/gc_implementation/shared/mutableSpace.hpp



From shane.cox at gmail.com  Wed Jan 28 10:02:24 2009
From: shane.cox at gmail.com (Shane Cox)
Date: Wed, 28 Jan 2009 13:02:24 -0500
Subject: help with Adaptive Sizing Policy
Message-ID: <dc6011320901281002q5084344eo24ab58faa9833941@mail.gmail.com>

I would like to preface this inquiry with the disclaimer that I'm
asking a question on behalf of another person (the application owner)
who has provided me with incomplete info/data.

To my knowledge, these are the only runtime parameters specified:
JBOSS_HOME: /var/opt/jboss-eap-4.3
JAVA: /usr/jdk/instances/jdk1.6.0//bin/java
JAVA_OPTS: -Dprogram.name=run.sh -server -verbose:gc
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails
-XX:+PrintTenuringDistribution
-Xloggc:/var/opt/jboss-eap-4.3/server/webotc.thice.com/log/verboseGC.log
-agentlib:yjpagent=port=3580,usedmem=90,dir=/var/opt/jboss-eap-4.3/server/webotc.theice.com/log
 -d64 -Xmx1024m -Xms1024m -XX:MaxPermSize=128m -XX:+UseParallelGC
CLASSPATH: /var/opt/jboss-eap-4.3/bin/run.jar:/usr/jdk/instances/jdk1.6.0//lib/tools.jar

The application is hosted on a 4 processor Dell server running x86
Solaris 10.  The Java version is 1.6, build 07.

Attached, please find a poorly formatted excerpt from a gc log which,
to me, appears to have be the output of a grep.


These are my questions:
1)  Since -Xmx and -Xms are both set to 1024m, shouldn't adaptive
sizing be turned OFF?  Based on the GC log, it appears that the VM is
resizing the YoungSpace between collections.

2)  Somewhere around line 35 of this file, the YoungSpace allocation
decreases from approx 300MB to 171MB.  This occurs at a time when the
VM appears to be extremely low on space.  Why would the allocation of
YoungSpace, and therefore the VM's total Heap, decrease at a time when
almost all available space is occupied?  In fact, it appears that the
VM is on the verge of an OutOfMemoryException, yet the Heap allocation
(Young + Old) is only 871936K, whereas the max allowable should be
1GB.  Clearly there is a dynamic at play that I'm not aware of.

3)  Last, why would PermSpace allocation and occupancy grow over time?
 I know very little about the classloader, and therefore have no idea
when the decision is made to load a class ... though I presume most
are loaded on startup for the server VM.


Any help/insight would be appreciated and again, apologies for the
limited and poor quality of the logs.

Shane
-------------- next part --------------
] [Times: user=3.25 sys=0.00, real=3.25 secs] 
 [PSYoungGen: 298176K->20389K(321792K)] 795775K->517989K(1022208K), 0.1824475 secs] [Times: user=0.25 sys=0.00, real=0.18 secs] 
 [PSYoungGen: 315069K->10962K(322880K)] 812669K->525659K(1023296K), 0.1836846 secs] [Times: user=0.25 sys=0.00, real=0.18 secs] 
 [PSYoungGen: 306514K->23473K(319232K)] 821211K->544804K(1019648K), 0.1910273 secs] [Times: user=0.27 sys=0.00, real=0.19 secs] 
 [PSYoungGen: 315953K->20347K(312832K)] 837284K->547397K(1013248K), 0.1891748 secs] [Times: user=0.27 sys=0.00, real=0.19 secs] 
 [PSYoungGen: 312827K->13169K(321728K)] 839877K->551431K(1022144K), 0.1825135 secs] [Times: user=0.25 sys=0.00, real=0.18 secs] 
 [PSYoungGen: 305521K->12456K(320832K)] 843783K->561405K(1021248K), 0.1747306 secs] [Times: user=0.23 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 304808K->10245K(322880K)] 853757K->566098K(1023296K), 0.1674873 secs] [Times: user=0.21 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 305413K->16848K(322496K)] 861266K->576910K(1022912K), 0.1774588 secs] [Times: user=0.24 sys=0.00, real=0.18 secs] 
 [PSYoungGen: 312016K->13170K(324224K)] 872078K->584262K(1024640K), 0.1725367 secs] [Times: user=0.24 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 310578K->10899K(323392K)] 881670K->589932K(1023808K), 0.1721549 secs] [Times: user=0.23 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 308307K->7277K(324544K)] 887340K->596509K(1024960K), 0.1715460 secs] [Times: user=0.22 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 306285K->16389K(324608K)] 895517K->609187K(1025024K), 0.1692925 secs] [Times: user=0.22 sys=0.00, real=0.17 secs] 
14730.512: [GC-- [PSYoungGen: 315397K->315397K(324608K)] 908195K->1015807K(1025024K), 1.3764310 secs] [Times: user=1.44 sys=1.57, real=1.38 secs] 
14731.889: [Full GC [PSYoungGen: 315397K->4403K(324608K)] [PSOldGen: 700410K->700415K(700416K)] 1015807K->704819K(1025024K) [PSPermGen: 59242K->59242K(102400K)], 4.6745559 secs] [Times: user=4.65 sys=0.01, real=4.67 secs] 
14738.066: [Full GC [PSYoungGen: 299008K->177609K(324608K)] [PSOldGen: 700415K->700415K(700416K)] 999423K->878025K(1025024K) [PSPermGen: 59245K->59245K(98304K)], 4.7579768 secs] [Times: user=4.74 sys=0.01, real=4.76 secs] 
14746.141: [Full GC [PSYoungGen: 299008K->0K(324608K)] [PSOldGen: 700415K->523065K(700416K)] 999423K->523065K(1025024K) [PSPermGen: 59246K->59228K(94208K)], 5.0396459 secs] [Times: user=5.03 sys=0.01, real=5.04 secs] 
 [PSYoungGen: 299008K->17733K(324288K)] 822073K->540799K(1024704K), 0.1673576 secs] [Times: user=0.23 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 316613K->23099K(321984K)] 839679K->546165K(1022400K), 0.1786317 secs] [Times: user=0.23 sys=0.00, real=0.18 secs] 
 [PSYoungGen: 321612K->27773K(310912K)] 844678K->557159K(1011328K), 0.1866544 secs] [Times: user=0.27 sys=0.00, real=0.19 secs] 
 [PSYoungGen: 310909K->33529K(316672K)] 840295K->631197K(1017088K), 0.2881300 secs] [Times: user=0.60 sys=0.00, real=0.29 secs] 
14870.894: [GC-- [PSYoungGen: 316665K->316665K(316672K)] 914333K->1017081K(1017088K), 1.2390496 secs] [Times: user=1.50 sys=1.59, real=1.24 secs] 
14872.133: [Full GC [PSYoungGen: 316665K->75198K(316672K)] [PSOldGen: 700415K->700415K(700416K)] 1017081K->775614K(1017088K) [PSPermGen: 59238K->59238K(90112K)], 4.8353155 secs] [Times: user=4.81 sys=0.01, real=4.84 secs] 
14877.943: [Full GC [PSYoungGen: 283136K->181825K(316672K)] [PSOldGen: 700415K->700415K(700416K)] 983551K->882241K(1017088K) [PSPermGen: 59239K->59239K(88064K)], 5.4002260 secs] [Times: user=5.36 sys=0.00, real=5.40 secs] 
 [PSYoungGen: 283136K->0K(316672K)] [PSOldGen: 700415K->575471K(700416K)] 983551K->575471K(1017088K) [PSPermGen: 59248K->59248K(83968K)], 3.5870902 secs] [Times: user=3.53 sys=0.00, real=3.59 secs] 
 [PSYoungGen: 283136K->15035K(261248K)] 858607K->590507K(961664K), 0.1693287 secs] [Times: user=0.22 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 242747K->17026K(288960K)] 818219K->592498K(989376K), 0.1717620 secs] [Times: user=0.23 sys=0.00, real=0.17 secs] 
 [PSYoungGen: 244738K->22103K(294592K)] 820210K->597575K(995008K), 0.1777377 secs] [Times: user=0.25 sys=0.00, real=0.18 secs] 
 [PSYoungGen: 257815K->29975K(291328K)] 833287K->605447K(991744K), 0.1899035 secs] [Times: user=0.27 sys=0.00, real=0.19 secs] 
 [PSYoungGen: 265687K->27620K(297216K)] 841159K->603091K(997632K), 0.1870630 secs] [Times: user=0.26 sys=0.00, real=0.19 secs] 
 [PSYoungGen: 270052K->52971K(295424K)] 845523K->703443K(995840K), 0.3134323 secs] [Times: user=0.74 sys=0.00, real=0.31 secs] 
15098.601: [Full GC [PSYoungGen: 52971K->0K(295424K)] [PSOldGen: 650471K->605025K(700416K)] 703443K->605025K(995840K) [PSPermGen: 59274K->59261K(79872K)], 4.8489219 secs] [Times: user=4.76 sys=0.01, real=4.85 secs] 
 [PSYoungGen: 242432K->54769K(171520K)] 847457K->733795K(871936K), 0.3193630 secs] [Times: user=0.76 sys=0.00, real=0.32 secs] 
15105.097: [Full GC [PSYoungGen: 54769K->33259K(171520K)] [PSOldGen: 679025K->700415K(700416K)] 733795K->733675K(871936K) [PSPermGen: 59261K->59261K(77824K)], 3.8685338 secs] [Times: user=3.86 sys=0.01, real=3.87 secs] 
15109.400: [Full GC [PSYoungGen: 116736K->67611K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->768027K(871936K) [PSPermGen: 59261K->59261K(75776K)], 3.9220545 secs] [Times: user=3.91 sys=0.01, real=3.92 secs] 
15113.709: [Full GC [PSYoungGen: 116736K->81894K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->782310K(871936K) [PSPermGen: 59261K->59261K(73728K)], 3.9854650 secs] [Times: user=3.98 sys=0.00, real=3.99 secs] 
15118.090: [Full GC [PSYoungGen: 116736K->90333K(171520K)] [PSOldGen: 700415K->700416K(700416K)] 817151K->790749K(871936K) [PSPermGen: 59261K->59261K(71680K)], 5.6391899 secs] [Times: user=5.56 sys=0.00, real=5.64 secs] 
15124.103: [Full GC [PSYoungGen: 116736K->109904K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->810320K(871936K) [PSPermGen: 59261K->59261K(69632K)], 4.2258024 secs] [Times: user=4.09 sys=0.00, real=4.23 secs] 
15128.613: [Full GC [PSYoungGen: 116736K->112517K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->812933K(871936K) [PSPermGen: 59261K->59261K(67584K)], 4.0214130 secs] [Times: user=4.01 sys=0.00, real=4.02 secs] 
15132.910: [Full GC [PSYoungGen: 115776K->113601K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 816192K->814017K(871936K) [PSPermGen: 59261K->59261K(67584K)], 4.0069786 secs] [Times: user=3.99 sys=0.01, real=4.01 secs] 
15137.186: [Full GC [PSYoungGen: 116736K->106672K(171520K)] [PSOldGen: 700416K->700415K(700416K)] 817152K->807088K(871936K) [PSPermGen: 59261K->59259K(65536K)], 5.6996949 secs] [Times: user=5.69 sys=0.01, real=5.70 secs] 
15143.170: [Full GC [PSYoungGen: 116507K->114951K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 816923K->815367K(871936K) [PSPermGen: 59259K->59259K(65536K)], 3.9350693 secs] [Times: user=3.93 sys=0.00, real=3.94 secs] 
15147.368: [Full GC [PSYoungGen: 116274K->113196K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 816690K->813612K(871936K) [PSPermGen: 59259K->59259K(63488K)], 4.0219157 secs] [Times: user=3.98 sys=0.00, real=4.02 secs] 
15151.657: [Full GC [PSYoungGen: 116736K->115167K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->815583K(871936K) [PSPermGen: 59259K->59259K(63488K)], 3.9680560 secs] [Times: user=3.96 sys=0.01, real=3.97 secs] 
15155.893: [Full GC [PSYoungGen: 116736K->108736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->809152K(871936K) [PSPermGen: 59259K->59259K(63488K)], 5.0729809 secs] [Times: user=5.06 sys=0.00, real=5.07 secs] 
15161.257: [Full GC [PSYoungGen: 116736K->114782K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->815198K(871936K) [PSPermGen: 59259K->59259K(63488K)], 3.9928835 secs] [Times: user=3.99 sys=0.00, real=3.99 secs] 
15165.535: [Full GC [PSYoungGen: 116736K->115805K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816221K(871936K) [PSPermGen: 59259K->59259K(61440K)], 3.9805049 secs] [Times: user=3.97 sys=0.01, real=3.98 secs] 
15169.782: [Full GC [PSYoungGen: 116736K->116237K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816653K(871936K) [PSPermGen: 59259K->59259K(61440K)], 3.9738937 secs] [Times: user=3.96 sys=0.00, real=3.97 secs] 
15174.023: [Full GC [PSYoungGen: 116735K->110313K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->810729K(871936K) [PSPermGen: 59259K->59259K(61440K)], 5.0955167 secs] [Times: user=5.07 sys=0.00, real=5.10 secs] 
15179.403: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59259K->59259K(61440K)], 3.9747766 secs] [Times: user=3.94 sys=0.00, real=3.97 secs] 
 [PSYoungGen: 116736K->112601K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->813017K(871936K) [PSPermGen: 59259K->59248K(61440K)], 6.6887692 secs] [Times: user=6.66 sys=0.01, real=6.69 secs] 
15190.396: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59248K->59248K(61440K)], 4.1210265 secs] [Times: user=4.05 sys=0.01, real=4.12 secs] 
15194.517: [Full GC [PSYoungGen: 116736K->112284K(171520K)] [PSOldGen: 700415K->700416K(700416K)] 817151K->812700K(871936K) [PSPermGen: 59248K->59248K(61440K)], 6.8098327 secs] [Times: user=6.77 sys=0.00, real=6.81 secs] 
15201.647: [Full GC [PSYoungGen: 116060K->116060K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 816476K->816476K(871936K) [PSPermGen: 59248K->59248K(61440K)], 3.9731262 secs] [Times: user=3.96 sys=0.00, real=3.97 secs] 
15205.620: [Full GC [PSYoungGen: 116060K->111169K(171520K)] [PSOldGen: 700416K->700415K(700416K)] 816476K->811585K(871936K) [PSPermGen: 59248K->59248K(61440K)], 6.7717103 secs] [Times: user=6.73 sys=0.01, real=6.77 secs] 
15212.716: [Full GC [PSYoungGen: 116698K->116698K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817114K->817114K(871936K) [PSPermGen: 59248K->59248K(61440K)], 4.0204048 secs] [Times: user=4.00 sys=0.01, real=4.02 secs] 
15216.737: [Full GC [PSYoungGen: 116698K->112819K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817114K->813235K(871936K) [PSPermGen: 59248K->59248K(61440K)], 5.7119179 secs] [Times: user=5.70 sys=0.00, real=5.71 secs] 
15222.722: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59248K->59248K(61440K)], 3.9991435 secs] [Times: user=3.98 sys=0.00, real=4.00 secs] 
15226.722: [Full GC [PSYoungGen: 116736K->112411K(171520K)] [PSOldGen: 700415K->700416K(700416K)] 817151K->812827K(871936K) [PSPermGen: 59248K->59248K(61440K)], 6.1962084 secs] [Times: user=6.16 sys=0.01, real=6.20 secs] 
15233.245: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59248K->59248K(61440K)], 4.0103510 secs] [Times: user=4.00 sys=0.00, real=4.01 secs] 
15237.256: [Full GC [PSYoungGen: 116736K->114606K(171520K)] [PSOldGen: 700416K->700415K(700416K)] 817152K->815022K(871936K) [PSPermGen: 59248K->59248K(59392K)], 5.7794189 secs] [Times: user=5.74 sys=0.01, real=5.78 secs] 
15243.311: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59248K->59248K(59392K)], 3.9989372 secs] [Times: user=3.96 sys=0.00, real=4.00 secs] 
15247.310: [Full GC [PSYoungGen: 116736K->116138K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816554K(871936K) [PSPermGen: 59248K->59248K(59392K)], 5.7380927 secs] [Times: user=5.70 sys=0.01, real=5.74 secs] 
15253.309: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 3.9843501 secs] [Times: user=3.95 sys=0.00, real=3.98 secs] 
15257.293: [Full GC [PSYoungGen: 116736K->116053K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816469K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.8456282 secs] [Times: user=4.83 sys=0.01, real=4.85 secs] 
15262.406: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 3.9992648 secs] [Times: user=3.96 sys=0.01, real=4.00 secs] 
15266.406: [Full GC [PSYoungGen: 116736K->115015K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->815431K(871936K) [PSPermGen: 59249K->59249K(59392K)], 5.2393804 secs] [Times: user=5.22 sys=0.00, real=5.24 secs] 
15271.912: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.1223198 secs] [Times: user=4.08 sys=0.01, real=4.12 secs] 
15276.035: [Full GC [PSYoungGen: 116736K->116397K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816813K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.3368821 secs] [Times: user=4.28 sys=0.00, real=4.34 secs] 
15280.633: [Full GC [PSYoungGen: 116695K->116695K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817111K->817111K(871936K) [PSPermGen: 59249K->59249K(59392K)], 3.9827842 secs] [Times: user=3.97 sys=0.01, real=3.98 secs] 
15284.616: [Full GC [PSYoungGen: 116695K->116469K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817111K->816885K(871936K) [PSPermGen: 59249K->59249K(59392K)], 5.7614345 secs] [Times: user=5.75 sys=0.00, real=5.76 secs] 
15290.641: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 3.9997900 secs] [Times: user=3.99 sys=0.01, real=4.00 secs] 
15294.641: [Full GC [PSYoungGen: 116736K->116521K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816937K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.8554103 secs] [Times: user=4.84 sys=0.00, real=4.86 secs] 
15299.769: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.0103872 secs] [Times: user=4.00 sys=0.01, real=4.01 secs] 
15303.780: [Full GC [PSYoungGen: 116736K->116563K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816979K(871936K) [PSPermGen: 59249K->59249K(59392K)], 5.7268007 secs] [Times: user=5.70 sys=0.00, real=5.73 secs] 
15309.767: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 3.9853614 secs] [Times: user=3.96 sys=0.01, real=3.99 secs] 
15313.753: [Full GC [PSYoungGen: 116736K->116611K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817027K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.0749571 secs] [Times: user=4.06 sys=0.00, real=4.08 secs] 
15318.096: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 3.9974540 secs] [Times: user=3.99 sys=0.01, real=4.00 secs] 
15322.355: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.0264841 secs] [Times: user=3.97 sys=0.00, real=4.03 secs] 
15326.382: [Full GC [PSYoungGen: 116736K->116612K(171520K)] [PSOldGen: 700415K->700416K(700416K)] 817151K->817028K(871936K) [PSPermGen: 59249K->59249K(59392K)], 6.7524254 secs] [Times: user=6.73 sys=0.01, real=6.75 secs] 
15355.939: [Full GC [PSYoungGen: 116736K->116497K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->816913K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.3769198 secs] [Times: user=4.36 sys=0.00, real=4.38 secs] 
15360.583: [Full GC [PSYoungGen: 116683K->116683K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817099K->817099K(871936K) [PSPermGen: 59249K->59249K(59392K)], 4.0681272 secs] [Times: user=4.02 sys=0.01, real=4.07 secs] 
15364.651: [Full GC [PSYoungGen: 116683K->115440K(171520K)] [PSOldGen: 700416K->700415K(700416K)] 817099K->815856K(871936K) [PSPermGen: 59249K->59249K(59392K)], 5.8008390 secs] [Times: user=5.76 sys=0.00, real=5.80 secs] 
15370.722: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59250K->59250K(59392K)], 4.0559837 secs] [Times: user=3.99 sys=0.01, real=4.06 secs] 
15374.779: [Full GC [PSYoungGen: 116736K->115865K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816280K(871936K) [PSPermGen: 59250K->59250K(59392K)], 4.0573834 secs] [Times: user=4.04 sys=0.00, real=4.06 secs] 
15379.103: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59255K->59255K(59392K)], 3.9883488 secs] [Times: user=3.97 sys=0.00, real=3.99 secs] 
15383.092: [Full GC [PSYoungGen: 116736K->115795K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816211K(871936K) [PSPermGen: 59255K->59255K(59392K)], 6.2084830 secs] [Times: user=6.19 sys=0.01, real=6.21 secs] 
15389.619: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59255K->59255K(59392K)], 4.0209462 secs] [Times: user=4.00 sys=0.01, real=4.02 secs] 
15393.906: [Full GC [PSYoungGen: 116736K->114578K(171520K)] [PSOldGen: 700416K->700415K(700416K)] 817152K->814994K(871936K) [PSPermGen: 59255K->59251K(59392K)], 6.8336956 secs] [Times: user=6.79 sys=0.01, real=6.83 secs] 
15401.057: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59252K->59252K(59392K)], 3.9714759 secs] [Times: user=3.96 sys=0.00, real=3.97 secs] 
15405.294: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59252K->59252K(59392K)], 4.0138218 secs] [Times: user=4.00 sys=0.01, real=4.01 secs] 
15409.574: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59252K->59252K(59392K)], 4.0259992 secs] [Times: user=3.98 sys=0.00, real=4.03 secs] 
15413.601: [Full GC [PSYoungGen: 116736K->114786K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->815202K(871936K) [PSPermGen: 59252K->59252K(59392K)], 5.7757666 secs] [Times: user=5.76 sys=0.01, real=5.78 secs] 
15419.645: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59252K->59252K(59392K)], 3.9996142 secs] [Times: user=3.99 sys=0.01, real=4.00 secs] 
15423.644: [Full GC [PSYoungGen: 116736K->115065K(171520K)] [PSOldGen: 700415K->700416K(700416K)] 817151K->815481K(871936K) [PSPermGen: 59252K->59252K(59392K)], 6.2203656 secs] [Times: user=6.19 sys=0.01, real=6.22 secs] 
15430.176: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59252K->59252K(59392K)], 4.0173540 secs] [Times: user=4.00 sys=0.00, real=4.02 secs] 
15434.194: [Full GC [PSYoungGen: 116736K->115075K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->815491K(871936K) [PSPermGen: 59252K->59252K(59392K)], 6.1576664 secs] [Times: user=6.13 sys=0.01, real=6.16 secs] 
15440.655: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59252K->59252K(59392K)], 4.0512073 secs] [Times: user=4.00 sys=0.01, real=4.05 secs] 
15444.707: [Full GC [PSYoungGen: 116736K->115767K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->816183K(871936K) [PSPermGen: 59252K->59252K(59392K)], 4.0245966 secs] [Times: user=4.02 sys=0.00, real=4.02 secs] 
15449.005: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59252K->59252K(59392K)], 4.0293786 secs] [Times: user=4.01 sys=0.01, real=4.03 secs] 
15453.035: [Full GC [PSYoungGen: 116736K->116132K(171520K)] [PSOldGen: 700416K->700415K(700416K)] 817152K->816548K(871936K) [PSPermGen: 59252K->59252K(59392K)], 5.8855080 secs] [Times: user=5.86 sys=0.00, real=5.89 secs] 
15459.215: [Full GC [PSYoungGen: 116735K->116735K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59252K->59252K(59392K)], 3.9864389 secs] [Times: user=3.98 sys=0.01, real=3.99 secs] 
15463.202: [Full GC [PSYoungGen: 116735K->116208K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816624K(871936K) [PSPermGen: 59252K->59252K(59392K)], 5.0618503 secs] [Times: user=5.04 sys=0.00, real=5.06 secs] 
15468.535: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0376264 secs] [Times: user=3.97 sys=0.01, real=4.04 secs] 
15472.573: [Full GC [PSYoungGen: 116736K->116233K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816649K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0230229 secs] [Times: user=4.02 sys=0.00, real=4.02 secs] 
15476.872: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0189989 secs] [Times: user=4.00 sys=0.01, real=4.02 secs] 
15481.152: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0317084 secs] [Times: user=4.00 sys=0.00, real=4.03 secs] 
15485.184: [Full GC [PSYoungGen: 116736K->116377K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816793K(871936K) [PSPermGen: 59256K->59256K(59392K)], 6.9439696 secs] [Times: user=6.75 sys=0.01, real=6.94 secs] 
15492.437: [Full GC [PSYoungGen: 116736K->116514K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816930K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.1839080 secs] [Times: user=4.03 sys=0.01, real=4.18 secs] 
15496.621: [Full GC [PSYoungGen: 116514K->116514K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 816930K->816930K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0780464 secs] [Times: user=4.05 sys=0.00, real=4.08 secs] 
15500.967: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0133835 secs] [Times: user=4.00 sys=0.01, real=4.01 secs] 
15504.981: [Full GC [PSYoungGen: 116736K->116522K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816938K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0842791 secs] [Times: user=4.06 sys=0.00, real=4.08 secs] 
15509.332: [Full GC [PSYoungGen: 116736K->116556K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816972K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.1143123 secs] [Times: user=4.03 sys=0.01, real=4.11 secs] 
15513.717: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9976019 secs] [Times: user=3.98 sys=0.01, real=4.00 secs] 
15517.715: [Full GC [PSYoungGen: 116736K->116564K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816980K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0413757 secs] [Times: user=4.03 sys=0.00, real=4.04 secs] 
15522.026: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0096287 secs] [Times: user=3.99 sys=0.00, real=4.01 secs] 
15526.036: [Full GC [PSYoungGen: 116736K->116568K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816984K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0226499 secs] [Times: user=4.01 sys=0.00, real=4.02 secs] 
15530.329: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0806359 secs] [Times: user=4.01 sys=0.01, real=4.08 secs] 
15534.410: [Full GC [PSYoungGen: 116736K->116459K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->816875K(871936K) [PSPermGen: 59256K->59256K(59392K)], 5.3046010 secs] [Times: user=5.28 sys=0.00, real=5.30 secs] 
15539.989: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700415K->700415K(700416K)] 817151K->817151K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0094775 secs] [Times: user=3.99 sys=0.01, real=4.01 secs] 
15543.999: [Full GC [PSYoungGen: 116736K->116440K(171520K)] [PSOldGen: 700415K->700416K(700416K)] 817151K->816856K(871936K) [PSPermGen: 59256K->59256K(59392K)], 6.2407471 secs] [Times: user=6.18 sys=0.00, real=6.24 secs] 
15550.548: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0402691 secs] [Times: user=4.02 sys=0.01, real=4.04 secs] 
15554.589: [Full GC [PSYoungGen: 116736K->116535K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->816951K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0380531 secs] [Times: user=4.02 sys=0.00, real=4.04 secs] 
15558.899: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9891695 secs] [Times: user=3.98 sys=0.01, real=3.99 secs] 

15562.889: [Full GC [PSYoungGen: 116736K->116561K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->816977K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0307145 secs] [Times: user=4.02 sys=0.00, real=4.03 secs] 

15567.190: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0174578 secs] [Times: user=4.01 sys=0.01, real=4.02 secs] 
15571.208: [Full GC [PSYoungGen: 116736K->116588K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817004K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9955031 secs] [Times: user=3.98 sys=0.00, real=4.00 secs] 
15575.464: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0401537 secs] [Times: user=4.03 sys=0.01, real=4.04 secs] 
15579.504: [Full GC [PSYoungGen: 116736K->116637K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817053K(871936K) [PSPermGen: 59256K->59256K(59392K)], 5.1706954 secs] [Times: user=5.15 sys=0.00, real=5.17 secs] 
15584.936: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9687685 secs] [Times: user=3.96 sys=0.01, real=3.97 secs] 
15588.905: [Full GC [PSYoungGen: 116736K->116665K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817081K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9879101 secs] [Times: user=3.97 sys=0.00, real=3.99 secs] 
15593.211: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9690735 secs] [Times: user=3.96 sys=0.00, real=3.97 secs] 
15597.180: [Full GC [PSYoungGen: 116736K->116667K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817083K(871936K) [PSPermGen: 59256K->59256K(59392K)], 3.9884672 secs] [Times: user=3.98 sys=0.01, real=3.99 secs] 
15601.431: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.1048783 secs] [Times: user=4.04 sys=0.00, real=4.11 secs] 
15605.536: [Full GC [PSYoungGen: 116736K->116669K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817085K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.2097440 secs] [Times: user=4.11 sys=0.01, real=4.21 secs] 
15610.007: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0033139 secs] [Times: user=3.99 sys=0.00, real=4.00 secs] 
15614.010: [Full GC [PSYoungGen: 116736K->116681K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817097K(871936K) [PSPermGen: 59256K->59256K(59392K)], 4.0373354 secs] [Times: user=4.00 sys=0.01, real=4.04 secs] 
15618.309: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0436870 secs] [Times: user=4.03 sys=0.00, real=4.04 secs] 
15622.353: [Full GC [PSYoungGen: 116736K->116690K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817106K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.1021462 secs] [Times: user=4.07 sys=0.01, real=4.10 secs] 
15626.721: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0882206 secs] [Times: user=4.03 sys=0.00, real=4.09 secs] 
15630.810: [Full GC [PSYoungGen: 116736K->116689K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817105K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0423266 secs] [Times: user=4.02 sys=0.01, real=4.04 secs] 
15635.122: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0126749 secs] [Times: user=3.99 sys=0.00, real=4.01 secs] 
15639.135: [Full GC [PSYoungGen: 116736K->116699K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817115K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0946200 secs] [Times: user=4.05 sys=0.01, real=4.09 secs] 
15643.493: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0511811 secs] [Times: user=4.04 sys=0.01, real=4.05 secs] 
15647.545: [Full GC [PSYoungGen: 116736K->116703K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817119K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0154649 secs] [Times: user=4.00 sys=0.00, real=4.02 secs] 
15651.827: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 3.9851157 secs] [Times: user=3.98 sys=0.00, real=3.99 secs] 
15655.812: [Full GC [PSYoungGen: 116736K->116715K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817131K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0297710 secs] [Times: user=3.98 sys=0.01, real=4.03 secs] 
15660.103: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0012770 secs] [Times: user=3.98 sys=0.00, real=4.00 secs] 
15664.105: [Full GC [PSYoungGen: 116736K->116715K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817131K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0345708 secs] [Times: user=4.02 sys=0.01, real=4.03 secs] 
15668.407: [Full GC [PSYoungGen: 116736K->116736K(171520K)] [PSOldGen: 700416K->700416K(700416K)] 817152K->817152K(871936K) [PSPermGen: 59257K->59257K(59392K)], 4.0387420 secs] [Times: user=4.03 sys=0.00, real=4.04 secs] 
^[:q!
^C
-bash-3.00$ 

From Jon.Masamitsu at Sun.COM  Wed Jan 28 11:57:38 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Wed, 28 Jan 2009 11:57:38 -0800
Subject: help with Adaptive Sizing Policy
In-Reply-To: <dc6011320901281002q5084344eo24ab58faa9833941@mail.gmail.com>
References: <dc6011320901281002q5084344eo24ab58faa9833941@mail.gmail.com>
Message-ID: <4980B8B2.8090809@Sun.COM>



On 01/28/09 10:02, Shane Cox wrote:
> ...
> 
> 
> These are my questions:
> 1)  Since -Xmx and -Xms are both set to 1024m, shouldn't adaptive
> sizing be turned OFF?  Based on the GC log, it appears that the VM is
> resizing the YoungSpace between collections.

The overall size of the young gen should not be changing but
the adaptive size policy still will be changing the sizes
of the spaces (eden and the two survivor spaces).  The size of
young gen is considered to be the size of eden and 1 survivor
space (from-space).  The roles of the survivor spaces change
after a minor collection (from-space and to-space flip roles).
So if the survivor spaces are of different sizes (not uncommon),
then eden + from-space (where from-space is flipping between the
two survivor spaces) can be changing.

> 
> 2)  Somewhere around line 35 of this file, the YoungSpace allocation
> decreases from approx 300MB to 171MB.  This occurs at a time when the
> VM appears to be extremely low on space.  Why would the allocation of
> YoungSpace, and therefore the VM's total Heap, decrease at a time when
> almost all available space is occupied?  In fact, it appears that the
> VM is on the verge of an OutOfMemoryException, yet the Heap allocation
> (Young + Old) is only 871936K, whereas the max allowable should be
> 1GB.  Clearly there is a dynamic at play that I'm not aware of.

There have just been a bunch of full collections so the adaptive size
policy is trying to move more of the work into the young gen
collections.  It does that by increasing the size of the survivor
spaces.  The survivor space are likely close to their maximum size
(1/3 of the total young gen).  The 871936K will not include 1 survivor
space.

> 
> 3)  Last, why would PermSpace allocation and occupancy grow over time?
>  I know very little about the classloader, and therefore have no idea
> when the decision is made to load a class ... though I presume most
> are loaded on startup for the server VM.

The perm gen actually looks pretty stable at around 59m.

Applications can load new classes as they need them.  This would
be something to as the customer - does their application use
new classes as it runs.




From Jon.Masamitsu at Sun.COM  Thu Jan 29 10:44:31 2009
From: Jon.Masamitsu at Sun.COM (Jon Masamitsu)
Date: Thu, 29 Jan 2009 10:44:31 -0800
Subject: parallel adaptive gc
In-Reply-To: <2fcb552b0901290925o2d4b6909p9809e910eb3c0186@mail.gmail.com>
References: <2fcb552b0901290925o2d4b6909p9809e910eb3c0186@mail.gmail.com>
Message-ID: <4981F90F.2020401@sun.com>

Tony,

The definition of GC cost used in the adaptive size policy
work is the fraction

      GC-pause-time  /  time-interval

where time-interval is the time from the start of
of one GC to the start of the next GC.  The time-interval
is calculated as

    time-interval = GC-pause-time + time-between-GC

where time-between-GC is time from the end of a GC
to the start of the next GC.  

Each GC cost is calculated separately (minor GC cost
and major GC cost).  The intent is that the
time-between-GC includes all the times (mutator
times and times for other types of GC's).

Does that make sense?

I can't say why the GC cost is modeled as this fraction.
Before the current adaptive size policy there was
an implementation in 1.4.2 that did the sizing of the
generations and the GC cost model may have come
from that previous implementation.

Jon

Tony Guan wrote On 01/29/09 09:25,:

>Hi,
>I just reviewed some of the code of the class PSAdaptiveSizePolicy.
>There is one thing I don't understand, why the mutator cost is
>caculated 2 times: one is measured from the end of the minor
>collection till the beginning of the next minor collection:
>(_latest_minor_mutator_interval_seconds=_minor_timer.seconds), and the
>other is measured from the end of a major collection till the
>beginning of the next major collection.(
>_latest_major_mutator_interval_seconds = _major_timer.seconds())
>
>And the cost of minor collection is calculated as (this minor gc
>time)/(this minor gc time+last MINOR mutator time)
>the cost of major collection is :  (this major gc time)/(this major gc
>time+last MAJOR mutator time)
>
>But in fact, the two mutator time can be overlapping, since we don't
>stop minor timer even when we are doing the major timer, and vice
>versa.
>So we end up with such possible counting:
>time1                              time2
>time3
>minor gc stops               minor gc starts            minor gc stops
>minor_mutator_starts     minor_mutator_ends    minor_mutator_starts
>
>time4                              time5                            time6
>major gc starts                major gc stops             minor gc starts
>major mutator ends         major mutator starts     minor mutator ends
>
>time 7
>minor gc ends
>minor mutator starts.
>
>If we are at time 7, and want to caculate minor gc cost, then
>last_minor_mutator is (time6-time3), and minor gc time is
>(time7-time6)
>but here (time6-time3)=
>(time4-time3)+(time5-time4)+(time6-time5)=mutator time + full gc
>time+mutator time.
>
>based on such cost calculation, I really doubt whether we could be
>precise enough to do any prediction?
>
>Or that's maybe just my incomplete understanding of it, can somebody
>help me out?
>
>Thanks!
>
>
>Tony
>_______________________________________________
>hotspot-gc-use mailing list
>hotspot-gc-use at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>  
>

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


From john.coomes at sun.com  Thu Jan 29 21:28:00 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 05:28:00 +0000
Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b45 for changeset 99846f001ca2
Message-ID: <20090130052801.0BEB5E4EF@hg.openjdk.java.net>

Changeset: e8a2a4d18777
Author:    xdono
Date:      2009-01-29 13:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/e8a2a4d18777

Added tag jdk7-b45 for changeset 99846f001ca2

! .hgtags



From john.coomes at sun.com  Thu Jan 29 21:30:20 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 05:30:20 +0000
Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b45 for changeset
	68814aa5b44b
Message-ID: <20090130053021.B1857E4F4@hg.openjdk.java.net>

Changeset: 1691dbfc08f8
Author:    xdono
Date:      2009-01-29 13:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/1691dbfc08f8

Added tag jdk7-b45 for changeset 68814aa5b44b

! .hgtags



From john.coomes at sun.com  Thu Jan 29 21:38:18 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 05:38:18 +0000
Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b45 for changeset
	0f113667880d
Message-ID: <20090130053821.41A2AE519@hg.openjdk.java.net>

Changeset: b2271877894a
Author:    xdono
Date:      2009-01-29 13:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/b2271877894a

Added tag jdk7-b45 for changeset 0f113667880d

! .hgtags



From john.coomes at sun.com  Thu Jan 29 21:40:43 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 05:40:43 +0000
Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b45 for changeset
	dea7753d7139
Message-ID: <20090130054045.9F104E524@hg.openjdk.java.net>

Changeset: af4a3eeb7812
Author:    xdono
Date:      2009-01-29 13:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/af4a3eeb7812

Added tag jdk7-b45 for changeset dea7753d7139

! .hgtags



From john.coomes at sun.com  Thu Jan 29 21:43:13 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 05:43:13 +0000
Subject: hg: jdk7/hotspot-gc/jdk: Added tag jdk7-b45 for changeset 527b426497a2
Message-ID: <20090130054337.EC2EAE529@hg.openjdk.java.net>

Changeset: 997c6403bf2e
Author:    xdono
Date:      2009-01-29 13:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/997c6403bf2e

Added tag jdk7-b45 for changeset 527b426497a2

! .hgtags



From john.coomes at sun.com  Thu Jan 29 21:50:27 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 05:50:27 +0000
Subject: hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b45 for changeset
	30db5e0aaf83
Message-ID: <20090130055030.6664CE532@hg.openjdk.java.net>

Changeset: d957ceba29f9
Author:    xdono
Date:      2009-01-29 13:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d957ceba29f9

Added tag jdk7-b45 for changeset 30db5e0aaf83

! .hgtags



From y.s.ramakrishna at sun.com  Thu Jan 29 23:56:21 2009
From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com)
Date: Fri, 30 Jan 2009 07:56:21 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 7 new changesets
Message-ID: <20090130075634.C5A65E590@hg.openjdk.java.net>

Changeset: 37b3ca071522
Author:    coleenp
Date:      2009-01-14 20:14 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/37b3ca071522

6793825: Missing include dependancies for GCC without predefined headers
Summary: With predefined headers off for gcc, some .inline.hpp files aren't included to make definition visible for inline functions
Reviewed-by: jcoomes, xlu

! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/includeDB_gc_parNew
! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core
! src/share/vm/includeDB_features

Changeset: 8db2b3e46c38
Author:    swamyv
Date:      2009-01-14 19:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8db2b3e46c38

6786948: SA on core file fails on solaris-amd64 if vm started with -XX:+StartAttachListener
Reviewed-by: jjh, dcubed

! agent/src/os/linux/ps_core.c
! agent/src/os/solaris/proc/saproc.cpp

Changeset: fc14734c5aec
Author:    swamyv
Date:      2009-01-15 13:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fc14734c5aec

Merge


Changeset: 40ee984935b9
Author:    phh
Date:      2009-01-21 11:14 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/40ee984935b9

6792705: Add JAR file to bootclasspath when using AggressiveOpts
Summary: During argument processing, add alt-rt.jar to the bootclasspath between bootclasspath/p and default elements.
Reviewed-by: xlu, coleenp

! src/share/vm/runtime/arguments.cpp

Changeset: 99c597293e35
Author:    coleenp
Date:      2009-01-23 10:41 -0500
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/99c597293e35

Merge

! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: dc3ad84615cf
Author:    xlu
Date:      2009-01-26 12:07 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/dc3ad84615cf

6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS.
Summary: Use NULL_WORD in the places where intptr_t is expected due to incompatible types between intptr_t & int32_t
Reviewed-by: phh, coleenp, never

! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp

Changeset: 5b39c489c39d
Author:    ysr
Date:      2009-01-29 21:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5b39c489c39d

Merge

! src/share/vm/gc_implementation/includeDB_gc_parNew



From y.s.ramakrishna at sun.com  Fri Jan 30 18:00:21 2009
From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com)
Date: Sat, 31 Jan 2009 02:00:21 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6787254: Work queue capacity can be
	increased substantially on some platforms
Message-ID: <20090131020023.6DD51E66C@hg.openjdk.java.net>

Changeset: 23673011938d
Author:    ysr
Date:      2009-01-30 14:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/23673011938d

6787254: Work queue capacity can be increased substantially on some platforms
Summary: Increased the default and maximum size of the CMS marking stack and the size of the parallel workers' work queues in 64-bit mode. The latter was accomplished by an increase in the width of the Taskqueue's Age struct and its Tag field in 64-bit mode.
Reviewed-by: jmasa, tonyp

! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.cpp
! src/share/vm/utilities/taskqueue.hpp



From jon.masamitsu at sun.com  Sat Jan 31 02:38:39 2009
From: jon.masamitsu at sun.com (jon.masamitsu at sun.com)
Date: Sat, 31 Jan 2009 10:38:39 +0000
Subject: hg: jdk7/hotspot-gc/hotspot: 6792421:
	assert(_bitMap->isMarked(addr+size-1), inconsistent Printezis mark)
Message-ID: <20090131103842.12AF7E684@hg.openjdk.java.net>

Changeset: 9a25e0c45327
Author:    jmasa
Date:      2009-01-31 00:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9a25e0c45327

6792421: assert(_bitMap->isMarked(addr+size-1),inconsistent Printezis mark)
Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition.
Reviewed-by: ysr, tonyp

! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/cpCacheKlass.hpp
! src/share/vm/oops/cpCacheOop.hpp