From erik.helin at oracle.com  Mon Apr  1 09:04:08 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 01 Apr 2013 11:04:08 +0200
Subject: RFR (S): 8010916: Add tenuring threshold to young garbage collection
	events
Message-ID: <51594D88.6040905@oracle.com>

Hi all,

this change adds the field "tenuringThreshold" to the 
"vm/gc/collector/young_garbage_collection" event.

The code in gcTrace.hpp/cpp have been slightly adjusted to support this.
The hierarchy of tracers is:

     G1NewTracer -> YoungGCTracer -> GCTracer

where "->" means "inherits from".

Previously, the method "report_gc_end_impl" was virtual in "GCTracer" to 
enable "YoungGCTracer" to send the young GC event when "report_gc_end" 
was called on a GCTracer, as in the following:

     void GCTracer::report_gc_end(...) {
       // do other stuff
       report_gc_end_impl(...);
     }

     void YoungGCTracer::report_gc_end_impl(...) {
       // send young gc event here
     }

In this change, YoungGCTracer now has a method "report_young_gc_end" 
that is virtual and that G1NewTracer overrides. This means that 
YoungGCTracer does not need to override the method "report_gc_end_impl" 
from GCTracer. This also means that all young collectors now also must 
call "report_young_gc_end".

This change was needed, since report_young_gc_end must take the tenuring 
threshold as a parameter, something that was not possible to do with 
"report_gc_end_impl".

Webrev:
http://cr.openjdk.java.net/~ehelin/8010916/webrev.00/

Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010916

Testing:
JPRT

Thanks,
Erik


From john.cuthbertson at oracle.com  Mon Apr  1 18:47:01 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 01 Apr 2013 11:47:01 -0700
Subject: RFR (XXS): 8005857: assert in GC_locker from PSOldGen::expand
	with -XX:+PrintGCDetails and Verbose
In-Reply-To: <1364547114.2821.11.camel@cirrus>
References: <1364547114.2821.11.camel@cirrus>
Message-ID: <5159D625.2060902@oracle.com>

Hi Thomas,

The change looks god to me.

JohnC

On 3/29/2013 1:51 AM, Thomas Schatzl wrote:
> Hi all,
>
>    please review the following change for 8005857:
>
> In this issue, code checks whether the gc locker is active during heap
> expansion to print a message that instead of gc the heap has been expanded.
>
> The code used the method GCLocker::is_active() to get the gc locker
> state, but is_active() asserts when the VM is currently not at a
> safepoint and no GC is actually needed.
> This assert does not hold in all cases while expanding the heap. E.g. heap
> expansion may be done outside of a safepoint when satisfying an allocation
> request for a large object. Heap expansion may occur also when no GC is
> pending in the gc locker.
>
> Imho the previous use of is_active() was wrong not only because of the assert.
> The message text notifies of the avoidance of a gc. However, the condition did
> not check whether the gc locker indicated the need for a gc, i.e. did not
> check the GCLocker::needs_gc() predicate.
>
> This change uses GCLocker::is_active_and_needs_gc() instead of
> GCLocker::is_active(). Which does not check whether the vm is at a safepoint,
> and also checks whether a gc is actually pending.
>
> Jon M. suggested this fix.
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8005857
>
> bugs.sun:
> http://bugs.sun.com/view_bug.do?bug_id=8005857
>
> Testing:
> jprt, kitchensink, runthese jck tests (which contains the test case
> where this bug has been reported)
>
> Thanks,
> Thomas
>
>
>
>



From jon.masamitsu at oracle.com  Mon Apr  1 22:13:07 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 01 Apr 2013 15:13:07 -0700
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
Message-ID: <515A0673.9060407@oracle.com>

For the perm gen removal project the ChunkList class
which implemented a simple freelist of Metachunk's was added.
This change replaces ChunkList with FreeList<Metachunk>.

Changes include

- Deletion of ChunkList
- Code to initialize the freelists in the FreeList style
- Replacement of call to ChunkList methods with the
equivalent calls to FreeList methods.

http://cr.openjdk.java.net/~jmasa/8011173

Thanks.

Jon


From mikael.gerdin at oracle.com  Tue Apr  2 09:57:30 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 02 Apr 2013 11:57:30 +0200
Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests.
	Default shell for jtreg is bourne. thus failure
In-Reply-To: <51556105.2040900@oracle.com>
References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com>
	<5151A2E3.60507@oracle.com> <51556105.2040900@oracle.com>
Message-ID: <515AAB8A.4060109@oracle.com>

Leonid,

On 2013-03-29 10:38, Leonid Mesnik wrote:
> Hi
>
> Here is new version of test. (pass jprt)
> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.1/
> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.1/>

Overall it looks good. The test is nicely specified and in a controlled 
environment.

Can you please make the test save the stdout/stderr of the launched 
process and print it out in case of failure?
If the launch fails with some exit code we won't know its cause. I 
suggest something like:
pb.redirectErrorStream(true)
pb.redirectOutput("output.log")

I also have one small comment in:
args.toArray(externalVMopts)

Even though it may be correct to pass exernalVMopts to toArray(T[]) it 
looks a bit confusing.
Can you please change it to either
"toArray(new String[0])" or
"toArray(new String[args.size()])"

/Mikael

>
> See my comment inline.
> On 03/26/2013 05:30 PM, Mikael Gerdin wrote:
>> Leonid,
>>
>> On 2013-03-22 08:06, Leonid Mesnik wrote:
>>> Could anyone please review this small test fix.
>>>
>>> Leonid
>>> On 03/20/2013 04:16 PM, Leonid Mesnik wrote:
>>>> Hi
>>>>
>>>> Could you please review fix for  8009808 TEST-BUG : test case is using
>>>> bash style tests. Default shell for jtreg is bourne. thus failure.
>>>>
>>>> I've completely rewritten test in java without major changes it test
>>>> logic.
>>>> I remove CMS so test could be run when CMS is not supported. Also I
>>>> changed max memory to 128M to reduce memory load and increase number
>>>> of GC log entries.
>>
>> Do you think it would be useful to run this test with different GCs?
>> In that case you can pick up the test.vm.opts and test.java.opts
>> system properties and add them to the java command line you launch.
> I've added test.java.opts properties. They are used during testing to
> set additional GC.
>>
>>>>
>>>> Here is the link:
>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/
>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.0/>
>>>>
>>
>> Are you sure about this:
>> static final File currentDirectory = new
>> File(System.getProperty("user.dir"));
>>
>> isn't user.dir the home directory? Current directory should be just "."
>> Something like new File(".").getAbsoluteFile() should give you the
>> current work dir.
> System.getProperty("user.dir") is current directory. However I changed
> it to "." to make it more evident.
>>
>> What is the relation between "numberOfFiles" and "minutesToRun"??
>> How do you know that running for 3 minutes will cause a log rotation?
> I've updated test to invoke fullGC and estimate lower bound of needed
> invocation. Now test check that exactly 3 logs are generated.
>
> Leonid
>>
>> I know that you've just adapted the existing test but it seems strange
>> to me.
>>
>> /Mikael
>>
>>
>>
>>>
>>>
>
>


From jesper.wilhelmsson at oracle.com  Tue Apr  2 10:33:02 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 02 Apr 2013 12:33:02 +0200
Subject: RFR (S): 8010916: Add tenuring threshold to young garbage
	collection events
In-Reply-To: <51594D88.6040905@oracle.com>
References: <51594D88.6040905@oracle.com>
Message-ID: <515AB3DE.60909@oracle.com>

Erik,

I'm OK with this change as is but I think it is unfortunate that you chose not 
to follow the pattern used by the other events where we register a value at some 
point and then, in the end, report the event. I realize that in this case it 
would probably result in registering the tenuring threshold and then at the next 
line reporting the YC event. I'm not sure which is worse. I don't really like 
that you need to pass the tenuring threshold to report_young_gc_end.
/Jesper


Erik Helin skrev 1/4/13 11:04 AM:
> Hi all,
>
> this change adds the field "tenuringThreshold" to the
> "vm/gc/collector/young_garbage_collection" event.
>
> The code in gcTrace.hpp/cpp have been slightly adjusted to support this.
> The hierarchy of tracers is:
>
>      G1NewTracer -> YoungGCTracer -> GCTracer
>
> where "->" means "inherits from".
>
> Previously, the method "report_gc_end_impl" was virtual in "GCTracer" to enable
> "YoungGCTracer" to send the young GC event when "report_gc_end" was called on a
> GCTracer, as in the following:
>
>      void GCTracer::report_gc_end(...) {
>        // do other stuff
>        report_gc_end_impl(...);
>      }
>
>      void YoungGCTracer::report_gc_end_impl(...) {
>        // send young gc event here
>      }
>
> In this change, YoungGCTracer now has a method "report_young_gc_end" that is
> virtual and that G1NewTracer overrides. This means that YoungGCTracer does not
> need to override the method "report_gc_end_impl" from GCTracer. This also means
> that all young collectors now also must call "report_young_gc_end".
>
> This change was needed, since report_young_gc_end must take the tenuring
> threshold as a parameter, something that was not possible to do with
> "report_gc_end_impl".
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8010916/webrev.00/
>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010916
>
> Testing:
> JPRT
>
> Thanks,
> Erik


From thomas.schatzl at oracle.com  Tue Apr  2 12:05:53 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 02 Apr 2013 14:05:53 +0200
Subject: RFR(S): 8010780: G1: Eden occupancy/capacity output wrong after
	a full GC
In-Reply-To: <51536EE1.1010308@oracle.com>
References: <51536EE1.1010308@oracle.com>
Message-ID: <1364904353.2845.27.camel@cirrus>

Hi,

On Wed, 2013-03-27 at 15:12 -0700, John Cuthbertson wrote:
> Hi Everyone,
> 
> Can I have a couple of volunteers look review this fix? The webrev can 
> be found at: http://cr.openjdk.java.net/~johnc/8010780/webrev.0/
> 
> Summary:
> One of the performance team spotted and error in the G1 logs following a 
> full GC:
> 
> 411.322: [G1Ergonomics (Mixed GCs)  (to-space exhausted), 0.4279260 secs]
>
> [...]
>
> The heap transition line for the GC after the full GC was displaying the 
> eden capacity that was calculated by the GC preceding the full GC rather 
> than the eden capacity calculated at the end of the of the full GC. As a 
> result the reported eden occupancy is much larger than the reported 
> capacity.
> 
> The main part of the fix is the moving of 
> G1CollectorPolicy::_prev_eden_capacity from 
> G1CollectorPolicy::print_detailed_heap_transition() to 
> G1CollectorPolicy::record_collection_pause_start(). The code that 
> records the heap state before the GC has been refactored into a separate 
> routine and is invoked at the start of both an incremental and full GC.
> 

Seems fine.

Thomas




From mikael.gerdin at oracle.com  Tue Apr  2 14:42:44 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 02 Apr 2013 16:42:44 +0200
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515A0673.9060407@oracle.com>
References: <515A0673.9060407@oracle.com>
Message-ID: <515AEE64.6070101@oracle.com>

Jon,

On 2013-04-02 00:13, Jon Masamitsu wrote:
> For the perm gen removal project the ChunkList class
> which implemented a simple freelist of Metachunk's was added.
> This change replaces ChunkList with FreeList<Metachunk>.
>
> Changes include
>
> - Deletion of ChunkList
> - Code to initialize the freelists in the FreeList style
> - Replacement of call to ChunkList methods with the
> equivalent calls to FreeList methods.
>
> http://cr.openjdk.java.net/~jmasa/8011173

This looks like a good cleanup step.
I'm fine with you pushing this as is, these are just my thoughts about 
the FreeList<> stuff.

Regarding your comment in ChunkManager::return_chunks I think it could 
be resolved by making SpaceManager::_chunks_in_use[] into an array of 
ChunkList, similar to ChunkManager::_free_chunks.

The name FreeList is kind of a misnomer since it's actually just the 
head of a generic linked list.

Maybe we should consider encapsulating the managing of the _next and 
_prev fields only through the FreeList<> template by making the setters 
to them private and friend:ing FreeList<Metachunk> in class Metachunk 
and only ever letting FreeList manage the links?

It's confusing to have FreeList handle the links through link_prev and 
link_next and other parts of the code using set_next and set_prev.

/Mikael


>
> Thanks.
>
> Jon


From jon.masamitsu at oracle.com  Tue Apr  2 15:43:56 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 02 Apr 2013 08:43:56 -0700
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515AEE64.6070101@oracle.com>
References: <515A0673.9060407@oracle.com> <515AEE64.6070101@oracle.com>
Message-ID: <515AFCBC.60807@oracle.com>

Mikael,

Thanks for the review.

On 04/02/13 07:42, Mikael Gerdin wrote:
> Jon,
>
> On 2013-04-02 00:13, Jon Masamitsu wrote:
>> For the perm gen removal project the ChunkList class
>> which implemented a simple freelist of Metachunk's was added.
>> This change replaces ChunkList with FreeList<Metachunk>.
>>
>> Changes include
>>
>> - Deletion of ChunkList
>> - Code to initialize the freelists in the FreeList style
>> - Replacement of call to ChunkList methods with the
>> equivalent calls to FreeList methods.
>>
>> http://cr.openjdk.java.net/~jmasa/8011173
>
> This looks like a good cleanup step.
> I'm fine with you pushing this as is, these are just my thoughts about 
> the FreeList<> stuff.

I have some other changes build on top these changes so I would
like to push them with minimal changes.

>
> Regarding your comment in ChunkManager::return_chunks I think it could 
> be resolved by making SpaceManager::_chunks_in_use[] into an array of 
> ChunkList, similar to ChunkManager::_free_chunks.

I think something like this would work but as you note below FreeList is 
not really a freelist but
just a list.  I hesitated to make _chunks_in_use a FreeList because it 
would confuse the casual
reader.
>
> The name FreeList is kind of a misnomer since it's actually just the 
> head of a generic linked list.

Yes the name is wrong.  There is actually a prepend() method that takes 
a FreeList and that
is what I wanted to use  but the name "FreeList" stopped me.

>
> Maybe we should consider encapsulating the managing of the _next and 
> _prev fields only through the FreeList<> template by making the 
> setters to them private and friend:ing FreeList<Metachunk> in class 
> Metachunk and only ever letting FreeList manage the links?

So I don't understand that.  I've created a CR for your suggested clean ups.
8011265   I'll think about that when I get to fixing this.

>
> It's confusing to have FreeList handle the links through link_prev and 
> link_next and other parts of the code using set_next and set_prev.

link_prev() and link_next() have special meaning in CMS.  One or the 
other used to set
the is_free bit in a CMS freelist.  It would be good to clean that up.

Thanks again.

Jon

>
> /Mikael
>
>
>>
>> Thanks.
>>
>> Jon


From erik.helin at oracle.com  Tue Apr  2 16:24:04 2013
From: erik.helin at oracle.com (erik.helin at oracle.com)
Date: Tue, 02 Apr 2013 16:24:04 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8009408:
	gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit
	code 1"
Message-ID: <20130402162409.19A6B48533@hg.openjdk.java.net>

Changeset: 8bf6338972ce
Author:    ehelin
Date:      2013-03-23 09:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8bf6338972ce

8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1"
Reviewed-by: brutisso, sla, ctornqvi

! test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
+ test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java



From uschindler at apache.org  Tue Apr  2 19:16:58 2013
From: uschindler at apache.org (Uwe Schindler)
Date: Tue, 2 Apr 2013 21:16:58 +0200
Subject: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
	during	reference processing
In-Reply-To: <20130319012113.3D86148231@hg.openjdk.java.net>
References: <20130319012113.3D86148231@hg.openjdk.java.net>
Message-ID: <016101ce2fd6$a596bfb0$f0c43f10$@apache.org>

Hi John,

today I installed JDK8 b83 on one of the Jenkins build servers used by Apache Lucene: The problem with 32 bit JVMs and G1 collector is solved. I compared the trunk checkout of Lucene with both JVMs: In b82 it hangs, in b83 it passes. So I was able to re-enable 32 bit builds without the extra workaround stacksize option again.

Thanks for fixing this issue.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-
> bounces at openjdk.java.net] On Behalf Of john.cuthbertson at oracle.com
> Sent: Tuesday, March 19, 2013 2:21 AM
> To: hotspot-gc-dev at openjdk.java.net
> Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
> during reference processing
> 
> Changeset: fa08949fe0cb
> Author:    johnc
> Date:      2013-03-18 11:05 -0700
> URL:       http://hg.openjdk.java.net/hsx/hotspot-
> gc/hotspot/rev/fa08949fe0cb
> 
> 8009536: G1: Apache Lucene hang during reference processing
> Summary: In CMTask::do_marking_step(), Skip offering termination and
> entering the first and second synchronization barriers if called from a serial
> context, i.e. the VM thread.
> Reviewed-by: brutisso, tschatzl
> 
> ! src/share/vm/gc_implementation/g1/concurrentMark.cpp
> ! src/share/vm/gc_implementation/g1/concurrentMark.hpp



From john.cuthbertson at oracle.com  Tue Apr  2 20:48:15 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 02 Apr 2013 13:48:15 -0700
Subject: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during
	reference processing
In-Reply-To: <016101ce2fd6$a596bfb0$f0c43f10$@apache.org>
References: <20130319012113.3D86148231@hg.openjdk.java.net>
	<016101ce2fd6$a596bfb0$f0c43f10$@apache.org>
Message-ID: <515B440F.9010008@oracle.com>

Hi Uwe,

Thanks for the update. That is good to know. The bulk of the credit goes 
to Bengt who did the initial diagnosis and the prototype fix.

Thanks also for walking me through how to reproduce the issue. Once the 
magic formula for the proxy was found - your instructions were spot on. 
The tests were awesome as marking stress tests and uncovered several 
issues associated with concurrent marking overflows. I've added them to 
the set of tests I run for marking changes. :)

Cheers,

JohnC

On 4/2/2013 12:16 PM, Uwe Schindler wrote:
> Hi John,
>
> today I installed JDK8 b83 on one of the Jenkins build servers used by Apache Lucene: The problem with 32 bit JVMs and G1 collector is solved. I compared the trunk checkout of Lucene with both JVMs: In b82 it hangs, in b83 it passes. So I was able to re-enable 32 bit builds without the extra workaround stacksize option again.
>
> Thanks for fixing this issue.
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler at apache.org
> Apache Lucene PMC Member / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>> -----Original Message-----
>> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-
>> bounces at openjdk.java.net] On Behalf Of john.cuthbertson at oracle.com
>> Sent: Tuesday, March 19, 2013 2:21 AM
>> To: hotspot-gc-dev at openjdk.java.net
>> Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
>> during reference processing
>>
>> Changeset: fa08949fe0cb
>> Author:    johnc
>> Date:      2013-03-18 11:05 -0700
>> URL:       http://hg.openjdk.java.net/hsx/hotspot-
>> gc/hotspot/rev/fa08949fe0cb
>>
>> 8009536: G1: Apache Lucene hang during reference processing
>> Summary: In CMTask::do_marking_step(), Skip offering termination and
>> entering the first and second synchronization barriers if called from a serial
>> context, i.e. the VM thread.
>> Reviewed-by: brutisso, tschatzl
>>
>> ! src/share/vm/gc_implementation/g1/concurrentMark.cpp
>> ! src/share/vm/gc_implementation/g1/concurrentMark.hpp



From john.cuthbertson at oracle.com  Tue Apr  2 23:32:03 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 02 Apr 2013 16:32:03 -0700
Subject: RFR(S): 8011343: Add new flag for verifying the heap during startup
Message-ID: <515B6A73.2060602@oracle.com>

Hi Everyone,

Can I have a couple of reviews for this change please? The webrev can be 
found at: http://cr.openjdk.java.net/~johnc/8011343/webrev.0/

Summary:
During the code review for 8010463 it was suggested that the 
verification that is performed during VM startup should be done under 
control of a new flag rather than piggy-backing off the VerifyBeforeGC 
flag. In response to another comment I suggested that the verification 
should be done using a VM Operation so as to maximize the verification 
(certain parts of the G1 heap are skipped if the verification is not 
performed at a safepoint).

These changes address these comments.

Testing:
GC test suite with the new flag
jprt with the new flag (this configuration saw some failures that are 
caused by the issue described in 8010943)
jtreg with the changed regression test

Note: I think the warning(s) emitted from arguments.cpp when 
FLSVerifyAllHeapReferences is enabled can be removed (now that 
verification is performed at a safepoint) but I am loathe to do so. 
Testing this configuration resulted in some assertion failures (even 
with a new workspace) that I'll be submitting another CR for.

Thanks,

JohnC




From john.cuthbertson at oracle.com  Wed Apr  3 00:09:44 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Wed, 03 Apr 2013 00:09:44 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8005857: assert in GC_locker from
	PSOldGen::expand with -XX:+PrintGCDetails and Verbose
Message-ID: <20130403000948.A4EAE48566@hg.openjdk.java.net>

Changeset: cc5b5976d72c
Author:    tschatzl
Date:      2013-04-02 10:03 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cc5b5976d72c

8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose
Summary: Use GC_locker::is_active_and_needs_gc() instead of GC_locker::is_active() for providing information about the reason of heap expansion.
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp



From stefan.karlsson at oracle.com  Wed Apr  3 07:40:09 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 03 Apr 2013 09:40:09 +0200
Subject: RFR(S): 8011343: Add new flag for verifying the heap during
	startup
In-Reply-To: <515B6A73.2060602@oracle.com>
References: <515B6A73.2060602@oracle.com>
Message-ID: <515BDCD9.4080101@oracle.com>

Looks good to me.

StefanK

On 04/03/2013 01:32 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of reviews for this change please? The webrev can 
> be found at: http://cr.openjdk.java.net/~johnc/8011343/webrev.0/
>
> Summary:
> During the code review for 8010463 it was suggested that the 
> verification that is performed during VM startup should be done under 
> control of a new flag rather than piggy-backing off the VerifyBeforeGC 
> flag. In response to another comment I suggested that the verification 
> should be done using a VM Operation so as to maximize the verification 
> (certain parts of the G1 heap are skipped if the verification is not 
> performed at a safepoint).
>
> These changes address these comments.
>
> Testing:
> GC test suite with the new flag
> jprt with the new flag (this configuration saw some failures that are 
> caused by the issue described in 8010943)
> jtreg with the changed regression test
>
> Note: I think the warning(s) emitted from arguments.cpp when 
> FLSVerifyAllHeapReferences is enabled can be removed (now that 
> verification is performed at a safepoint) but I am loathe to do so. 
> Testing this configuration resulted in some assertion failures (even 
> with a new workspace) that I'll be submitting another CR for.
>
> Thanks,
>
> JohnC
>
>



From mikael.gerdin at oracle.com  Wed Apr  3 10:15:13 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Wed, 03 Apr 2013 10:15:13 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 32 new changesets
Message-ID: <20130403101750.7C65848588@hg.openjdk.java.net>

Changeset: eca90b8a06eb
Author:    rdurbin
Date:      2013-03-19 11:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eca90b8a06eb

7030610: runtime/6878713/Test6878713.sh fails Error. failed to clean up files after test
7123945: runtime/6878713/Test6878713.sh require about 2G of native memory, swaps and times out
Summary: Add new diagnostic option -XX:MallocMaxTestWords=NNN and fix Test6878713.sh.
Reviewed-by: dcubed, coleenp, dholmes, iklam

! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.cpp
! test/runtime/6878713/Test6878713.sh

Changeset: a649f6511c04
Author:    ctornqvi
Date:      2013-03-20 08:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a649f6511c04

8010084: Race in runtime/NMT/BaselineWithParameter.java
Summary: Added a waitFor() on the process
Reviewed-by: mgerdin, sla, zgu

! test/runtime/NMT/BaselineWithParameter.java

Changeset: 91bf0bdae37b
Author:    coleenp
Date:      2013-03-20 08:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/91bf0bdae37b

8008217: CDS: Class data sharing limits the malloc heap on Solaris
Summary: In 64bit VM move CDS archive address to 32G on all platforms using new flag SharedBaseAddress.  In 32bit VM set CDS archive address to 3Gb on Linux and let other OSs pick the address.
Reviewed-by: kvn, dcubed, zgu, hseigel

! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp
! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp
! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp
! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp
! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp
! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 2c7663baeb67
Author:    acorn
Date:      2013-03-20 11:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2c7663baeb67

8010017: lambda: reflection get(Declared)Methods support for default methods.
Summary: Don't expose vm generated overpass (bridges to default methods).
Reviewed-by: dholmes, fparain

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

Changeset: 79259e97a072
Author:    acorn
Date:      2013-03-20 12:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/79259e97a072

Merge


Changeset: 1feda2e9f044
Author:    ctornqvi
Date:      2013-03-20 20:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1feda2e9f044

8007982: some runtime/CommandLine/ tests fail on 32-bit platforms
Summary: Changed tests to use platform independent flags
Reviewed-by: collins, hseigel, zgu

! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java
! test/runtime/CommandLine/FlagWithInvalidValue.java
! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java

Changeset: 81d1b58c078f
Author:    rdurbin
Date:      2013-03-20 20:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/81d1b58c078f

8010396: checking MallocMaxTestWords in testMalloc() function is redundant
Summary: Remove redundant checks in testMalloc and add assert.
Reviewed-by: dcubed, coleenp, dholmes

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

Changeset: e7081eb7e786
Author:    dcubed
Date:      2013-03-20 20:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e7081eb7e786

Merge


Changeset: 06db4c0afbf3
Author:    zgu
Date:      2013-03-20 09:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/06db4c0afbf3

8009298: NMT: Special version of class loading/unloading with runThese stresses out NMT
8009777: NMT: add new NMT dcmd to control auto shutdown option
Summary: Added diagnostic VM option and DCmd command to allow NMT stay alive under stress situation
Reviewed-by: dcubed, coleenp

! src/share/vm/runtime/globals.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/services/nmtDCmd.cpp
! src/share/vm/services/nmtDCmd.hpp

Changeset: 0ac03fef364f
Author:    zgu
Date:      2013-03-21 06:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0ac03fef364f

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 14509df4cd63
Author:    iklam
Date:      2013-03-21 20:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/14509df4cd63

8010389: After fix for 7107135 a failed dlopen() call results in a VM crash
Summary: Call dlerror() in VM thread as necessary.
Reviewed-by: coleenp, dholmes

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
+ test/runtime/8010389/VMThreadDlopen.java

Changeset: 6574f999e0cf
Author:    dcubed
Date:      2013-03-23 22:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6574f999e0cf

Merge

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

Changeset: c342fbdf8a70
Author:    ctornqvi
Date:      2013-03-24 09:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c342fbdf8a70

8008454: test/runtime/NMT/PrintNMTStatistics is broken
Summary: Added @run tag so that it actually runs the test, also fixed broken command line and incorrect parsing. Also reviewed by gerard.ziemski at oracle.com
Reviewed-by: mgerdin, zgu

! test/runtime/NMT/PrintNMTStatistics.java

Changeset: 9c8e53c7bed0
Author:    ctornqvi
Date:      2013-03-24 09:21 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9c8e53c7bed0

Merge

- make/test/Queens.java

Changeset: 729be16a470b
Author:    hseigel
Date:      2013-03-25 08:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/729be16a470b

8010667: Non-zero padding is not allowed in splitverifier for tableswitch/lookupswitch instructions.
Summary: Don't check the padding bits if class file version is >= 51.
Reviewed-by: kvn, dholmes, coleenp

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

Changeset: b8deb3205b51
Author:    bharadwaj
Date:      2013-03-25 09:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b8deb3205b51

8009552: test/vm/verifier/TestStaticIF.java failing with hs25.0-b
Summary: Remove support for verification of class files with version 52 and above from type inference verifier.
Reviewed-by: acorn, hseigel

! src/share/vm/classfile/verifier.cpp
- test/runtime/8007736/TestStaticIF.java

Changeset: 1916ca1dec2f
Author:    rbackman
Date:      2013-03-26 15:00 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1916ca1dec2f

8009382: Add JVM_Get{Field|Method}TypeAnnotations
Reviewed-by: dcubed, rbackman
Contributed-by: Joel Borggren-Franck <joel.franck at oracle.com>

! make/bsd/makefiles/mapfile-vers-debug
! make/bsd/makefiles/mapfile-vers-product
! make/linux/makefiles/mapfile-vers-debug
! make/linux/makefiles/mapfile-vers-product
! make/solaris/makefiles/mapfile-vers
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvm.h

Changeset: 36376b540a98
Author:    hseigel
Date:      2013-03-26 09:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/36376b540a98

8009595: The UseSplitVerifier option needs to be deprecated.
Summary: Put UseSplitVerifier option on the deprecated list.
Reviewed-by: dcubed, kmo, acorn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a8016373a893
Author:    hseigel
Date:      2013-03-26 12:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a8016373a893

Merge


Changeset: 6b748c9e1845
Author:    zgu
Date:      2013-03-26 14:11 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6b748c9e1845

8010651: create.bat still builds the kernel
Summary: Remove old kernel build targets and VS C++ projects created by create.bat on Windows
Reviewed-by: coleenp, sla

! make/windows/build.make
! make/windows/create.bat
! make/windows/makefiles/compile.make
! make/windows/makefiles/product.make
! make/windows/makefiles/vm.make
- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java

Changeset: 85192022ba8c
Author:    zgu
Date:      2013-03-26 11:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/85192022ba8c

Merge

- test/runtime/8007736/TestStaticIF.java

Changeset: 23f2d309e855
Author:    zgu
Date:      2013-03-26 15:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/23f2d309e855

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw

Changeset: aeb22fdaa14c
Author:    brutisso
Date:      2013-03-28 09:07 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aeb22fdaa14c

Merge

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

Changeset: 728b89404e34
Author:    jprovino
Date:      2013-03-21 10:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/728b89404e34

8009904: jvmtiClassFileReconstituter.cpp needs to be excluded from the minimal jvm
Summary: jvmtiClassFileReconstituter.cpp needs to be added to the list of files to exclude when JVMTI is excluded from the jvm
Reviewed-by: dholmes, sspitsyn

! make/excludeSrc.make

Changeset: 7ca101eef24a
Author:    jprovino
Date:      2013-03-23 14:59 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7ca101eef24a

Merge


Changeset: 04d6d4322c6a
Author:    collins
Date:      2013-03-27 09:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04d6d4322c6a

8009152: A number of jtreg tests need review/improvement
Summary: Added a new test_env.txt file to capture common shell variable. Added concept of COMPILEJAVA for use when TESTJAVA is a JRE. If COMPILEJAVA not set then TESTJAVA will be the default with assumption it is a JDK.
Reviewed-by: kvn, brutisso, coleenp

! test/compiler/5091921/Test6890943.sh
! test/compiler/5091921/Test7005594.sh
! test/compiler/6857159/Test6857159.sh
! test/compiler/7068051/Test7068051.sh
! test/compiler/7070134/Test7070134.sh
! test/compiler/7200264/Test7200264.sh
! test/gc/6941923/test6941923.sh
! test/runtime/6626217/Test6626217.sh
! test/runtime/6878713/Test6878713.sh
! test/runtime/6929067/Test6929067.sh
! test/runtime/7020373/Test7020373.sh
! test/runtime/7051189/Xchecksig.sh
! test/runtime/7107135/Test7107135.sh
! test/runtime/7110720/Test7110720.sh
! test/runtime/7158804/Test7158804.sh
! test/runtime/7162488/Test7162488.sh
+ test/test_env.sh

Changeset: d1897e7e0488
Author:    collins
Date:      2013-03-28 15:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d1897e7e0488

Merge

! test/runtime/6878713/Test6878713.sh

Changeset: e614fc564ded
Author:    katleman
Date:      2013-03-28 10:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e614fc564ded

Added tag jdk8-b83 for changeset 1c8db54ee9f3

! .hgtags

Changeset: 8d0f263a370c
Author:    amurillo
Date:      2013-03-28 19:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8d0f263a370c

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
- test/runtime/8007736/TestStaticIF.java

Changeset: af788b85010e
Author:    amurillo
Date:      2013-03-28 19:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/af788b85010e

Added tag hs25-b25 for changeset 8d0f263a370c

! .hgtags

Changeset: d26674db4d91
Author:    amurillo
Date:      2013-03-28 19:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d26674db4d91

8011022: new hotspot build - hs25-b26
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 15c04fe93c18
Author:    mgerdin
Date:      2013-04-03 09:19 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/15c04fe93c18

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
- test/runtime/8007736/TestStaticIF.java



From erik.helin at oracle.com  Wed Apr  3 17:19:27 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 03 Apr 2013 19:19:27 +0200
Subject: RFR (S): 8010916: Add tenuring threshold to young garbage
	collection events
In-Reply-To: <515AB3DE.60909@oracle.com>
References: <51594D88.6040905@oracle.com> <515AB3DE.60909@oracle.com>
Message-ID: <515C649F.4060102@oracle.com>

Hi Jesper,

thanks for the review! I would also like to thank Stefan for taking a 
look at the code offline.

On 04/02/2013 12:33 PM, Jesper Wilhelmsson wrote:
> Erik,
>
> I'm OK with this change as is but I think it is unfortunate that you
> chose not to follow the pattern used by the other events where we
> register a value at some point and then, in the end, report the event. I
> realize that in this case it would probably result in registering the
> tenuring threshold and then at the next line reporting the YC event. I'm
> not sure which is worse. I don't really like that you need to pass the
> tenuring threshold to report_young_gc_end.

The change has been updated to now saving the value in the young gc 
tracer and then report it at the end. I would prefer to not have to deal 
with this extra state, but it has to be this way because the young gc 
event needs the GC end time, and the end time is only passed to 
report_gc_end (thanks Stefan for pointing this out).

Please see new webrev at:
http://cr.openjdk.java.net/~ehelin/8010916/webrev.01/

Thanks,
Erik

> /Jesper
>
>
> Erik Helin skrev 1/4/13 11:04 AM:
>> Hi all,
>>
>> this change adds the field "tenuringThreshold" to the
>> "vm/gc/collector/young_garbage_collection" event.
>>
>> The code in gcTrace.hpp/cpp have been slightly adjusted to support this.
>> The hierarchy of tracers is:
>>
>>      G1NewTracer -> YoungGCTracer -> GCTracer
>>
>> where "->" means "inherits from".
>>
>> Previously, the method "report_gc_end_impl" was virtual in "GCTracer"
>> to enable
>> "YoungGCTracer" to send the young GC event when "report_gc_end" was
>> called on a
>> GCTracer, as in the following:
>>
>>      void GCTracer::report_gc_end(...) {
>>        // do other stuff
>>        report_gc_end_impl(...);
>>      }
>>
>>      void YoungGCTracer::report_gc_end_impl(...) {
>>        // send young gc event here
>>      }
>>
>> In this change, YoungGCTracer now has a method "report_young_gc_end"
>> that is
>> virtual and that G1NewTracer overrides. This means that YoungGCTracer
>> does not
>> need to override the method "report_gc_end_impl" from GCTracer. This
>> also means
>> that all young collectors now also must call "report_young_gc_end".
>>
>> This change was needed, since report_young_gc_end must take the tenuring
>> threshold as a parameter, something that was not possible to do with
>> "report_gc_end_impl".
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8010916/webrev.00/
>>
>> Bug:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010916
>>
>> Testing:
>> JPRT
>>
>> Thanks,
>> Erik



From jesper.wilhelmsson at oracle.com  Wed Apr  3 17:57:23 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 03 Apr 2013 19:57:23 +0200
Subject: RFR (S): 8010916: Add tenuring threshold to young garbage
	collection events
In-Reply-To: <515C649F.4060102@oracle.com>
References: <51594D88.6040905@oracle.com> <515AB3DE.60909@oracle.com>
	<515C649F.4060102@oracle.com>
Message-ID: <515C6D83.5010306@oracle.com>

Looks good,
Ship it!
/Jesper

Erik Helin skrev 3/4/13 7:19 PM:
> Hi Jesper,
>
> thanks for the review! I would also like to thank Stefan for taking a look at
> the code offline.
>
> On 04/02/2013 12:33 PM, Jesper Wilhelmsson wrote:
>> Erik,
>>
>> I'm OK with this change as is but I think it is unfortunate that you
>> chose not to follow the pattern used by the other events where we
>> register a value at some point and then, in the end, report the event. I
>> realize that in this case it would probably result in registering the
>> tenuring threshold and then at the next line reporting the YC event. I'm
>> not sure which is worse. I don't really like that you need to pass the
>> tenuring threshold to report_young_gc_end.
>
> The change has been updated to now saving the value in the young gc tracer and
> then report it at the end. I would prefer to not have to deal with this extra
> state, but it has to be this way because the young gc event needs the GC end
> time, and the end time is only passed to report_gc_end (thanks Stefan for
> pointing this out).
>
> Please see new webrev at:
> http://cr.openjdk.java.net/~ehelin/8010916/webrev.01/
>
> Thanks,
> Erik
>
>> /Jesper
>>
>>
>> Erik Helin skrev 1/4/13 11:04 AM:
>>> Hi all,
>>>
>>> this change adds the field "tenuringThreshold" to the
>>> "vm/gc/collector/young_garbage_collection" event.
>>>
>>> The code in gcTrace.hpp/cpp have been slightly adjusted to support this.
>>> The hierarchy of tracers is:
>>>
>>>      G1NewTracer -> YoungGCTracer -> GCTracer
>>>
>>> where "->" means "inherits from".
>>>
>>> Previously, the method "report_gc_end_impl" was virtual in "GCTracer"
>>> to enable
>>> "YoungGCTracer" to send the young GC event when "report_gc_end" was
>>> called on a
>>> GCTracer, as in the following:
>>>
>>>      void GCTracer::report_gc_end(...) {
>>>        // do other stuff
>>>        report_gc_end_impl(...);
>>>      }
>>>
>>>      void YoungGCTracer::report_gc_end_impl(...) {
>>>        // send young gc event here
>>>      }
>>>
>>> In this change, YoungGCTracer now has a method "report_young_gc_end"
>>> that is
>>> virtual and that G1NewTracer overrides. This means that YoungGCTracer
>>> does not
>>> need to override the method "report_gc_end_impl" from GCTracer. This
>>> also means
>>> that all young collectors now also must call "report_young_gc_end".
>>>
>>> This change was needed, since report_young_gc_end must take the tenuring
>>> threshold as a parameter, something that was not possible to do with
>>> "report_gc_end_impl".
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8010916/webrev.00/
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010916
>>>
>>> Testing:
>>> JPRT
>>>
>>> Thanks,
>>> Erik
>


From jon.masamitsu at oracle.com  Thu Apr  4 04:00:38 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 03 Apr 2013 21:00:38 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
Message-ID: <515CFAE6.8010903@oracle.com>

After class unloading deallocate any VirtualSpaceNodes not being used.

When the classes for a dead class loader are unloaded, all the Metachunks
that had been used by that class loader are put on the Metachunk
free list for later reuse.   If all the Metachunks allocated out of a
VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
  from the free list and deallocate the VirtualSpaceNode.

The constructor for VirtualSpaceNode was moved to be below the definition of
SpaceManager.

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

Thanks.

Jon


From thomas.schatzl at oracle.com  Thu Apr  4 08:33:17 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 04 Apr 2013 10:33:17 +0200
Subject: Request for review (s) - NPG: Replace the ChunkList
	implementation with class FreeList<Metachunk>
In-Reply-To: <515AEE64.6070101@oracle.com>
References: <515A0673.9060407@oracle.com> <515AEE64.6070101@oracle.com>
Message-ID: <1365064397.2604.2.camel@cirrus>


Hi,

On Tue, 2013-04-02 at 16:42 +0200, Mikael Gerdin wrote:
> Jon,
> 
> On 2013-04-02 00:13, Jon Masamitsu wrote:
> > For the perm gen removal project the ChunkList class
> > which implemented a simple freelist of Metachunk's was added.
> > This change replaces ChunkList with FreeList<Metachunk>.
> >
> > Changes include
> >
> > - Deletion of ChunkList
> > - Code to initialize the freelists in the FreeList style
> > - Replacement of call to ChunkList methods with the
> > equivalent calls to FreeList methods.
> >
> > http://cr.openjdk.java.net/~jmasa/8011173
> 
> This looks like a good cleanup step.

Same here.

> The name FreeList is kind of a misnomer since it's actually just the 
> head of a generic linked list.

Noticed the same about the naming. Other than that, seems fine.

Thomas





From mikael.gerdin at oracle.com  Thu Apr  4 09:05:14 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 04 Apr 2013 11:05:14 +0200
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515AFCBC.60807@oracle.com>
References: <515A0673.9060407@oracle.com> <515AEE64.6070101@oracle.com>
	<515AFCBC.60807@oracle.com>
Message-ID: <515D424A.6060606@oracle.com>

Jon,

On 2013-04-02 17:43, Jon Masamitsu wrote:
> Mikael,
>
> Thanks for the review.
>
> On 04/02/13 07:42, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2013-04-02 00:13, Jon Masamitsu wrote:
>>> For the perm gen removal project the ChunkList class
>>> which implemented a simple freelist of Metachunk's was added.
>>> This change replaces ChunkList with FreeList<Metachunk>.
>>>
>>> Changes include
>>>
>>> - Deletion of ChunkList
>>> - Code to initialize the freelists in the FreeList style
>>> - Replacement of call to ChunkList methods with the
>>> equivalent calls to FreeList methods.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011173
>>
>> This looks like a good cleanup step.
>> I'm fine with you pushing this as is, these are just my thoughts about
>> the FreeList<> stuff.
>
> I have some other changes build on top these changes so I would
> like to push them with minimal changes.

I just noticed that you forgot to remove the comment

// ChunkList methods
at line 1385.
Fix it in this push or fix it with 8011268, I'm fine either way.

/Mikael

>
>>
>> Regarding your comment in ChunkManager::return_chunks I think it could
>> be resolved by making SpaceManager::_chunks_in_use[] into an array of
>> ChunkList, similar to ChunkManager::_free_chunks.
>
> I think something like this would work but as you note below FreeList is
> not really a freelist but
> just a list.  I hesitated to make _chunks_in_use a FreeList because it
> would confuse the casual
> reader.
>>
>> The name FreeList is kind of a misnomer since it's actually just the
>> head of a generic linked list.
>
> Yes the name is wrong.  There is actually a prepend() method that takes
> a FreeList and that
> is what I wanted to use  but the name "FreeList" stopped me.
>
>>
>> Maybe we should consider encapsulating the managing of the _next and
>> _prev fields only through the FreeList<> template by making the
>> setters to them private and friend:ing FreeList<Metachunk> in class
>> Metachunk and only ever letting FreeList manage the links?
>
> So I don't understand that.  I've created a CR for your suggested clean
> ups.
> 8011265   I'll think about that when I get to fixing this.
>
>>
>> It's confusing to have FreeList handle the links through link_prev and
>> link_next and other parts of the code using set_next and set_prev.
>
> link_prev() and link_next() have special meaning in CMS.  One or the
> other used to set
> the is_free bit in a CMS freelist.  It would be good to clean that up.
>
> Thanks again.
>
> Jon
>
>>
>> /Mikael
>>
>>
>>>
>>> Thanks.
>>>
>>> Jon


From bengt.rutisson at oracle.com  Thu Apr  4 06:30:34 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 04 Apr 2013 08:30:34 +0200
Subject: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during
	reference processing
In-Reply-To: <515B440F.9010008@oracle.com>
References: <20130319012113.3D86148231@hg.openjdk.java.net>
	<016101ce2fd6$a596bfb0$f0c43f10$@apache.org>
	<515B440F.9010008@oracle.com>
Message-ID: <515D1E0A.50105@oracle.com>


Uwe,

Thanks for verifying the fix! You really provided an excellent bug report.

John,

Great that you got this fixed so quickly! I like that you added the 
Lucene test to your testing portfolio. Is there any way we can add it to 
the common testing? I'm guessing that we don't have a lot of tests that 
stress the marking overflow handling since we didn't catch this in our 
internal testing. Are there any license issues with including the Lucene 
test in our nightly testing?

Thanks,
Bengt

On 4/2/13 10:48 PM, John Cuthbertson wrote:
> Hi Uwe,
>
> Thanks for the update. That is good to know. The bulk of the credit 
> goes to Bengt who did the initial diagnosis and the prototype fix.
>
> Thanks also for walking me through how to reproduce the issue. Once 
> the magic formula for the proxy was found - your instructions were 
> spot on. The tests were awesome as marking stress tests and uncovered 
> several issues associated with concurrent marking overflows. I've 
> added them to the set of tests I run for marking changes. :)
>
> Cheers,
>
> JohnC
>
> On 4/2/2013 12:16 PM, Uwe Schindler wrote:
>> Hi John,
>>
>> today I installed JDK8 b83 on one of the Jenkins build servers used 
>> by Apache Lucene: The problem with 32 bit JVMs and G1 collector is 
>> solved. I compared the trunk checkout of Lucene with both JVMs: In 
>> b82 it hangs, in b83 it passes. So I was able to re-enable 32 bit 
>> builds without the extra workaround stacksize option again.
>>
>> Thanks for fixing this issue.
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> uschindler at apache.org
>> Apache Lucene PMC Member / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>> -----Original Message-----
>>> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-
>>> bounces at openjdk.java.net] On Behalf Of john.cuthbertson at oracle.com
>>> Sent: Tuesday, March 19, 2013 2:21 AM
>>> To: hotspot-gc-dev at openjdk.java.net
>>> Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
>>> during reference processing
>>>
>>> Changeset: fa08949fe0cb
>>> Author:    johnc
>>> Date:      2013-03-18 11:05 -0700
>>> URL:       http://hg.openjdk.java.net/hsx/hotspot-
>>> gc/hotspot/rev/fa08949fe0cb
>>>
>>> 8009536: G1: Apache Lucene hang during reference processing
>>> Summary: In CMTask::do_marking_step(), Skip offering termination and
>>> entering the first and second synchronization barriers if called 
>>> from a serial
>>> context, i.e. the VM thread.
>>> Reviewed-by: brutisso, tschatzl
>>>
>>> ! src/share/vm/gc_implementation/g1/concurrentMark.cpp
>>> ! src/share/vm/gc_implementation/g1/concurrentMark.hpp
>



From leonid.mesnik at oracle.com  Thu Apr  4 10:34:07 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Thu, 04 Apr 2013 14:34:07 +0400
Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests.
	Default shell for jtreg is bourne. thus failure
In-Reply-To: <515AAB8A.4060109@oracle.com>
References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com>
	<5151A2E3.60507@oracle.com> <51556105.2040900@oracle.com>
	<515AAB8A.4060109@oracle.com>
Message-ID: <515D571F.8070002@oracle.com>

Mikael

Here is updated webrev:
http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.2

Streams were redirected, toArray() was updated.

Leonid
On 04/02/2013 01:57 PM, Mikael Gerdin wrote:
> Leonid,
>
> On 2013-03-29 10:38, Leonid Mesnik wrote:
>> Hi
>>
>> Here is new version of test. (pass jprt)
>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.1/
>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.1/>
>
> Overall it looks good. The test is nicely specified and in a 
> controlled environment.
>
> Can you please make the test save the stdout/stderr of the launched 
> process and print it out in case of failure?
> If the launch fails with some exit code we won't know its cause. I 
> suggest something like:
> pb.redirectErrorStream(true)
> pb.redirectOutput("output.log")
>
> I also have one small comment in:
> args.toArray(externalVMopts)
>
> Even though it may be correct to pass exernalVMopts to toArray(T[]) it 
> looks a bit confusing.
> Can you please change it to either
> "toArray(new String[0])" or
> "toArray(new String[args.size()])"
>
> /Mikael
>
>>
>> See my comment inline.
>> On 03/26/2013 05:30 PM, Mikael Gerdin wrote:
>>> Leonid,
>>>
>>> On 2013-03-22 08:06, Leonid Mesnik wrote:
>>>> Could anyone please review this small test fix.
>>>>
>>>> Leonid
>>>> On 03/20/2013 04:16 PM, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> Could you please review fix for  8009808 TEST-BUG : test case is 
>>>>> using
>>>>> bash style tests. Default shell for jtreg is bourne. thus failure.
>>>>>
>>>>> I've completely rewritten test in java without major changes it test
>>>>> logic.
>>>>> I remove CMS so test could be run when CMS is not supported. Also I
>>>>> changed max memory to 128M to reduce memory load and increase number
>>>>> of GC log entries.
>>>
>>> Do you think it would be useful to run this test with different GCs?
>>> In that case you can pick up the test.vm.opts and test.java.opts
>>> system properties and add them to the java command line you launch.
>> I've added test.java.opts properties. They are used during testing to
>> set additional GC.
>>>
>>>>>
>>>>> Here is the link:
>>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/
>>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.0/> 
>>>>>
>>>>>
>>>
>>> Are you sure about this:
>>> static final File currentDirectory = new
>>> File(System.getProperty("user.dir"));
>>>
>>> isn't user.dir the home directory? Current directory should be just "."
>>> Something like new File(".").getAbsoluteFile() should give you the
>>> current work dir.
>> System.getProperty("user.dir") is current directory. However I changed
>> it to "." to make it more evident.
>>>
>>> What is the relation between "numberOfFiles" and "minutesToRun"??
>>> How do you know that running for 3 minutes will cause a log rotation?
>> I've updated test to invoke fullGC and estimate lower bound of needed
>> invocation. Now test check that exactly 3 logs are generated.
>>
>> Leonid
>>>
>>> I know that you've just adapted the existing test but it seems strange
>>> to me.
>>>
>>> /Mikael
>>>
>>>
>>>
>>>>
>>>>
>>
>>


-- 
Leonid Mesnik
JVM SQE



From mikael.gerdin at oracle.com  Thu Apr  4 11:57:52 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 04 Apr 2013 13:57:52 +0200
Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests.
	Default shell for jtreg is bourne. thus failure
In-Reply-To: <515D571F.8070002@oracle.com>
References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com>
	<5151A2E3.60507@oracle.com> <51556105.2040900@oracle.com>
	<515AAB8A.4060109@oracle.com> <515D571F.8070002@oracle.com>
Message-ID: <515D6AC0.7030502@oracle.com>

Leonid,

On 2013-04-04 12:34, Leonid Mesnik wrote:
> Mikael
>
> Here is updated webrev:
> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.2
>
> Streams were redirected, toArray() was updated.

Looks good to me.

/Mikael

>
> Leonid
> On 04/02/2013 01:57 PM, Mikael Gerdin wrote:
>> Leonid,
>>
>> On 2013-03-29 10:38, Leonid Mesnik wrote:
>>> Hi
>>>
>>> Here is new version of test. (pass jprt)
>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.1/
>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.1/>
>>
>> Overall it looks good. The test is nicely specified and in a
>> controlled environment.
>>
>> Can you please make the test save the stdout/stderr of the launched
>> process and print it out in case of failure?
>> If the launch fails with some exit code we won't know its cause. I
>> suggest something like:
>> pb.redirectErrorStream(true)
>> pb.redirectOutput("output.log")
>>
>> I also have one small comment in:
>> args.toArray(externalVMopts)
>>
>> Even though it may be correct to pass exernalVMopts to toArray(T[]) it
>> looks a bit confusing.
>> Can you please change it to either
>> "toArray(new String[0])" or
>> "toArray(new String[args.size()])"
>>
>> /Mikael
>>
>>>
>>> See my comment inline.
>>> On 03/26/2013 05:30 PM, Mikael Gerdin wrote:
>>>> Leonid,
>>>>
>>>> On 2013-03-22 08:06, Leonid Mesnik wrote:
>>>>> Could anyone please review this small test fix.
>>>>>
>>>>> Leonid
>>>>> On 03/20/2013 04:16 PM, Leonid Mesnik wrote:
>>>>>> Hi
>>>>>>
>>>>>> Could you please review fix for  8009808 TEST-BUG : test case is
>>>>>> using
>>>>>> bash style tests. Default shell for jtreg is bourne. thus failure.
>>>>>>
>>>>>> I've completely rewritten test in java without major changes it test
>>>>>> logic.
>>>>>> I remove CMS so test could be run when CMS is not supported. Also I
>>>>>> changed max memory to 128M to reduce memory load and increase number
>>>>>> of GC log entries.
>>>>
>>>> Do you think it would be useful to run this test with different GCs?
>>>> In that case you can pick up the test.vm.opts and test.java.opts
>>>> system properties and add them to the java command line you launch.
>>> I've added test.java.opts properties. They are used during testing to
>>> set additional GC.
>>>>
>>>>>>
>>>>>> Here is the link:
>>>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/
>>>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.0/>
>>>>>>
>>>>>>
>>>>
>>>> Are you sure about this:
>>>> static final File currentDirectory = new
>>>> File(System.getProperty("user.dir"));
>>>>
>>>> isn't user.dir the home directory? Current directory should be just "."
>>>> Something like new File(".").getAbsoluteFile() should give you the
>>>> current work dir.
>>> System.getProperty("user.dir") is current directory. However I changed
>>> it to "." to make it more evident.
>>>>
>>>> What is the relation between "numberOfFiles" and "minutesToRun"??
>>>> How do you know that running for 3 minutes will cause a log rotation?
>>> I've updated test to invoke fullGC and estimate lower bound of needed
>>> invocation. Now test check that exactly 3 logs are generated.
>>>
>>> Leonid
>>>>
>>>> I know that you've just adapted the existing test but it seems strange
>>>> to me.
>>>>
>>>> /Mikael
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>
>>>
>
>


From bengt.rutisson at oracle.com  Thu Apr  4 12:11:21 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 04 Apr 2013 14:11:21 +0200
Subject: RFE (m) (Prelminary): JDK-7197666: java -d64 -version core dumps
	in a box with lots of memory
In-Reply-To: <1364549625.2821.34.camel@cirrus>
References: <5154BF9A.2080208@oracle.com> <1364549625.2821.34.camel@cirrus>
Message-ID: <515D6DE9.9010804@oracle.com>


Hi Thomas,

Thanks for looking at this!

On 3/29/13 10:33 AM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2013-03-28 at 23:09 +0100, Bengt Rutisson wrote:
>> Hi all,
>>
>> Sending this to both runtime and GC since I think it concerns both
>> areas.
>>
>> I'd like some feedback on this preliminary change. I still want to do
>> some more testing and evaluation before I ask for final reviews:
>>
>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>>
>> In particular I would like some feedback on these questions:
>>
>> - The class I am adding, ArrayAllocator, wants to choose between doing
>> malloc and mmap. Normally we use ReservedSpace and VirtualSpace to get
>> mapped memory. However, those classes are kind of clumsy when I just
>> want to allocate one chunk of memory. It is much simpler to use the
>> os::reserve_memory() and os::commit_memory() methods directly. I think
>> my use case here motivate using these methods directly, but is there
>> some reason not to do that?
> The *Space classes are heavily geared to be used as virtual memory
> management helpers for a two-generation heap, so I'm not sure if they
> are appropriate here.
>
> Not sure why you chose to use AllocateHeap(), I always thought that the
> use of the corresponding macros (NEW_C_HEAP_ARRAY etc.) is recommended.

The reason I use AllocateHeap() directly is that I already have the size 
calculated and if I use NEW_C_HEAP_ARRAY it would have to do that 
calculation again.

> The error messages of ArrayAllocator give very little information, maybe
> add the requested block size that lead to the failure in the message.

The requested size is part of the error message. Is there more you would 
like to have in the message? Currently it looks like this:

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 1048576 bytes for 
Allocator failed to commit

I admit that this message is not perfect. First it says "(malloc)" even 
though it was actually mmap that failed. But this is I think more of a 
bug in vm_exit_out_of_memory() than in my use of it. There are several 
places that use VirtualSpace and when it fails call 
vm_exit_out_of_memory(). This has the same issue as my code. For example 
when we try to expand the heap in G1 with G1CollectedHeap::expand()

I also think the last part of the message looks a bit odd now that I see 
the whole message. But I would like to know if it was reserve or commit 
that failed. Do you think I should change to "Allocator (reserve)" and 
"Allocator (commit)" instead?

> There is a typo in the comment "uses malpped memory" -> "uses mapped
> memory".

Thanks! Fixed.

> While it is not strictly necessary, you could initialize all member
> variables in the constructor's initialization list.

OK. Done.

>
> Maybe there is a common name for such type of objects, i.e. cleanup
> helpers that are "stack allocated" only to be automatically called
> during destructor of the enclosing class in c++ jargon.
> It seems to be a common pattern.
>
> If that is not the case, maybe rename it to LargeArrayAllocator to
> better indicate the purpose in addition to the comment.

I don't really like LargeArrayAllocator since this one can be used for 
arrays that can be both small and large. The whole idea is that when we 
have dynamic sizes we need a simple way to allocate both small and large 
arrays but get them allocated in the right way. That's why I picked just 
ArrayAllocator.

>> Some background on the change:
>>
>> The default implementation of malloc on Solaris has several limitation
>> compared to malloc on other platforms. One limitation is that it can
>> only use one consecutive chunk of memory. Another limitation is that
>> it always allocates in this single chunk of memory no matter how large
>> the requested amount of memory is. Other malloc implementations
>> normally use mapped memory for large allocations.
>>
>> The Java heap is mapped in memory and we try to pick a good address
>> for it. The lowest allowed address is controlled by
>> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other
>> platforms have at least 2 GB). Since the C heap ends up below the Java
>> heap it means that in some cases it is limited to 256 MB.
> 256 MB seems to be very low in any case. Maybe in addition to that, make
> HeapBaseMinAddress dependent on the OS?

HeapBaseMinAddress is already dependent on the OS. It is explicitly set 
to 256MB on Solaris x86 and at least 2GB on all other platforms. We want 
to keep it to 256MB on Solaris x86 to be able to use as large heaps as 
possible for compressed oops.

>
> Is there some documentation/FAQ that tells solaris/x86 users to consider
> increasing HeapBaseMinAddress if they run out of C heap?

That's a good point. I can talk to SE about how they would like to 
communicate this to users.

Thanks,
Bengt

> Thomas
>



From bengt.rutisson at oracle.com  Thu Apr  4 12:17:08 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 04 Apr 2013 14:17:08 +0200
Subject: RFE (m): JDK-7197666: java -d64 -version core dumps in a box
	with lots of memory
In-Reply-To: <5154BF9A.2080208@oracle.com>
References: <5154BF9A.2080208@oracle.com>
Message-ID: <515D6F44.4050909@oracle.com>


Hi all,

Coleen and Thomas have already looked at the preliminary version of this 
request. Thanks!

Removing the preliminary part of this request now and asking for full 
reviews.

Here is an updated webrev based on the comments from Coleen and Thomas:

http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/

Thanks,
Bengt


On 3/28/13 11:09 PM, Bengt Rutisson wrote:
>
> Hi all,
>
> Sending this to both runtime and GC since I think it concerns both areas.
>
> I'd like some feedback on this preliminary change. I still want to do 
> some more testing and evaluation before I ask for final reviews:
>
> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>
> In particular I would like some feedback on these questions:
>
> - I am adding a flag that has the same value on all platforms except 
> Solaris x86. There is the product_pd flag macro to support this. But 
> there is no experimental_pd marcro. I would have preferred to make my 
> new flag experimental. Should I add experimental_pd or should I just 
> use a product flag?
>
> - Even with product_pd I think I still have to go in to all the 
> different platform files and add the exact same code to give the flag 
> a default value on all platforms. Is there a way to have a default 
> value and only override it on Solaris x86?
>
> - The class I am adding, ArrayAllocator, wants to choose between doing 
> malloc and mmap. Normally we use ReservedSpace and VirtualSpace to get 
> mapped memory. However, those classes are kind of clumsy when I just 
> want to allocate one chunk of memory. It is much simpler to use the 
> os::reserve_memory() and os::commit_memory() methods directly. I think 
> my use case here motivate using these methods directly, but is there 
> some reason not to do that?
>
> Some background on the change:
>
> The default implementation of malloc on Solaris has several limitation 
> compared to malloc on other platforms. One limitation is that it can 
> only use one consecutive chunk of memory. Another limitation is that 
> it always allocates in this single chunk of memory no matter how large 
> the requested amount of memory is. Other malloc implementations 
> normally use mapped memory for large allocations.
>
> The Java heap is mapped in memory and we try to pick a good address 
> for it. The lowest allowed address is controlled by 
> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other 
> platforms have at least 2 GB). Since the C heap ends up below the Java 
> heap it means that in some cases it is limited to 256 MB.
>
> When we run with ParallelOldGC we get three task queues per GC thread. 
> Each task queue takes mallocs 1MB. The failing machine in the bug 
> report has lots of CPUs and ends up with 83 GC threads. This is 249 
> MB, which is more than we can get out of the 256 MB limited C heap 
> considering that there are other things that get malloced too.
>
> So, the problems occur mostly on Solaris x86. My suggested fix tries 
> to address this by letting the task queues be mapped instead of 
> malloced on Solaris x86. Instead of inlining this logic in 
> taskqueue.cpp I added a more general class. The reason for this is 
> that I think we need to use the same logic in more places, especially 
> for G1, which is mallocing quite a lot.
>
> Since I think malloc on other platforms use mapped memory for large 
> malloc requests I think it is enough for this change to have effect on 
> Solaris. The other platforms probably have better heuristics than I 
> can come up with for which sizes should be mapped. On Sparc we have 
> the same limitation with malloc, but we have more memory available for 
> the C heap. This is why I have only enabled this for Solaris x86.
>
> Also, I will be on vacation for a few days. Back in the office 
> Thrusday April 4. I'm happy for any feedback on this, but if I don't 
> respond until next week you know why :)
>
> Thanks,
> Bengt

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

From mikael.gerdin at oracle.com  Thu Apr  4 12:28:19 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 04 Apr 2013 14:28:19 +0200
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515CFAE6.8010903@oracle.com>
References: <515CFAE6.8010903@oracle.com>
Message-ID: <515D71E3.9000300@oracle.com>

Jon,

On 2013-04-04 06:00, Jon Masamitsu wrote:
> After class unloading deallocate any VirtualSpaceNodes not being used.

The webrev is a bit confusing since it says for metaspace.cpp:
rev 4373 : 8011173: NPG: Replace the ChunkList implementation with class 
FreeList<Metachunk>
Reviewed-by: mgerdin

this implies to me that the 8011173 patch is included in this webrev 
when in fact this webrev is incremental on top of that patch.
I don't know if that was intentional or not but it confused me a bit 
when trying to apply this patch.

I'm totally fine with incremental webrevs though, just as long as they 
are advertised as such :)

>
> When the classes for a dead class loader are unloaded, all the Metachunks
> that had been used by that class loader are put on the Metachunk
> free list for later reuse.   If all the Metachunks allocated out of a
> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>   from the free list and deallocate the VirtualSpaceNode.
>
> The constructor for VirtualSpaceNode was moved to be below the
> definition of
> SpaceManager.

I'm not sure why you moved the VirtualSpaceNode constructor to after the 
definition of SpaceManager, but I see that {inc,dec}_container_count 
need to reference the expand_lock().

Also, when I applied your patch and looked at the code in eclipse it 
helpfully notified me that you are forgetting to initialize 
_container_count in the VirtualSpaceNode constructor that you moved.

Why don't you set the Metachunk::_container field in 
Metachunk::initialize():

  776   // Point the chunk at the space
  777   Metachunk* result = Metachunk::initialize(chunk_limit, 
chunk_word_size);
  778   return result;

  It's called from VirtualSpaceNode so you should be able to pass "this" 
along to Metachunk::initialize. That will save us the walking of 
VirtualSpaceList to find the correct node to increment the count for.

If you set up Metachunk::_container in Metachunk::_initialize you could 
also skip the wrapper for ChunkManager::chunk_freelist_allocate inside 
VirtualSpaceList and just add:

if (next != NULL) {
   next->container()->inc_container_count();
}
at the end of VirtualSpaceList::get_new_chunk

You are not decreasing the _container_count when returning humongous 
chunks in ~SpaceManager:
2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
// here you could do a
humongous_chunks->container()->dec_container_count();
2124 
chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);

You are already incrementing _container_count for humongous chunks 
allocated from the hum chunk free list because those allocations go 
through the chunk_freelist_allocate wrapper function you added.

It also feels strange that inc_container_count() is private but 
dec_container_count and container_count() are public. I realize that it 
works currently because VirtualSpaceList is a friend of VirtualSpaceNode 
but it seems like a strange level of encapsulation.


The class space only contains one VirtualSpaceNode currently, should we 
add some code to make sure that we don't accidentally free that memory?

/Mikael

>
> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>
> Thanks.
>
> Jon


From bengt.rutisson at oracle.com  Thu Apr  4 13:47:25 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 04 Apr 2013 15:47:25 +0200
Subject: RFR(S): 8011343: Add new flag for verifying the heap during
	startup
In-Reply-To: <515B6A73.2060602@oracle.com>
References: <515B6A73.2060602@oracle.com>
Message-ID: <515D846D.5030701@oracle.com>


Hi John,

Thanks for fixing this!

Looks good!
Bengt

On 4/3/13 1:32 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of reviews for this change please? The webrev can 
> be found at: http://cr.openjdk.java.net/~johnc/8011343/webrev.0/
>
> Summary:
> During the code review for 8010463 it was suggested that the 
> verification that is performed during VM startup should be done under 
> control of a new flag rather than piggy-backing off the VerifyBeforeGC 
> flag. In response to another comment I suggested that the verification 
> should be done using a VM Operation so as to maximize the verification 
> (certain parts of the G1 heap are skipped if the verification is not 
> performed at a safepoint).
>
> These changes address these comments.
>
> Testing:
> GC test suite with the new flag
> jprt with the new flag (this configuration saw some failures that are 
> caused by the issue described in 8010943)
> jtreg with the changed regression test
>
> Note: I think the warning(s) emitted from arguments.cpp when 
> FLSVerifyAllHeapReferences is enabled can be removed (now that 
> verification is performed at a safepoint) but I am loathe to do so. 
> Testing this configuration resulted in some assertion failures (even 
> with a new workspace) that I'll be submitting another CR for.
>
> Thanks,
>
> JohnC
>
>



From jesper.wilhelmsson at oracle.com  Thu Apr  4 14:04:20 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 04 Apr 2013 16:04:20 +0200
Subject: RFR: 8009032 - Implement evacuation info event
Message-ID: <515D8864.6070209@oracle.com>

Hi,

I'm looking for a couple of reviews for this change.

This is an tracing event with information about G1 evacuation/compaction. It 
contains the number of regions in from-space and to-space, how much data that 
was used before and after, the number of bytes copied during the 
evacuation/compaction, and how many regions that was completely freed during an 
evacuation.

Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/


The patch also contains a bunch of fixed typos in various comments nearby the 
relevant changes. These may add some noise to the webrev, if you prefer to look 
at the webrev without these changes a separate webrev is available here:

Webrev without typo fixes:
  http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/


Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032

Thanks,
/Jesper


From john.cuthbertson at oracle.com  Thu Apr  4 16:55:36 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 09:55:36 -0700
Subject: RFR(S): 8011343: Add new flag for verifying the heap during
	startup
In-Reply-To: <515BDCD9.4080101@oracle.com>
References: <515B6A73.2060602@oracle.com> <515BDCD9.4080101@oracle.com>
Message-ID: <515DB088.50000@oracle.com>

Hi Stefan,

Thanks for taking a look.

JohnC

On 4/3/2013 12:40 AM, Stefan Karlsson wrote:
> Looks good to me.
>
> StefanK
>
> On 04/03/2013 01:32 AM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of reviews for this change please? The webrev can 
>> be found at: http://cr.openjdk.java.net/~johnc/8011343/webrev.0/
>>
>> Summary:
>> During the code review for 8010463 it was suggested that the 
>> verification that is performed during VM startup should be done under 
>> control of a new flag rather than piggy-backing off the 
>> VerifyBeforeGC flag. In response to another comment I suggested that 
>> the verification should be done using a VM Operation so as to 
>> maximize the verification (certain parts of the G1 heap are skipped 
>> if the verification is not performed at a safepoint).
>>
>> These changes address these comments.
>>
>> Testing:
>> GC test suite with the new flag
>> jprt with the new flag (this configuration saw some failures that are 
>> caused by the issue described in 8010943)
>> jtreg with the changed regression test
>>
>> Note: I think the warning(s) emitted from arguments.cpp when 
>> FLSVerifyAllHeapReferences is enabled can be removed (now that 
>> verification is performed at a safepoint) but I am loathe to do so. 
>> Testing this configuration resulted in some assertion failures (even 
>> with a new workspace) that I'll be submitting another CR for.
>>
>> Thanks,
>>
>> JohnC
>>
>>
>



From john.cuthbertson at oracle.com  Thu Apr  4 16:57:38 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 09:57:38 -0700
Subject: RFR(S): 8011343: Add new flag for verifying the heap during
	startup
In-Reply-To: <515D846D.5030701@oracle.com>
References: <515B6A73.2060602@oracle.com> <515D846D.5030701@oracle.com>
Message-ID: <515DB102.9090101@oracle.com>

Hi Bengt,

Thanks for looking the changes over.

JohnC

On 4/4/2013 6:47 AM, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for fixing this!
>
> Looks good!
> Bengt
>
> On 4/3/13 1:32 AM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of reviews for this change please? The webrev can 
>> be found at: http://cr.openjdk.java.net/~johnc/8011343/webrev.0/
>>
>> Summary:
>> During the code review for 8010463 it was suggested that the 
>> verification that is performed during VM startup should be done under 
>> control of a new flag rather than piggy-backing off the 
>> VerifyBeforeGC flag. In response to another comment I suggested that 
>> the verification should be done using a VM Operation so as to 
>> maximize the verification (certain parts of the G1 heap are skipped 
>> if the verification is not performed at a safepoint).
>>
>> These changes address these comments.
>>
>> Testing:
>> GC test suite with the new flag
>> jprt with the new flag (this configuration saw some failures that are 
>> caused by the issue described in 8010943)
>> jtreg with the changed regression test
>>
>> Note: I think the warning(s) emitted from arguments.cpp when 
>> FLSVerifyAllHeapReferences is enabled can be removed (now that 
>> verification is performed at a safepoint) but I am loathe to do so. 
>> Testing this configuration resulted in some assertion failures (even 
>> with a new workspace) that I'll be submitting another CR for.
>>
>> Thanks,
>>
>> JohnC
>>
>>
>



From john.cuthbertson at oracle.com  Thu Apr  4 17:11:50 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 10:11:50 -0700
Subject: RFE (m): JDK-7197666: java -d64 -version core dumps in a box
	with lots of memory
In-Reply-To: <515D6F44.4050909@oracle.com>
References: <5154BF9A.2080208@oracle.com> <515D6F44.4050909@oracle.com>
Message-ID: <515DB456.6020904@oracle.com>

Hi Bengt,

This looks good. One minor nit: the comment in allocation.hpp is 
slightly inconsistent with the setting of the malloc limit in 
globals.hpp. The limit will be 64K on sparc as well.

Thanks for doing this. We/I can use this to reduce malloc usage for some 
other large mallocs.

JohnC

On 4/4/2013 5:17 AM, Bengt Rutisson wrote:
>
> Hi all,
>
> Coleen and Thomas have already looked at the preliminary version of 
> this request. Thanks!
>
> Removing the preliminary part of this request now and asking for full 
> reviews.
>
> Here is an updated webrev based on the comments from Coleen and Thomas:
>
> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/
>
> Thanks,
> Bengt
>
>
> On 3/28/13 11:09 PM, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Sending this to both runtime and GC since I think it concerns both areas.
>>
>> I'd like some feedback on this preliminary change. I still want to do 
>> some more testing and evaluation before I ask for final reviews:
>>
>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>>
>> In particular I would like some feedback on these questions:
>>
>> - I am adding a flag that has the same value on all platforms except 
>> Solaris x86. There is the product_pd flag macro to support this. But 
>> there is no experimental_pd marcro. I would have preferred to make my 
>> new flag experimental. Should I add experimental_pd or should I just 
>> use a product flag?
>>
>> - Even with product_pd I think I still have to go in to all the 
>> different platform files and add the exact same code to give the flag 
>> a default value on all platforms. Is there a way to have a default 
>> value and only override it on Solaris x86?
>>
>> - The class I am adding, ArrayAllocator, wants to choose between 
>> doing malloc and mmap. Normally we use ReservedSpace and VirtualSpace 
>> to get mapped memory. However, those classes are kind of clumsy when 
>> I just want to allocate one chunk of memory. It is much simpler to 
>> use the os::reserve_memory() and os::commit_memory() methods 
>> directly. I think my use case here motivate using these methods 
>> directly, but is there some reason not to do that?
>>
>> Some background on the change:
>>
>> The default implementation of malloc on Solaris has several 
>> limitation compared to malloc on other platforms. One limitation is 
>> that it can only use one consecutive chunk of memory. Another 
>> limitation is that it always allocates in this single chunk of memory 
>> no matter how large the requested amount of memory is. Other malloc 
>> implementations normally use mapped memory for large allocations.
>>
>> The Java heap is mapped in memory and we try to pick a good address 
>> for it. The lowest allowed address is controlled by 
>> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other 
>> platforms have at least 2 GB). Since the C heap ends up below the 
>> Java heap it means that in some cases it is limited to 256 MB.
>>
>> When we run with ParallelOldGC we get three task queues per GC 
>> thread. Each task queue takes mallocs 1MB. The failing machine in the 
>> bug report has lots of CPUs and ends up with 83 GC threads. This is 
>> 249 MB, which is more than we can get out of the 256 MB limited C 
>> heap considering that there are other things that get malloced too.
>>
>> So, the problems occur mostly on Solaris x86. My suggested fix tries 
>> to address this by letting the task queues be mapped instead of 
>> malloced on Solaris x86. Instead of inlining this logic in 
>> taskqueue.cpp I added a more general class. The reason for this is 
>> that I think we need to use the same logic in more places, especially 
>> for G1, which is mallocing quite a lot.
>>
>> Since I think malloc on other platforms use mapped memory for large 
>> malloc requests I think it is enough for this change to have effect 
>> on Solaris. The other platforms probably have better heuristics than 
>> I can come up with for which sizes should be mapped. On Sparc we have 
>> the same limitation with malloc, but we have more memory available 
>> for the C heap. This is why I have only enabled this for Solaris x86.
>>
>> Also, I will be on vacation for a few days. Back in the office 
>> Thrusday April 4. I'm happy for any feedback on this, but if I don't 
>> respond until next week you know why :)
>>
>> Thanks,
>> Bengt
>

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

From john.cuthbertson at oracle.com  Thu Apr  4 17:20:35 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 10:20:35 -0700
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515A0673.9060407@oracle.com>
References: <515A0673.9060407@oracle.com>
Message-ID: <515DB663.2000900@oracle.com>

Hi Jon,

This looks good to me.

JohnC

On 4/1/2013 3:13 PM, Jon Masamitsu wrote:
> For the perm gen removal project the ChunkList class
> which implemented a simple freelist of Metachunk's was added.
> This change replaces ChunkList with FreeList<Metachunk>.
>
> Changes include
>
> - Deletion of ChunkList
> - Code to initialize the freelists in the FreeList style
> - Replacement of call to ChunkList methods with the
> equivalent calls to FreeList methods.
>
> http://cr.openjdk.java.net/~jmasa/8011173
>
> Thanks.
>
> Jon



From john.cuthbertson at oracle.com  Thu Apr  4 17:29:01 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 10:29:01 -0700
Subject: HeapRegionRemSetIterator question
Message-ID: <515DB85D.8020001@oracle.com>

Hi Everyone,

I've been looking at G1's HeapRegionRemSetIterator and I was wondering 
if anyone knows why we pre-allocate instances of the iterator during 
startup and then initalize them repeatedly when RSet scanning claims new 
regions? I don't see much difference between this and stack allocating 
new instances - other than saving the initialization of one or two 
fields. Is there any reason not to stack allocate the iterator instances?

Thanks,

JohnC


From john.cuthbertson at oracle.com  Thu Apr  4 18:02:24 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 11:02:24 -0700
Subject: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during
	reference processing
In-Reply-To: <515D1E0A.50105@oracle.com>
References: <20130319012113.3D86148231@hg.openjdk.java.net>
	<016101ce2fd6$a596bfb0$f0c43f10$@apache.org>
	<515B440F.9010008@oracle.com> <515D1E0A.50105@oracle.com>
Message-ID: <515DC030.9030003@oracle.com>

Hi Bengt,

I'm not sure. I don't think we want to make the GC test suite dependent 
on ant and ivy (currently you only need shell and a jdk to run them). At 
the moment I'm running the command Uwe gave by hand .

But it would be great to be able to run them consistently.

Uwe:  do you think there would be any licensing issues?

JohnC

On 4/3/2013 11:30 PM, Bengt Rutisson wrote:
>
> Uwe,
>
> Thanks for verifying the fix! You really provided an excellent bug 
> report.
>
> John,
>
> Great that you got this fixed so quickly! I like that you added the 
> Lucene test to your testing portfolio. Is there any way we can add it 
> to the common testing? I'm guessing that we don't have a lot of tests 
> that stress the marking overflow handling since we didn't catch this 
> in our internal testing. Are there any license issues with including 
> the Lucene test in our nightly testing?
>
> Thanks,
> Bengt
>
> On 4/2/13 10:48 PM, John Cuthbertson wrote:
>> Hi Uwe,
>>
>> Thanks for the update. That is good to know. The bulk of the credit 
>> goes to Bengt who did the initial diagnosis and the prototype fix.
>>
>> Thanks also for walking me through how to reproduce the issue. Once 
>> the magic formula for the proxy was found - your instructions were 
>> spot on. The tests were awesome as marking stress tests and uncovered 
>> several issues associated with concurrent marking overflows. I've 
>> added them to the set of tests I run for marking changes. :)
>>
>> Cheers,
>>
>> JohnC
>>
>> On 4/2/2013 12:16 PM, Uwe Schindler wrote:
>>> Hi John,
>>>
>>> today I installed JDK8 b83 on one of the Jenkins build servers used 
>>> by Apache Lucene: The problem with 32 bit JVMs and G1 collector is 
>>> solved. I compared the trunk checkout of Lucene with both JVMs: In 
>>> b82 it hangs, in b83 it passes. So I was able to re-enable 32 bit 
>>> builds without the extra workaround stacksize option again.
>>>
>>> Thanks for fixing this issue.
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> uschindler at apache.org
>>> Apache Lucene PMC Member / Committer
>>> Bremen, Germany
>>> http://lucene.apache.org/
>>>
>>>> -----Original Message-----
>>>> From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-
>>>> bounces at openjdk.java.net] On Behalf Of john.cuthbertson at oracle.com
>>>> Sent: Tuesday, March 19, 2013 2:21 AM
>>>> To: hotspot-gc-dev at openjdk.java.net
>>>> Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
>>>> during reference processing
>>>>
>>>> Changeset: fa08949fe0cb
>>>> Author:    johnc
>>>> Date:      2013-03-18 11:05 -0700
>>>> URL:       http://hg.openjdk.java.net/hsx/hotspot-
>>>> gc/hotspot/rev/fa08949fe0cb
>>>>
>>>> 8009536: G1: Apache Lucene hang during reference processing
>>>> Summary: In CMTask::do_marking_step(), Skip offering termination and
>>>> entering the first and second synchronization barriers if called 
>>>> from a serial
>>>> context, i.e. the VM thread.
>>>> Reviewed-by: brutisso, tschatzl
>>>>
>>>> ! src/share/vm/gc_implementation/g1/concurrentMark.cpp
>>>> ! src/share/vm/gc_implementation/g1/concurrentMark.hpp
>>
>



From jon.masamitsu at oracle.com  Thu Apr  4 19:07:15 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 04 Apr 2013 12:07:15 -0700
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <1365064397.2604.2.camel@cirrus>
References: <515A0673.9060407@oracle.com> <515AEE64.6070101@oracle.com>
	<1365064397.2604.2.camel@cirrus>
Message-ID: <515DCF63.40802@oracle.com>

Thomas,

Thanks for look the review.

On 4/4/13 1:33 AM, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2013-04-02 at 16:42 +0200, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2013-04-02 00:13, Jon Masamitsu wrote:
>>> For the perm gen removal project the ChunkList class
>>> which implemented a simple freelist of Metachunk's was added.
>>> This change replaces ChunkList with FreeList<Metachunk>.
>>>
>>> Changes include
>>>
>>> - Deletion of ChunkList
>>> - Code to initialize the freelists in the FreeList style
>>> - Replacement of call to ChunkList methods with the
>>> equivalent calls to FreeList methods.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011173
>> This looks like a good cleanup step.
> Same here.
>
>> The name FreeList is kind of a misnomer since it's actually just the
>> head of a generic linked list.
> Noticed the same about the naming. Other than that, seems fine.

Yes, wrong name.  I filed 8011265 to fix it.

Jon
>
> Thomas
>
>
>



From jon.masamitsu at oracle.com  Thu Apr  4 19:15:30 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 04 Apr 2013 12:15:30 -0700
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515D424A.6060606@oracle.com>
References: <515A0673.9060407@oracle.com> <515AEE64.6070101@oracle.com>
	<515AFCBC.60807@oracle.com> <515D424A.6060606@oracle.com>
Message-ID: <515DD152.9080605@oracle.com>

On 4/4/13 2:05 AM, Mikael Gerdin wrote:
> Jon,
>
> On 2013-04-02 17:43, Jon Masamitsu wrote:
>> Mikael,
>>
>> Thanks for the review.
>>
>> On 04/02/13 07:42, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2013-04-02 00:13, Jon Masamitsu wrote:
>>>> For the perm gen removal project the ChunkList class
>>>> which implemented a simple freelist of Metachunk's was added.
>>>> This change replaces ChunkList with FreeList<Metachunk>.
>>>>
>>>> Changes include
>>>>
>>>> - Deletion of ChunkList
>>>> - Code to initialize the freelists in the FreeList style
>>>> - Replacement of call to ChunkList methods with the
>>>> equivalent calls to FreeList methods.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8011173
>>>
>>> This looks like a good cleanup step.
>>> I'm fine with you pushing this as is, these are just my thoughts about
>>> the FreeList<> stuff.
>>
>> I have some other changes build on top these changes so I would
>> like to push them with minimal changes.
>
> I just noticed that you forgot to remove the comment
>
> // ChunkList methods
> at line 1385.
> Fix it in this push or fix it with 8011268, I'm fine either way.

Fixed it in this patch.  It was simple enough that mercurial didn't reject
the following qpush :-)

Thanks again.

Jon
>
> /Mikael
>
>>
>>>
>>> Regarding your comment in ChunkManager::return_chunks I think it could
>>> be resolved by making SpaceManager::_chunks_in_use[] into an array of
>>> ChunkList, similar to ChunkManager::_free_chunks.
>>
>> I think something like this would work but as you note below FreeList is
>> not really a freelist but
>> just a list.  I hesitated to make _chunks_in_use a FreeList because it
>> would confuse the casual
>> reader.
>>>
>>> The name FreeList is kind of a misnomer since it's actually just the
>>> head of a generic linked list.
>>
>> Yes the name is wrong.  There is actually a prepend() method that takes
>> a FreeList and that
>> is what I wanted to use  but the name "FreeList" stopped me.
>>
>>>
>>> Maybe we should consider encapsulating the managing of the _next and
>>> _prev fields only through the FreeList<> template by making the
>>> setters to them private and friend:ing FreeList<Metachunk> in class
>>> Metachunk and only ever letting FreeList manage the links?
>>
>> So I don't understand that.  I've created a CR for your suggested clean
>> ups.
>> 8011265   I'll think about that when I get to fixing this.
>>
>>>
>>> It's confusing to have FreeList handle the links through link_prev and
>>> link_next and other parts of the code using set_next and set_prev.
>>
>> link_prev() and link_next() have special meaning in CMS.  One or the
>> other used to set
>> the is_free bit in a CMS freelist.  It would be good to clean that up.
>>
>> Thanks again.
>>
>> Jon
>>
>>>
>>> /Mikael
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Jon



From jon.masamitsu at oracle.com  Thu Apr  4 21:38:13 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 04 Apr 2013 14:38:13 -0700
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515DB663.2000900@oracle.com>
References: <515A0673.9060407@oracle.com> <515DB663.2000900@oracle.com>
Message-ID: <515DF2C5.9070401@oracle.com>

On 4/4/13 10:20 AM, John Cuthbertson wrote:

Thanks.

Jon
> Hi Jon,
>
> This looks good to me.
>
> JohnC
>
> On 4/1/2013 3:13 PM, Jon Masamitsu wrote:
>> For the perm gen removal project the ChunkList class
>> which implemented a simple freelist of Metachunk's was added.
>> This change replaces ChunkList with FreeList<Metachunk>.
>>
>> Changes include
>>
>> - Deletion of ChunkList
>> - Code to initialize the freelists in the FreeList style
>> - Replacement of call to ChunkList methods with the
>> equivalent calls to FreeList methods.
>>
>> http://cr.openjdk.java.net/~jmasa/8011173
>>
>> Thanks.
>>
>> Jon
>



From coleen.phillimore at oracle.com  Thu Apr  4 21:50:17 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 04 Apr 2013 17:50:17 -0400
Subject: Request for review (s) - NPG: Replace the ChunkList implementation
	with class FreeList<Metachunk>
In-Reply-To: <515DF2C5.9070401@oracle.com>
References: <515A0673.9060407@oracle.com> <515DB663.2000900@oracle.com>
	<515DF2C5.9070401@oracle.com>
Message-ID: <515DF599.6030900@oracle.com>

This looks good!
Coleen

On 04/04/2013 05:38 PM, Jon Masamitsu wrote:
> On 4/4/13 10:20 AM, John Cuthbertson wrote:
>
> Thanks.
>
> Jon
>> Hi Jon,
>>
>> This looks good to me.
>>
>> JohnC
>>
>> On 4/1/2013 3:13 PM, Jon Masamitsu wrote:
>>> For the perm gen removal project the ChunkList class
>>> which implemented a simple freelist of Metachunk's was added.
>>> This change replaces ChunkList with FreeList<Metachunk>.
>>>
>>> Changes include
>>>
>>> - Deletion of ChunkList
>>> - Code to initialize the freelists in the FreeList style
>>> - Replacement of call to ChunkList methods with the
>>> equivalent calls to FreeList methods.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011173
>>>
>>> Thanks.
>>>
>>> Jon
>>
>



From jon.masamitsu at oracle.com  Thu Apr  4 19:54:29 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 04 Apr 2013 12:54:29 -0700
Subject: RFE (m): JDK-7197666: java -d64 -version core dumps in a box
	with lots of memory
In-Reply-To: <515D6F44.4050909@oracle.com>
References: <5154BF9A.2080208@oracle.com> <515D6F44.4050909@oracle.com>
Message-ID: <515DDA75.1090707@oracle.com>

Bengt,

http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/src/share/vm/memory/allocation.inline.hpp.frames.html

  118   if (_use_malloc) {
  119     _addr = AllocateHeap(_size, F);
  120     return (E*)_addr;
  121   }


Did you consider checking the value of _addr and going on
to the mmap based allocation if the malloc() failed?

Jon


On 4/4/13 5:17 AM, Bengt Rutisson wrote:
>
> Hi all,
>
> Coleen and Thomas have already looked at the preliminary version of 
> this request. Thanks!
>
> Removing the preliminary part of this request now and asking for full 
> reviews.
>
> Here is an updated webrev based on the comments from Coleen and Thomas:
>
> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/
>
> Thanks,
> Bengt
>
>
> On 3/28/13 11:09 PM, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Sending this to both runtime and GC since I think it concerns both areas.
>>
>> I'd like some feedback on this preliminary change. I still want to do 
>> some more testing and evaluation before I ask for final reviews:
>>
>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>>
>> In particular I would like some feedback on these questions:
>>
>> - I am adding a flag that has the same value on all platforms except 
>> Solaris x86. There is the product_pd flag macro to support this. But 
>> there is no experimental_pd marcro. I would have preferred to make my 
>> new flag experimental. Should I add experimental_pd or should I just 
>> use a product flag?
>>
>> - Even with product_pd I think I still have to go in to all the 
>> different platform files and add the exact same code to give the flag 
>> a default value on all platforms. Is there a way to have a default 
>> value and only override it on Solaris x86?
>>
>> - The class I am adding, ArrayAllocator, wants to choose between 
>> doing malloc and mmap. Normally we use ReservedSpace and VirtualSpace 
>> to get mapped memory. However, those classes are kind of clumsy when 
>> I just want to allocate one chunk of memory. It is much simpler to 
>> use the os::reserve_memory() and os::commit_memory() methods 
>> directly. I think my use case here motivate using these methods 
>> directly, but is there some reason not to do that?
>>
>> Some background on the change:
>>
>> The default implementation of malloc on Solaris has several 
>> limitation compared to malloc on other platforms. One limitation is 
>> that it can only use one consecutive chunk of memory. Another 
>> limitation is that it always allocates in this single chunk of memory 
>> no matter how large the requested amount of memory is. Other malloc 
>> implementations normally use mapped memory for large allocations.
>>
>> The Java heap is mapped in memory and we try to pick a good address 
>> for it. The lowest allowed address is controlled by 
>> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other 
>> platforms have at least 2 GB). Since the C heap ends up below the 
>> Java heap it means that in some cases it is limited to 256 MB.
>>
>> When we run with ParallelOldGC we get three task queues per GC 
>> thread. Each task queue takes mallocs 1MB. The failing machine in the 
>> bug report has lots of CPUs and ends up with 83 GC threads. This is 
>> 249 MB, which is more than we can get out of the 256 MB limited C 
>> heap considering that there are other things that get malloced too.
>>
>> So, the problems occur mostly on Solaris x86. My suggested fix tries 
>> to address this by letting the task queues be mapped instead of 
>> malloced on Solaris x86. Instead of inlining this logic in 
>> taskqueue.cpp I added a more general class. The reason for this is 
>> that I think we need to use the same logic in more places, especially 
>> for G1, which is mallocing quite a lot.
>>
>> Since I think malloc on other platforms use mapped memory for large 
>> malloc requests I think it is enough for this change to have effect 
>> on Solaris. The other platforms probably have better heuristics than 
>> I can come up with for which sizes should be mapped. On Sparc we have 
>> the same limitation with malloc, but we have more memory available 
>> for the C heap. This is why I have only enabled this for Solaris x86.
>>
>> Also, I will be on vacation for a few days. Back in the office 
>> Thrusday April 4. I'm happy for any feedback on this, but if I don't 
>> respond until next week you know why :)
>>
>> Thanks,
>> Bengt
>

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

From john.cuthbertson at oracle.com  Thu Apr  4 22:01:12 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 04 Apr 2013 15:01:12 -0700
Subject: HeapRegionRemSetIterator question
In-Reply-To: <515DE840.3070202@oracle.com>
References: <515DB85D.8020001@oracle.com> <515DE840.3070202@oracle.com>
Message-ID: <515DF828.8000700@oracle.com>

Hi Jesper,

That's a good point about the false sharing. If we see it with 
PSPromotionManager instances with ParallelGC then it's possible for this 
array.

If no one objects I'll change the iterator to be stack allocated - it's 
going to make like a little simpler for me.

JohnC

On 4/4/2013 1:53 PM, Jesper Wilhelmsson wrote:
> John,
>
> It looks to me as if this array is accessed by different threads over 
> and over again. Could this be a source for contention and cache misses 
> due to false sharing? Stack allocating new instances in the thread 
> that is to use the iterator sounds more efficient to me, especially in 
> a NUMA world which is where we are heading I guess.
> /Jesper
>
> John Cuthbertson skrev 4/4/13 7:29 PM:
>> Hi Everyone,
>>
>> I've been looking at G1's HeapRegionRemSetIterator and I was 
>> wondering if anyone
>> knows why we pre-allocate instances of the iterator during startup 
>> and then
>> initalize them repeatedly when RSet scanning claims new regions? I 
>> don't see
>> much difference between this and stack allocating new instances - 
>> other than
>> saving the initialization of one or two fields. Is there any reason 
>> not to stack
>> allocate the iterator instances?
>>
>> Thanks,
>>
>> JohnC



From coleen.phillimore at oracle.com  Thu Apr  4 22:41:36 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 04 Apr 2013 18:41:36 -0400
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515D71E3.9000300@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
Message-ID: <515E01A0.4090604@oracle.com>


Hi Jon,

Mikael's review is more thorough than what I've looked at so far.  I 
wanted to add to it and my own comments at the end.   I didn't realize 
you were working on this.  This is far less code than changing our 
allocation scheme to malloc!

On 04/04/2013 08:28 AM, Mikael Gerdin wrote:
> Jon,
>
> On 2013-04-04 06:00, Jon Masamitsu wrote:
>> After class unloading deallocate any VirtualSpaceNodes not being used.
>
> The webrev is a bit confusing since it says for metaspace.cpp:
> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with 
> class FreeList<Metachunk>
> Reviewed-by: mgerdin
>
> this implies to me that the 8011173 patch is included in this webrev 
> when in fact this webrev is incremental on top of that patch.
> I don't know if that was intentional or not but it confused me a bit 
> when trying to apply this patch.
>
> I'm totally fine with incremental webrevs though, just as long as they 
> are advertised as such :)
>
>>
>> When the classes for a dead class loader are unloaded, all the 
>> Metachunks
>> that had been used by that class loader are put on the Metachunk
>> free list for later reuse.   If all the Metachunks allocated out of a
>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>   from the free list and deallocate the VirtualSpaceNode.
>>
>> The constructor for VirtualSpaceNode was moved to be below the
>> definition of
>> SpaceManager.
>
> I'm not sure why you moved the VirtualSpaceNode constructor to after 
> the definition of SpaceManager, but I see that 
> {inc,dec}_container_count need to reference the expand_lock().
>

You moved the constructor for VirtualSpaceNode but the gc baseline 
doesn't have changes I made to it recently, so moving it will not get 
the most recent changes from hotspot-rt.


> Also, when I applied your patch and looked at the code in eclipse it 
> helpfully notified me that you are forgetting to initialize 
> _container_count in the VirtualSpaceNode constructor that you moved.
>
> Why don't you set the Metachunk::_container field in 
> Metachunk::initialize():
>
>  776   // Point the chunk at the space
>  777   Metachunk* result = Metachunk::initialize(chunk_limit, 
> chunk_word_size);
>  778   return result;

In fact, I believe the Metachunk constructor is never called. Pointers 
are transformed into these.  If that's the case the Metachunk 
constructors should be removed.

>
>  It's called from VirtualSpaceNode so you should be able to pass 
> "this" along to Metachunk::initialize. That will save us the walking 
> of VirtualSpaceList to find the correct node to increment the count for.
>
> If you set up Metachunk::_container in Metachunk::_initialize you 
> could also skip the wrapper for ChunkManager::chunk_freelist_allocate 
> inside VirtualSpaceList and just add:
>
> if (next != NULL) {
>   next->container()->inc_container_count();
> }
> at the end of VirtualSpaceList::get_new_chunk
>
> You are not decreasing the _container_count when returning humongous 
> chunks in ~SpaceManager:
> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
> // here you could do a
> humongous_chunks->container()->dec_container_count();
> 2124 
> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>
> You are already incrementing _container_count for humongous chunks 
> allocated from the hum chunk free list because those allocations go 
> through the chunk_freelist_allocate wrapper function you added.
>
> It also feels strange that inc_container_count() is private but 
> dec_container_count and container_count() are public. I realize that 
> it works currently because VirtualSpaceList is a friend of 
> VirtualSpaceNode but it seems like a strange level of encapsulation.
>
>
> The class space only contains one VirtualSpaceNode currently, should 
> we add some code to make sure that we don't accidentally free that 
> memory?
>

The class space can contain >1 virtual space nodes if 
!UseCompressedKlassPointers right now so you can purge unused spaces.   
I'm making this go away.

It looks like you find the containing virtual space node when you 
deallocate the chunks which looks really expensive.   Why not have all 
the chunks have a field with their container when they are created or 
reused?  Am I reading this wrong?   These two "contains()" calls at 
lines 2033, 2034 are going to be killer.


At 932, you should not purge the current virtual space, I think, because 
you might just allocate it again.

Around 928, why do you have to walk the virtual space itself?  Why not 
walk the linked list of free chunks for the container entry that matches 
the virtual space node if the virtual space count is null? You could do 
one walk and remove all entries with all virtual space nodes that are 
matching if you are worried about the loop in the loop.   It has to find 
the chunk in the free list anyway to remove it.

This is a nit of mine.   Can you move the declaration at 805 to 807 
where the initial value is returned?

Thanks!
Coleen

> /Mikael
>
>>
>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>
>> Thanks.
>>
>> Jon



From jesper.wilhelmsson at oracle.com  Thu Apr  4 20:53:20 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 04 Apr 2013 22:53:20 +0200
Subject: HeapRegionRemSetIterator question
In-Reply-To: <515DB85D.8020001@oracle.com>
References: <515DB85D.8020001@oracle.com>
Message-ID: <515DE840.3070202@oracle.com>

John,

It looks to me as if this array is accessed by different threads over and over 
again. Could this be a source for contention and cache misses due to false 
sharing? Stack allocating new instances in the thread that is to use the 
iterator sounds more efficient to me, especially in a NUMA world which is where 
we are heading I guess.
/Jesper

John Cuthbertson skrev 4/4/13 7:29 PM:
> Hi Everyone,
>
> I've been looking at G1's HeapRegionRemSetIterator and I was wondering if anyone
> knows why we pre-allocate instances of the iterator during startup and then
> initalize them repeatedly when RSet scanning claims new regions? I don't see
> much difference between this and stack allocating new instances - other than
> saving the initialization of one or two fields. Is there any reason not to stack
> allocate the iterator instances?
>
> Thanks,
>
> JohnC


From jon.masamitsu at oracle.com  Fri Apr  5 04:07:11 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 04 Apr 2013 21:07:11 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515D71E3.9000300@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
Message-ID: <515E4DEF.2060702@oracle.com>

On 4/4/13 5:28 AM, Mikael Gerdin wrote:
> Jon,
>
> On 2013-04-04 06:00, Jon Masamitsu wrote:
>> After class unloading deallocate any VirtualSpaceNodes not being used.
>
> The webrev is a bit confusing since it says for metaspace.cpp:
> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with 
> class FreeList<Metachunk>
> Reviewed-by: mgerdin
>
> this implies to me that the 8011173 patch is included in this webrev 
> when in fact this webrev is incremental on top of that patch.
> I don't know if that was intentional or not but it confused me a bit 
> when trying to apply this patch.
>
> I'm totally fine with incremental webrevs though, just as long as they 
> are advertised as such :)

Yes, my bad.  I had intended to say something about that.
>
>>
>> When the classes for a dead class loader are unloaded, all the 
>> Metachunks
>> that had been used by that class loader are put on the Metachunk
>> free list for later reuse.   If all the Metachunks allocated out of a
>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>   from the free list and deallocate the VirtualSpaceNode.
>>
>> The constructor for VirtualSpaceNode was moved to be below the
>> definition of
>> SpaceManager.
>
> I'm not sure why you moved the VirtualSpaceNode constructor to after 
> the definition of SpaceManager, but I see that 
> {inc,dec}_container_count need to reference the expand_lock().

Yes, that's why.  I kept all the methods for VirtualSpaceNode together 
so moved the
constructor down with the inc_container_count()/dec_container_count().
>
> Also, when I applied your patch and looked at the code in eclipse it 
> helpfully notified me that you are forgetting to initialize 
> _container_count in the VirtualSpaceNode constructor that you moved.

I fixed that.

>
> Why don't you set the Metachunk::_container field in 
> Metachunk::initialize():
>
>  776   // Point the chunk at the space
>  777   Metachunk* result = Metachunk::initialize(chunk_limit, 
> chunk_word_size);
>  778   return result;
>
>  It's called from VirtualSpaceNode so you should be able to pass 
> "this" along to Metachunk::initialize. That will save us the walking 
> of VirtualSpaceList to find the correct node to increment the count for.
>
> If you set up Metachunk::_container in Metachunk::_initialize you 
> could also skip the wrapper for ChunkManager::chunk_freelist_allocate 
> inside VirtualSpaceList and just add:
>
> if (next != NULL) {
>   next->container()->inc_container_count();
> }
> at the end of VirtualSpaceList::get_new_chunk
I think I will do this.  At one time I thought I would overlay 
_container_count
and _top but I don't need to save 1 or 2 words per chunk.

>
> You are not decreasing the _container_count when returning humongous 
> chunks in ~SpaceManager:
> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
> // here you could do a
> humongous_chunks->container()->dec_container_count();
> 2124 
> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>
> You are already incrementing _container_count for humongous chunks 
> allocated from the hum chunk free list because those allocations go 
> through the chunk_freelist_allocate wrapper function you added.

A VirtualSpace that contains 1 Metachunk holds nothing else so that 
decrementing
the count on such a VirtualSpace will deallocate it.  I'll try it but 
may revert it.


>
> It also feels strange that inc_container_count() is private but 
> dec_container_count and container_count() are public. I realize that 
> it works currently because VirtualSpaceList is a friend of 
> VirtualSpaceNode but it seems like a strange level of encapsulation.

Isn't incrementing the counter done by a VirtualSpaceNode
and decrementing done by a SpaceManager for the dec_container_count()
needs to be public?
>
>
> The class space only contains one VirtualSpaceNode currently, should 
> we add some code to make sure that we don't accidentally free that 
> memory?

Let me defer this because I think Coleen had something to say.

Thanks.

Jon
>
> /Mikael
>
>>
>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>
>> Thanks.
>>
>> Jon



From john.coomes at oracle.com  Fri Apr  5 04:48:49 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 04:48:49 +0000
Subject: hg: hsx/hotspot-gc/corba: 5 new changesets
Message-ID: <20130405044854.DF9FA480B4@hg.openjdk.java.net>

Changeset: c3ec80715805
Author:    mfang
Date:      2013-03-25 16:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/c3ec80715805

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties
! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties
! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp

Changeset: 910af9c3f338
Author:    mfang
Date:      2013-03-25 18:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/910af9c3f338

Merge


Changeset: 7d7a009d5fbd
Author:    lana
Date:      2013-03-26 12:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/7d7a009d5fbd

Merge


Changeset: 928f8b888deb
Author:    lana
Date:      2013-04-01 21:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/928f8b888deb

Merge


Changeset: 9583a6431596
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/9583a6431596

Added tag jdk8-b84 for changeset 928f8b888deb

! .hgtags



From john.coomes at oracle.com  Fri Apr  5 04:48:44 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 04:48:44 +0000
Subject: hg: hsx/hotspot-gc: 8 new changesets
Message-ID: <20130405044845.538A2480B3@hg.openjdk.java.net>

Changeset: 19a59a13b3ef
Author:    dholmes
Date:      2013-03-14 01:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/19a59a13b3ef

8009428: Revert changes to $ substitution performed as part of nashorn integration
Reviewed-by: alanb, erikj

! common/makefiles/MakeBase.gmk

Changeset: 4984ac509993
Author:    lana
Date:      2013-03-15 23:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/4984ac509993

Merge


Changeset: 477d18509ecb
Author:    lana
Date:      2013-03-26 12:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/477d18509ecb

Merge


Changeset: a1bb1a0df1fa
Author:    lana
Date:      2013-04-01 21:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a1bb1a0df1fa

Merge


Changeset: 15c1642967c9
Author:    andrew
Date:      2013-04-02 13:59 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/15c1642967c9

8009988: build-infra: Fix configure output for zip debuginfo check
Summary: No output from zip debuginfo option when default is used.
Reviewed-by: tbell

! common/autoconf/autogen.sh
! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: f3cdfb3d360d
Author:    omajid
Date:      2013-04-02 14:13 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/f3cdfb3d360d

8011278: Allow using a system-installed giflib
Reviewed-by: andrew, prr

! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4

Changeset: 01f631f89fa3
Author:    katleman
Date:      2013-04-02 15:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/01f631f89fa3

Merge


Changeset: a0fa9e93efee
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a0fa9e93efee

Added tag jdk8-b84 for changeset 01f631f89fa3

! .hgtags



From john.coomes at oracle.com  Fri Apr  5 04:48:58 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 04:48:58 +0000
Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b84 for changeset f5f40094ffcc
Message-ID: <20130405044907.977EB480B5@hg.openjdk.java.net>

Changeset: 41b50e2c5ea3
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/41b50e2c5ea3

Added tag jdk8-b84 for changeset f5f40094ffcc

! .hgtags



From john.coomes at oracle.com  Fri Apr  5 04:49:12 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 04:49:12 +0000
Subject: hg: hsx/hotspot-gc/jaxws: 4 new changesets
Message-ID: <20130405044923.30EC2480B6@hg.openjdk.java.net>

Changeset: 0ab59cba6167
Author:    jjg
Date:      2013-03-18 18:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/0ab59cba6167

8007803: Implement javax.lang.model API for Type Annotations
Reviewed-by: darcy

! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java

Changeset: 2476e1f2afa5
Author:    lana
Date:      2013-03-26 12:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/2476e1f2afa5

Merge


Changeset: 5773e3fc8380
Author:    lana
Date:      2013-04-01 21:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/5773e3fc8380

Merge


Changeset: 8c0b6bccfe47
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/8c0b6bccfe47

Added tag jdk8-b84 for changeset 5773e3fc8380

! .hgtags



From john.coomes at oracle.com  Fri Apr  5 04:52:02 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 04:52:02 +0000
Subject: hg: hsx/hotspot-gc/jdk: 52 new changesets
Message-ID: <20130405050256.1DDB4480B7@hg.openjdk.java.net>

Changeset: 07acfb90700b
Author:    malenkov
Date:      2013-03-14 12:15 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/07acfb90700b

8000183: 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs
Reviewed-by: alexsch, serb

! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
+ test/javax/swing/JScrollBar/7163696/Test7163696.java

Changeset: d4e1c5803a59
Author:    alexsch
Date:      2013-03-15 17:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d4e1c5803a59

8009221: [macosx] Two closed/javax/swing regression tests fail on MacOSX.
Reviewed-by: serb, alexp

+ test/javax/swing/JMenu/4515762/bug4515762.java
+ test/javax/swing/JRootPane/4670486/bug4670486.java
! test/javax/swing/regtesthelpers/Util.java

Changeset: 2725b8a783e7
Author:    lana
Date:      2013-03-15 16:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2725b8a783e7

Merge

- make/tools/javazic/Makefile
- make/tools/src/build/tools/javazic/BackEnd.java
- make/tools/src/build/tools/javazic/Checksum.java
- make/tools/src/build/tools/javazic/DayOfWeek.java
- make/tools/src/build/tools/javazic/Gen.java
- make/tools/src/build/tools/javazic/GenDoc.java
- make/tools/src/build/tools/javazic/Main.java
- make/tools/src/build/tools/javazic/Mappings.java
- make/tools/src/build/tools/javazic/Month.java
- make/tools/src/build/tools/javazic/Rule.java
- make/tools/src/build/tools/javazic/RuleDay.java
- make/tools/src/build/tools/javazic/RuleRec.java
- make/tools/src/build/tools/javazic/Simple.java
- make/tools/src/build/tools/javazic/Time.java
- make/tools/src/build/tools/javazic/Timezone.java
- make/tools/src/build/tools/javazic/Zone.java
- make/tools/src/build/tools/javazic/ZoneRec.java
- make/tools/src/build/tools/javazic/Zoneinfo.java
- src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
- src/share/classes/java/util/function/Block.java
- src/share/classes/java/util/function/DoubleBlock.java
- src/share/classes/java/util/function/IntBlock.java
- src/share/classes/java/util/function/LongBlock.java
- src/share/classes/sun/security/util/KeyLength.java
- test/javax/script/RhinoExceptionTest.java

Changeset: 4bf5a5a72664
Author:    serb
Date:      2013-03-18 22:10 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4bf5a5a72664

8000435: [macosx] Button painting error under Java 7 on Mac
Reviewed-by: denis, alexsch

! src/macosx/classes/com/apple/laf/AquaButtonBorder.java
! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java

Changeset: af6049edac00
Author:    kshefov
Date:      2013-03-19 17:51 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af6049edac00

8009881: TEST_BUG: javax/swing/JTree/8004298/bug8004298.java should be modified
Reviewed-by: serb, alexsch

! test/javax/swing/JTree/8004298/bug8004298.java

Changeset: 4e15c3e56315
Author:    kshefov
Date:      2013-03-20 14:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4e15c3e56315

8009880: TEST_BUG: Test java/beans/Introspector/TestTypeResolver.java should be modified again
Reviewed-by: malenkov, alexsch

! test/java/beans/Introspector/TestTypeResolver.java

Changeset: 87001c7bb678
Author:    alitvinov
Date:      2013-03-20 20:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/87001c7bb678

6550588: java.awt.Desktop cannot open file with Windows UNC filename
Reviewed-by: art, uta

! src/windows/classes/sun/awt/windows/WDesktopPeer.java
! src/windows/native/sun/windows/awt_Desktop.cpp
+ test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java

Changeset: ef948ef2b58f
Author:    alexsch
Date:      2013-03-21 16:50 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ef948ef2b58f

8007146: [macosx] Setting a display mode crashes JDK under VNC
Reviewed-by: serb

! src/macosx/native/sun/awt/CGraphicsDevice.m
+ test/java/awt/GraphicsDevice/CheckDisplayModes.java

Changeset: a275acd8bcae
Author:    denis
Date:      2013-03-22 19:56 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a275acd8bcae

7123476: DesktopOpenTests:When enter the file path and click the open button,it crash
Reviewed-by: art, anthony

! make/sun/xawt/FILES_c_unix.gmk
! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/gtk2_interface.h
! src/solaris/native/sun/xawt/awt_Desktop.c
+ src/solaris/native/sun/xawt/gnome_interface.c
+ src/solaris/native/sun/xawt/gnome_interface.h

Changeset: 15a2599f470f
Author:    lana
Date:      2013-03-26 11:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/15a2599f470f

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: e497a050e059
Author:    uta
Date:      2013-03-13 13:22 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e497a050e059

7190897: (fs) Files.isWritable method returns false when the path is writable (win)
Summary: The [GetEffectiveRightsFromAcl] based implementation was changed to the [AccessCheck] based.
Reviewed-by: alanb

! src/windows/classes/sun/nio/fs/WindowsConstants.java
! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java
! src/windows/classes/sun/nio/fs/WindowsSecurity.java
! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c

Changeset: e33cbbe21419
Author:    alanb
Date:      2013-03-13 17:58 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e33cbbe21419

8009751: (se) Selector spin when select, close and interestOps(0) invoked at same time (lnx)
Reviewed-by: zhouyx, chegar, robm

! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java

Changeset: 94335b6ffb32
Author:    jgish
Date:      2013-03-13 11:24 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/94335b6ffb32

8002070: Remove the stack search for a resource bundle for Logger to use
Summary: The fragile, vulnerable, stack crawling has been eliminated from findResourceBundle(String)
Reviewed-by: mchung, alanb

! src/share/classes/java/util/logging/Logger.java
! test/java/util/logging/LoggerResourceBundleRace.java

Changeset: ef0c60b93a17
Author:    dxu
Date:      2013-03-13 14:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ef0c60b93a17

8001334: Remove use of JVM_* functions from java.io code
Summary: Replace JVM_* functions with direct system calls in java io area
Reviewed-by: alanb, uta, martin

! make/java/nio/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/share/native/java/io/ObjectOutputStream.c
! src/share/native/java/io/io_util.c
! src/share/native/java/io/io_util.h
! src/solaris/native/common/jdk_util_md.h
! src/solaris/native/java/io/FileDescriptor_md.c
! src/solaris/native/java/io/UnixFileSystem_md.c
! src/solaris/native/java/io/io_util_md.c
! src/solaris/native/java/io/io_util_md.h
! src/windows/native/common/jdk_util_md.h
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/io/io_util_md.h

Changeset: f5c85c0a9af0
Author:    robm
Date:      2013-03-14 00:21 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f5c85c0a9af0

8009650: HttpClient available() check throws SocketException when connection has been closed
Reviewed-by: chegar, khazra, dsamersoff
Contributed-by: sdouglas at redhat.com

! src/share/classes/sun/net/www/http/HttpClient.java
+ test/sun/net/www/http/HttpClient/IsAvailable.java

Changeset: 41289b4a1819
Author:    dholmes
Date:      2013-03-14 01:47 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/41289b4a1819

8009429: Miscellaneous profiles cleanup
8009428: Revert changes to $ substitution performed as part of nashorn integration
Reviewed-by: alanb, erikj

! makefiles/CreateJars.gmk
! makefiles/ProfileNames.gmk
! makefiles/Profiles.gmk
! makefiles/profile-includes.txt
! makefiles/profile-rtjar-includes.txt

Changeset: f010eb1e696f
Author:    alanb
Date:      2013-03-14 16:03 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f010eb1e696f

8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs
Reviewed-by: dlong, alanb, mduigou
Contributed-by: bill.pittore at oracle.com, bob.vandette at oracle.com

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/System.java
! src/share/javavm/export/jni.h
! src/share/native/common/jni_util.h
! src/share/native/java/lang/ClassLoader.c
! src/solaris/native/common/jni_util_md.c
! src/windows/native/common/jni_util_md.c

Changeset: ca9469a15792
Author:    alanb
Date:      2013-03-14 16:59 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ca9469a15792

7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1)
Reviewed-by: alanb, chegar
Contributed-by: yiming.wang at oracle.com

! test/java/nio/channels/DatagramChannel/Connect.java
! test/java/nio/channels/DatagramChannel/ConnectedSend.java
! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java
! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java

Changeset: d79503c4c56f
Author:    naoto
Date:      2013-03-14 11:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d79503c4c56f

8008576: Calendar mismatch using Host LocaleProviderAdapter
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/sun/util/locale/LanguageTag.java
! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java
+ src/share/classes/sun/util/locale/provider/CalendarProviderImpl.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
+ src/share/classes/sun/util/spi/CalendarProvider.java
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c

Changeset: 46ad8dfabd5f
Author:    sundar
Date:      2013-03-15 19:30 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/46ad8dfabd5f

8010136: Make jrunscript's init.js to work on nashorn
Reviewed-by: lagergren, hannesw

! src/share/classes/com/sun/tools/script/shell/init.js

Changeset: c1a142965db0
Author:    lana
Date:      2013-03-15 23:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c1a142965db0

Merge

! makefiles/CompileNativeLibraries.gmk
! src/share/classes/java/util/logging/Logger.java
- src/share/classes/sun/security/util/KeyLength.java

Changeset: c1165d566a23
Author:    vlivanov
Date:      2013-03-06 16:59 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c1165d566a23

8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field
Reviewed-by: jrose, twisti

! src/share/classes/java/lang/invoke/DirectMethodHandle.java
+ test/java/lang/invoke/8009222/Test8009222.java

Changeset: ec8229b26dbc
Author:    chegar
Date:      2013-03-17 09:55 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ec8229b26dbc

8010142: ProblemList.txt updates (3/2013)
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: a0275a47fa78
Author:    sla
Date:      2013-03-19 09:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a0275a47fa78

8006637: Failure to filter out native frame events on Solaris
Summary: Test is confused by other threads calling String.intern(). Add a thread filter to avoid this.
Reviewed-by: sspitsyn, alanb

! test/com/sun/jdi/NativeInstanceFilter.java

Changeset: e766da5575fa
Author:    dholmes
Date:      2013-03-19 06:01 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e766da5575fa

8009426: "profiles" target fails due to nashorn if "images" is not built first
Reviewed-by: alanb

! makefiles/CreateJars.gmk
! makefiles/Profiles.gmk
! makefiles/profile-includes.txt

Changeset: 4103eb6b2137
Author:    jzavgren
Date:      2013-03-18 14:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4103eb6b2137

8007607: security native code doesn't always use malloc, realloc, and calloc correctly
Reviewed-by: chegar, dsamersoff, valeriep

! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
! src/share/native/sun/security/jgss/wrapper/NativeUtil.c
! src/solaris/native/com/sun/security/auth/module/Solaris.c
! src/solaris/native/com/sun/security/auth/module/Unix.c
! src/solaris/native/sun/security/smartcardio/pcsc_md.c

Changeset: 2241a2d34085
Author:    mduigou
Date:      2013-03-19 16:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2241a2d34085

8001642: Add Optional<T>, OptionalDouble, OptionalInt, OptionalLong
Reviewed-by: mduigou, darcy, alanb, jjb
Contributed-by: Brian Goetz <brian.goetz at oracle.com>

+ src/share/classes/java/util/Optional.java
+ src/share/classes/java/util/OptionalDouble.java
+ src/share/classes/java/util/OptionalInt.java
+ src/share/classes/java/util/OptionalLong.java
+ test/java/util/Optional/Basic.java
+ test/java/util/Optional/BasicDouble.java
+ test/java/util/Optional/BasicInt.java
+ test/java/util/Optional/BasicLong.java

Changeset: fb23896a01f5
Author:    uta
Date:      2013-03-20 13:21 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fb23896a01f5

8006193: (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public
Reviewed-by: alanb

! src/windows/classes/java/lang/ProcessImpl.java

Changeset: 3070b7363853
Author:    chegar
Date:      2013-03-20 14:39 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3070b7363853

8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe
Reviewed-by: khazra, alanb

! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java
! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java

Changeset: 38116bfe5323
Author:    mullan
Date:      2013-03-20 10:58 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/38116bfe5323

8010112: NullPointerException in sun.security.provider.certpath.CertId()
Reviewed-by: vinnie

! src/share/classes/sun/security/provider/certpath/CertId.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/x509/X509CertImpl.java

Changeset: 9859856920ed
Author:    mullan
Date:      2013-03-20 11:23 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9859856920ed

Merge

- src/share/classes/sun/security/util/KeyLength.java

Changeset: 38c1d0c2d6a6
Author:    mullan
Date:      2013-03-20 12:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/38c1d0c2d6a6

Merge


Changeset: ccd9f53377c4
Author:    mchung
Date:      2013-03-20 09:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ccd9f53377c4

8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration
Reviewed-by: alanb

! test/java/util/logging/CustomLogManager.java
! test/java/util/logging/CustomLogManagerTest.java

Changeset: cf0049037deb
Author:    darcy
Date:      2013-03-20 15:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cf0049037deb

8010427: Refine Method.isDefault implementation
Reviewed-by: acorn, dlsmith

! src/share/classes/java/lang/reflect/Method.java

Changeset: 3c1a4966d901
Author:    dholmes
Date:      2013-03-20 22:39 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3c1a4966d901

8006818: SunEC and SunPKCS11 providers should be in all profiles
Reviewed-by: dholmes, alanb, valeriep
Contributed-by: Jen Dority <jen.dority at oracle.com>

! makefiles/profile-includes.txt

Changeset: 9ee1aff76498
Author:    sundar
Date:      2013-03-21 19:19 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9ee1aff76498

8009869: Need to modify java.security property package.access to include nashorn packages
Reviewed-by: ahgross, jlaskey, lagergren

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 3f8fbb0ab155
Author:    robm
Date:      2013-03-21 17:33 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3f8fbb0ab155

8009251: Add proxy handling and keep-alive fixes to jsse
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java

Changeset: 93cd7052d306
Author:    weijun
Date:      2013-03-22 19:59 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/93cd7052d306

8010531: Add BadKdc* tests to problem list for solaris-sparcv9
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 470232a8e89d
Author:    stefank
Date:      2013-03-22 15:01 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/470232a8e89d

8005116: NPG: Rename -permstat option for jmap in jdk8 to -clstats
Reviewed-by: jmasa, sla
Contributed-by: Erik Helin <erik.helin at oracle.com>

! src/share/classes/sun/tools/jmap/JMap.java

Changeset: 518d6087e01f
Author:    stefank
Date:      2013-03-22 15:01 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/518d6087e01f

8004172: Update jstat counter names to reflect metaspace changes
Reviewed-by: mchung
Contributed-by: Erik Helin <erik.helin at oracle.com>

! src/share/classes/sun/tools/jstat/resources/jstat_options
! test/sun/tools/jstat/gcCapacityOutput1.awk
! test/sun/tools/jstat/gcCauseOutput1.awk
+ test/sun/tools/jstat/gcMetaCapacityOutput1.awk
! test/sun/tools/jstat/gcOldOutput1.awk
! test/sun/tools/jstat/gcOutput1.awk
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
+ test/sun/tools/jstat/jstatGcMetaCapacityOutput1.sh
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh
! test/sun/tools/jstat/lineCounts1.awk
! test/sun/tools/jstat/lineCounts2.awk
! test/sun/tools/jstat/lineCounts3.awk
! test/sun/tools/jstat/lineCounts4.awk
! test/sun/tools/jstat/options1.out
! test/sun/tools/jstat/options2.out
! test/sun/tools/jstat/timeStamp1.awk
! test/sun/tools/jstatd/jstatGcutilOutput1.awk

Changeset: 3470101fae58
Author:    weijun
Date:      2013-03-23 11:49 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3470101fae58

8009970: Several LoginModule classes need extra permission to load AuthResources
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java
! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java

Changeset: ed63cace1d30
Author:    weijun
Date:      2013-03-23 11:49 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ed63cace1d30

8009875: Provide a default udp_preference_limit for krb5.conf
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/internal/Krb5.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/config/DefUdpLimit.java

Changeset: d92a96dcbfe1
Author:    sundar
Date:      2013-03-25 19:25 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d92a96dcbfe1

8010704: The test closed/java/lang/SecurityManager/CheckPackageDefinition.java failed after fix for 8009869
Reviewed-by: lagergren, hannesw

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-solaris

Changeset: 5d0c891264bf
Author:    chegar
Date:      2013-03-25 14:29 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5d0c891264bf

8010668: builtin JNI libraries should not be unloaded
Reviewed-by: chegar, alanb
Contributed-by: Bill Pittore <bill.pittore at oracle.com>

! src/share/native/java/lang/ClassLoader.c

Changeset: 5e383a73386a
Author:    mchung
Date:      2013-03-25 17:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e383a73386a

8007703: Remove com.sun.servicetag API
Reviewed-by: dholmes, alanb, erikj

! make/com/sun/Makefile
! make/common/Release.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcProperties.gmk
! makefiles/profile-includes.txt
! makefiles/profile-rtjar-includes.txt
! test/Makefile

Changeset: 335d2156222e
Author:    mchung
Date:      2013-03-25 18:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/335d2156222e

8010787: changeset for 8007703 is missing the deleted files
Reviewed-by: dholmes, alanb, erikj

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties

Changeset: 543d0fbc962e
Author:    lana
Date:      2013-03-26 12:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/543d0fbc962e

Merge

- make/com/sun/servicetag/Makefile
! makefiles/CompileNativeLibraries.gmk
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: ea7d0f49e5dd
Author:    lana
Date:      2013-04-01 21:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ea7d0f49e5dd

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: b68094f8263f
Author:    erikj
Date:      2013-03-28 09:36 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b68094f8263f

8010908: Images target failes when configured with --disable-zip-debug-info
Reviewed-by: tbell

! makefiles/Images.gmk

Changeset: 9c76ea43d491
Author:    omajid
Date:      2013-04-02 14:13 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9c76ea43d491

8011278: Allow using a system-installed giflib
Reviewed-by: andrew, prr

! makefiles/CompileNativeLibraries.gmk
! src/share/native/sun/awt/splashscreen/splashscreen_gif.c

Changeset: 7b4721e4edb4
Author:    katleman
Date:      2013-04-02 15:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7b4721e4edb4

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: 43da85020921
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/43da85020921

Added tag jdk8-b84 for changeset 7b4721e4edb4

! .hgtags



From john.coomes at oracle.com  Fri Apr  5 05:05:38 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 05:05:38 +0000
Subject: hg: hsx/hotspot-gc/langtools: 29 new changesets
Message-ID: <20130405050703.AD2AF480B8@hg.openjdk.java.net>

Changeset: eb0198033c5c
Author:    jfranck
Date:      2013-03-13 22:03 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/eb0198033c5c

8006547: Repeating annotations: No Target on container annotation with all targets on base annotation gives compiler error
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/repeatingAnnotations/DefaultTarget.java
+ test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java
+ test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out
+ test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java
+ test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out
+ test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java
+ test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java

Changeset: e0ef84e33167
Author:    bpatel
Date:      2013-03-13 14:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e0ef84e33167

8009684: Default top left frame should be "All Packages" in the generated javadoc documentation
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java

Changeset: 82dc1e827c2a
Author:    dholmes
Date:      2013-03-14 01:45 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/82dc1e827c2a

8009429: Miscellaneous profiles cleanup
Reviewed-by: jjg, alanb

! src/share/classes/com/sun/tools/javac/sym/Profiles.java

Changeset: 2e21ecd7a5ad
Author:    vromero
Date:      2013-03-14 08:30 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2e21ecd7a5ad

8008582: jtreg failures after conversion of shell tests to Java
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java
! test/tools/javac/4846262/CheckEBCDICLocaleTest.java
! test/tools/javac/ClassPathTest/ClassPathTest.java
! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java
! test/tools/javac/lib/ToolBox.java
! test/tools/javac/links/LinksTest.java
! test/tools/javac/newlines/NewLineTest.java
! test/tools/javah/6257087/T6257087.java
! test/tools/javah/constMacroTest/ConstMacroTest.java
! test/tools/javap/stackmap/StackmapTest.java

Changeset: fd3fdaff0257
Author:    mchung
Date:      2013-03-14 10:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fd3fdaff0257

8005428: Update jdeps to read the same profile information as by javac
Reviewed-by: alanb

! make/netbeans/langtools/nbproject/project.xml
! src/share/classes/com/sun/tools/jdeps/Analyzer.java
! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java
! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
+ src/share/classes/com/sun/tools/jdeps/Profiles.java
! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
! test/tools/jdeps/Basic.java
! test/tools/jdeps/p/Foo.java
+ test/tools/jdeps/profiles.properties

Changeset: fbbf5376e7e4
Author:    rfield
Date:      2013-03-14 22:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fbbf5376e7e4

8010010: NPE generating serializedLambdaName for nested lambda
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/LambdaLambdaSerialized.java

Changeset: fa24eba012bd
Author:    vromero
Date:      2013-03-15 09:02 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fa24eba012bd

5053846: javac: MethodRef entries are duplicated in the constant pool
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java

Changeset: 195b71850b56
Author:    mnunez
Date:      2013-03-15 13:39 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/195b71850b56

8007767: TargetAnnoCombo.java need to be updated to add a new test mode
Reviewed-by: jjg, strarup

! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java
! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: a3049f4a7987
Author:    lana
Date:      2013-03-15 23:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a3049f4a7987

Merge


Changeset: 1f8c28134ffc
Author:    jjg
Date:      2013-03-18 08:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1f8c28134ffc

8005220: RFE to write javap tests for repeating annotations.
Reviewed-by: jjg
Contributed-by: peter.jensen at oracle.com

+ test/tools/javap/output/RepeatingTypeAnnotations.java
+ test/tools/javap/output/Tester.java

Changeset: 40adaf938847
Author:    jjg
Date:      2013-03-18 14:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/40adaf938847

8008425: Remove interim new javax.lang.model API for type-annotations
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
- src/share/classes/javax/lang/model/type/AnnotatedType.java
! src/share/classes/javax/lang/model/type/ExecutableType.java
! src/share/classes/javax/lang/model/type/TypeKind.java
! src/share/classes/javax/lang/model/type/TypeVisitor.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/Types.java

Changeset: 97f6839673d6
Author:    jjg
Date:      2013-03-18 18:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/97f6839673d6

8007803: Implement javax.lang.model API for Type Annotations
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
+ src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
+ src/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/share/classes/javax/lang/model/element/Element.java
! src/share/classes/javax/lang/model/element/ExecutableElement.java
! src/share/classes/javax/lang/model/type/ExecutableType.java
! src/share/classes/javax/lang/model/type/TypeMirror.java
! src/share/classes/javax/lang/model/util/Types.java

Changeset: a4913ea9bb62
Author:    darcy
Date:      2013-03-19 13:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a4913ea9bb62

8010179: Remove transitional target values from javac
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! test/tools/javac/ClassFileModifiers/MemberModifiers.java
! test/tools/javac/profiles/ProfileOptionTest.java

Changeset: 578eb3dd111d
Author:    jjg
Date:      2013-03-19 15:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/578eb3dd111d

8010315: doclint errors in javac public API
Reviewed-by: darcy

! make/build.xml
! src/share/classes/com/sun/source/util/DocTreeScanner.java
! src/share/classes/com/sun/source/util/JavacTask.java
! src/share/classes/com/sun/source/util/Plugin.java
! src/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/share/classes/javax/lang/model/type/ExecutableType.java

Changeset: a03c4a86ea2b
Author:    jjg
Date:      2013-03-19 17:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a03c4a86ea2b

8010361: fix some langtools findbugs issues
Reviewed-by: darcy

! src/share/classes/com/sun/tools/classfile/Code_attribute.java
! src/share/classes/com/sun/tools/classfile/Descriptor.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/javah/Util.java
! src/share/classes/com/sun/tools/javap/StackMapWriter.java
! src/share/classes/com/sun/tools/jdeps/JdepsTask.java
! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java
! src/share/classes/com/sun/tools/sjavac/Main.java
! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java

Changeset: 9cf17b7a5fe7
Author:    jjg
Date:      2013-03-19 17:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9cf17b7a5fe7

8010333: Remove com.sun.tools.javac.Server
Reviewed-by: darcy

- src/share/classes/com/sun/tools/javac/Server.java

Changeset: 74d7f9bcac93
Author:    jjg
Date:      2013-03-19 19:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/74d7f9bcac93

8010317: DocLint incorrectly reports some <pre> tags as empty
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/EmptyPreTest.java

Changeset: 972474640b7d
Author:    darcy
Date:      2013-03-20 17:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/972474640b7d

8010364: Clarify javax.lang.model API for Type Annotations
Reviewed-by: jjg, abuckley

! src/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/share/classes/javax/lang/model/type/ExecutableType.java

Changeset: cc38a6723663
Author:    mcimadamore
Date:      2013-03-22 12:38 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/cc38a6723663

8009649: Lambda back-end should generate invokespecial for method handles referring to private instance methods
Summary: Private lambda methods should be accessed through invokespecial
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/bytecode/TestLambdaBytecode.java

Changeset: f3814edefb33
Author:    mcimadamore
Date:      2013-03-22 12:39 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f3814edefb33

8010101: Intersection type cast issues redundant unchecked warning
Summary: Code for checking intersection type cast is incorrectly swapping operands, leading to spurious warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/Intersection02.java
+ test/tools/javac/lambda/Intersection02.out

Changeset: b6cf07c54c29
Author:    mcimadamore
Date:      2013-03-22 12:41 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b6cf07c54c29

8009820: AssertionError when compiling java code with two identical static imports
Summary: Speculative attribution is carried out twice with same method symbol in case of static imports
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/lambda/DoubleStaticImport.java

Changeset: c6728c9addff
Author:    mcimadamore
Date:      2013-03-22 12:43 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c6728c9addff

8010303: Graph inference: missing incorporation step causes spurious inference error
Summary: Multiple equality constraints on inference vars are not used to generate new inference constraints
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/lambda/TargetType28.out
+ test/tools/javac/lambda/TargetType67.java
+ test/tools/javac/lambda/TargetType68.java
+ test/tools/javac/lambda/TargetType69.java

Changeset: 5da12e8a59ba
Author:    mcimadamore
Date:      2013-03-22 12:44 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5da12e8a59ba

8010387: Javac crashes when diagnostic mentions anonymous inner class' type variables
Summary: Rich formatter doesn't preprocess supertypes of an anonymous inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/8010387/T8010387.java
+ test/tools/javac/Diagnostics/8010387/T8010387.out

Changeset: f4500abff1fd
Author:    darcy
Date:      2013-03-22 10:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f4500abff1fd

7080464: langtools regression test failures when assertions are enabled
Reviewed-by: jjg

! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/diags/MessageFile.java
! test/tools/javac/diags/MessageInfo.java

Changeset: fdf30b225e1c
Author:    mfang
Date:      2013-03-25 16:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fdf30b225e1c

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties

Changeset: 65e1ca8dcdc7
Author:    mfang
Date:      2013-03-25 18:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/65e1ca8dcdc7

Merge


Changeset: 28e466e9cd34
Author:    lana
Date:      2013-03-26 12:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/28e466e9cd34

Merge

- src/share/classes/com/sun/tools/javac/Server.java
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
- src/share/classes/javax/lang/model/type/AnnotatedType.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: cfb65ca92082
Author:    lana
Date:      2013-04-01 21:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/cfb65ca92082

Merge

- src/share/classes/com/sun/tools/javac/Server.java
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
- src/share/classes/javax/lang/model/type/AnnotatedType.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: 4a48f3173534
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4a48f3173534

Added tag jdk8-b84 for changeset cfb65ca92082

! .hgtags



From john.coomes at oracle.com  Fri Apr  5 05:07:11 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 05:07:11 +0000
Subject: hg: hsx/hotspot-gc/nashorn: 16 new changesets
Message-ID: <20130405050723.743B8480B9@hg.openjdk.java.net>

Changeset: c54e218333be
Author:    sundar
Date:      2013-03-12 18:12 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c54e218333be

8009757: Package access clean up and refactoring
Reviewed-by: jlaskey, lagergren, attila

! docs/JavaScriptingProgrammersGuide.html
! docs/source/javaarray.js
! make/build.xml
! make/java.security.override
! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
+ src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/StructureLoader.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
+ src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
! src/jdk/nashorn/internal/runtime/resources/parser.js
! test/script/basic/JDK-8008448.js
! test/script/basic/NASHORN-401.js
! test/script/basic/consstring.js
! test/script/basic/fileline.js
! test/script/basic/javainnerclasses.js
! test/script/basic/list.js
! test/script/basic/map.js
! test/script/basic/stdin.js
! test/script/sandbox/javaextend.js
! test/script/sandbox/javaextend.js.EXPECTED
! test/script/sandbox/reflection.js
- test/script/sandbox/reflection.js.EXPECTED
! test/script/sandbox/unsafe.js
- test/script/sandbox/unsafe.js.EXPECTED
! test/script/trusted/urlreader.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
- test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java
! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java
- test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java
- test/src/jdk/nashorn/internal/test/models/DessertTopping.java
- test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java
- test/src/jdk/nashorn/internal/test/models/FinalClass.java
- test/src/jdk/nashorn/internal/test/models/FloorWax.java
- test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java
- test/src/jdk/nashorn/internal/test/models/NonPublicClass.java
- test/src/jdk/nashorn/internal/test/models/OuterClass.java
- test/src/jdk/nashorn/internal/test/models/OverloadedSam.java
- test/src/jdk/nashorn/internal/test/models/OverrideObject.java
- test/src/jdk/nashorn/internal/test/models/StringArgs.java
- test/src/jdk/nashorn/internal/test/models/Toothpaste.java
+ test/src/jdk/nashorn/test/models/ConstructorWithArgument.java
+ test/src/jdk/nashorn/test/models/DessertTopping.java
+ test/src/jdk/nashorn/test/models/DessertToppingFloorWaxDriver.java
+ test/src/jdk/nashorn/test/models/FinalClass.java
+ test/src/jdk/nashorn/test/models/FloorWax.java
+ test/src/jdk/nashorn/test/models/Nashorn401TestSubject.java
+ test/src/jdk/nashorn/test/models/NoAccessibleConstructorClass.java
+ test/src/jdk/nashorn/test/models/NonPublicClass.java
+ test/src/jdk/nashorn/test/models/OuterClass.java
+ test/src/jdk/nashorn/test/models/OverloadedSam.java
+ test/src/jdk/nashorn/test/models/OverrideObject.java
+ test/src/jdk/nashorn/test/models/SourceHelper.java
+ test/src/jdk/nashorn/test/models/StringArgs.java
+ test/src/jdk/nashorn/test/models/Toothpaste.java

Changeset: e15806b9d716
Author:    lagergren
Date:      2013-03-12 15:30 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e15806b9d716

8009718: Lazy execution architecture continued - ScriptFunctionData is either final or recompilable. Moved ScriptFunctionData creation logic away from runtime to compile time. Prepared for method generation/specialization. Got rid of ScriptFunctionImplTrampoline whose semantics could be done as part of the relinking anyway. Merge with the lookup package change.
Reviewed-by: attila, jlaskey

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/BranchOptimizer.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/CompileUnit.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/codegen/FunctionSignature.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/ObjectNode.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
- src/jdk/nashorn/internal/ir/annotations/ChildNode.java
- src/jdk/nashorn/internal/ir/annotations/ParentNode.java
! src/jdk/nashorn/internal/ir/annotations/Reference.java
! src/jdk/nashorn/internal/ir/debug/ASTWriter.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
- src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java
! src/jdk/nashorn/internal/parser/JSONParser.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/CodeInstaller.java
+ src/jdk/nashorn/internal/runtime/CompiledFunction.java
+ src/jdk/nashorn/internal/runtime/CompiledFunctions.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ECMAException.java
+ src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
+ src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
- src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! test/script/currently-failing/JDK-8006529.js
+ test/script/currently-failing/clone_ir.js

Changeset: 60684aeba89c
Author:    sundar
Date:      2013-03-12 21:17 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/60684aeba89c

8009868: For loop with "true" as condition results in AssertionError in codegen
Reviewed-by: jlaskey, hannesw, lagergren

! src/jdk/nashorn/internal/codegen/Lower.java
+ test/script/basic/JDK-8009868.js

Changeset: 390d44ba90cf
Author:    lagergren
Date:      2013-03-14 14:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/390d44ba90cf

8009982: Lazy execution bugfix. Added lazy sunspider unit test. Added mandreel to compile-octane test. Fixed warnings
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java
! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java
! src/jdk/nashorn/internal/runtime/regexp/RegExp.java
! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java
! src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java
! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
! test/script/basic/compile-octane.js.EXPECTED
! test/script/basic/run-octane.js
+ test/script/basic/runsunspider-eager.js
+ test/script/basic/runsunspider-lazy.js
! test/script/basic/runsunspider.js

Changeset: d5d80b52cf1c
Author:    lagergren
Date:      2013-03-15 16:07 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d5d80b52cf1c

8010147: Forgot to add EXPECTED files for lazy and eager sunspider test
Reviewed-by: sundar, jlaskey

+ test/script/basic/runsunspider-eager.js.EXPECTED
+ test/script/basic/runsunspider-lazy.js.EXPECTED
- test/script/basic/runsunspider.js.EXPECTED

Changeset: 4daacf8a25ef
Author:    sundar
Date:      2013-03-15 21:52 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4daacf8a25ef

8010145: removed workaround "init.js" in nashorn repo
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/api/scripting/Formatter.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/api/scripting/resources/engine.js
- src/jdk/nashorn/api/scripting/resources/init.js

Changeset: 3b0a0d9d51f0
Author:    sundar
Date:      2013-03-18 21:03 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3b0a0d9d51f0

8010199: javax.script.Invocable implementation for nashorn does not return null when matching functions are missing
Reviewed-by: lagergren, jlaskey

! bin/jjs
! bin/jjssecure
! bin/nashorn
! bin/nashornsecure
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
+ test/script/basic/JDK-8010199.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 606a1946e3e2
Author:    jlaskey
Date:      2013-03-19 11:03 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/606a1946e3e2

8009969: CodeCoverage should use template
Reviewed-by: jlaskey, sundar
Contributed-by: pavel.stepanov at oracle.com

! make/build.xml
! make/code_coverage.xml
! make/project.properties

Changeset: 4be452026847
Author:    attila
Date:      2013-03-23 00:58 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4be452026847

8010652: Eliminate non-child references in Block/FunctionNode, and make few node types immutable
Reviewed-by: jlaskey, lagergren

! make/project.properties
! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/ClassEmitter.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/codegen/FunctionSignature.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/ir/AccessNode.java
! src/jdk/nashorn/internal/ir/Assignment.java
! src/jdk/nashorn/internal/ir/BaseNode.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/BreakNode.java
! src/jdk/nashorn/internal/ir/CallNode.java
! src/jdk/nashorn/internal/ir/CaseNode.java
! src/jdk/nashorn/internal/ir/CatchNode.java
! src/jdk/nashorn/internal/ir/ContinueNode.java
! src/jdk/nashorn/internal/ir/DoWhileNode.java
! src/jdk/nashorn/internal/ir/EmptyNode.java
! src/jdk/nashorn/internal/ir/ExecuteNode.java
! src/jdk/nashorn/internal/ir/ForNode.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/IfNode.java
! src/jdk/nashorn/internal/ir/IndexNode.java
! src/jdk/nashorn/internal/ir/LabelNode.java
+ src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/ir/LineNumberNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/Location.java
! src/jdk/nashorn/internal/ir/Node.java
! src/jdk/nashorn/internal/ir/ObjectNode.java
! src/jdk/nashorn/internal/ir/PropertyNode.java
- src/jdk/nashorn/internal/ir/ReferenceNode.java
! src/jdk/nashorn/internal/ir/ReturnNode.java
! src/jdk/nashorn/internal/ir/RuntimeNode.java
! src/jdk/nashorn/internal/ir/SplitNode.java
! src/jdk/nashorn/internal/ir/SwitchNode.java
! src/jdk/nashorn/internal/ir/Symbol.java
! src/jdk/nashorn/internal/ir/TernaryNode.java
! src/jdk/nashorn/internal/ir/ThrowNode.java
! src/jdk/nashorn/internal/ir/TryNode.java
! src/jdk/nashorn/internal/ir/TypeOverride.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
! src/jdk/nashorn/internal/ir/VarNode.java
! src/jdk/nashorn/internal/ir/WhileNode.java
! src/jdk/nashorn/internal/ir/WithNode.java
! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
! test/script/basic/JDK-8006755.js
! test/script/basic/NASHORN-837.js
! test/src/jdk/nashorn/internal/codegen/CompilerTest.java

Changeset: ae4ef3102d9c
Author:    lagergren
Date:      2013-03-25 12:01 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ae4ef3102d9c

8017010: index evaluation to a temporary location for index operator much change temporaries to slots, but never scoped vars
Reviewed-by: hannesw, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java
+ test/script/basic/JDK-8017010.js
+ test/script/basic/JDK-8017010.js.EXPECTED
! test/script/basic/NASHORN-258.js
! test/script/basic/NASHORN-258.js.EXPECTED

Changeset: 15dac7439921
Author:    sundar
Date:      2013-03-25 18:20 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/15dac7439921

8010709: org on the top level doesn't resolve
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/Global.java
+ test/script/basic/JDK-8010709.js

Changeset: 43e40c08e7f8
Author:    lagergren
Date:      2013-03-26 08:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/43e40c08e7f8

8010706: -Dnashorn.args system property to create command lines to wrapped nashorn.jar:s
Reviewed-by: hannesw, sundar

! docs/DEVELOPER_README
! src/jdk/nashorn/internal/runtime/options/Options.java

Changeset: ed60078f0a80
Author:    sundar
Date:      2013-03-26 18:26 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ed60078f0a80

8010720: Linkage problem with java.lang.String.length()
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
+ test/script/basic/JDK-8010720.js

Changeset: db8a33cb22b8
Author:    lana
Date:      2013-03-26 12:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/db8a33cb22b8

Merge

- src/jdk/nashorn/api/scripting/resources/init.js
- src/jdk/nashorn/internal/ir/ReferenceNode.java
- src/jdk/nashorn/internal/ir/annotations/ChildNode.java
- src/jdk/nashorn/internal/ir/annotations/ParentNode.java
- src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java
- src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java
- test/script/basic/runsunspider.js.EXPECTED
- test/script/sandbox/reflection.js.EXPECTED
- test/script/sandbox/unsafe.js.EXPECTED
- test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java
- test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java
- test/src/jdk/nashorn/internal/test/models/DessertTopping.java
- test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java
- test/src/jdk/nashorn/internal/test/models/FinalClass.java
- test/src/jdk/nashorn/internal/test/models/FloorWax.java
- test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java
- test/src/jdk/nashorn/internal/test/models/NonPublicClass.java
- test/src/jdk/nashorn/internal/test/models/OuterClass.java
- test/src/jdk/nashorn/internal/test/models/OverloadedSam.java
- test/src/jdk/nashorn/internal/test/models/OverrideObject.java
- test/src/jdk/nashorn/internal/test/models/StringArgs.java
- test/src/jdk/nashorn/internal/test/models/Toothpaste.java

Changeset: 999cc1bf5520
Author:    lana
Date:      2013-04-01 21:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/999cc1bf5520

Merge

- src/jdk/nashorn/api/scripting/resources/init.js
- src/jdk/nashorn/internal/ir/ReferenceNode.java
- src/jdk/nashorn/internal/ir/annotations/ChildNode.java
- src/jdk/nashorn/internal/ir/annotations/ParentNode.java
- src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java
- src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java
- test/script/basic/runsunspider.js.EXPECTED
- test/script/sandbox/reflection.js.EXPECTED
- test/script/sandbox/unsafe.js.EXPECTED
- test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java
- test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java
- test/src/jdk/nashorn/internal/test/models/DessertTopping.java
- test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java
- test/src/jdk/nashorn/internal/test/models/FinalClass.java
- test/src/jdk/nashorn/internal/test/models/FloorWax.java
- test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java
- test/src/jdk/nashorn/internal/test/models/NonPublicClass.java
- test/src/jdk/nashorn/internal/test/models/OuterClass.java
- test/src/jdk/nashorn/internal/test/models/OverloadedSam.java
- test/src/jdk/nashorn/internal/test/models/OverrideObject.java
- test/src/jdk/nashorn/internal/test/models/StringArgs.java
- test/src/jdk/nashorn/internal/test/models/Toothpaste.java

Changeset: e0378f0a50da
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e0378f0a50da

Added tag jdk8-b84 for changeset 999cc1bf5520

! .hgtags



From mikael.gerdin at oracle.com  Fri Apr  5 10:45:20 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 05 Apr 2013 12:45:20 +0200
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515E01A0.4090604@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
	<515E01A0.4090604@oracle.com>
Message-ID: <515EAB40.6070206@oracle.com>



On 2013-04-05 00:41, Coleen Phillimore wrote:
>
> Hi Jon,
>
> Mikael's review is more thorough than what I've looked at so far.  I
> wanted to add to it and my own comments at the end.   I didn't realize
> you were working on this.  This is far less code than changing our
> allocation scheme to malloc!
>
> On 04/04/2013 08:28 AM, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2013-04-04 06:00, Jon Masamitsu wrote:
>>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>
>> The webrev is a bit confusing since it says for metaspace.cpp:
>> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with
>> class FreeList<Metachunk>
>> Reviewed-by: mgerdin
>>
>> this implies to me that the 8011173 patch is included in this webrev
>> when in fact this webrev is incremental on top of that patch.
>> I don't know if that was intentional or not but it confused me a bit
>> when trying to apply this patch.
>>
>> I'm totally fine with incremental webrevs though, just as long as they
>> are advertised as such :)
>>
>>>
>>> When the classes for a dead class loader are unloaded, all the
>>> Metachunks
>>> that had been used by that class loader are put on the Metachunk
>>> free list for later reuse.   If all the Metachunks allocated out of a
>>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>>   from the free list and deallocate the VirtualSpaceNode.
>>>
>>> The constructor for VirtualSpaceNode was moved to be below the
>>> definition of
>>> SpaceManager.
>>
>> I'm not sure why you moved the VirtualSpaceNode constructor to after
>> the definition of SpaceManager, but I see that
>> {inc,dec}_container_count need to reference the expand_lock().
>>
>
> You moved the constructor for VirtualSpaceNode but the gc baseline
> doesn't have changes I made to it recently, so moving it will not get
> the most recent changes from hotspot-rt.

FWIW those changes are actually in hotspot-gc so Jon will need to merge 
with them before pushing.

>
>
>> Also, when I applied your patch and looked at the code in eclipse it
>> helpfully notified me that you are forgetting to initialize
>> _container_count in the VirtualSpaceNode constructor that you moved.
>>
>> Why don't you set the Metachunk::_container field in
>> Metachunk::initialize():
>>
>>  776   // Point the chunk at the space
>>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
>> chunk_word_size);
>>  778   return result;
>
> In fact, I believe the Metachunk constructor is never called. Pointers
> are transformed into these.  If that's the case the Metachunk
> constructors should be removed.

I don't see where I said anything about the Metachunk constructor.

But the line where we call Metachunk::initialize is where we initialize 
the memory that we allocated for the chunk is set up.

I would prefer it if we could replace this with a call to the placement 
new operator and use a constructor to set up the Metachunk object but 
I'm not going to go into that argument.

>
>>
>>  It's called from VirtualSpaceNode so you should be able to pass
>> "this" along to Metachunk::initialize. That will save us the walking
>> of VirtualSpaceList to find the correct node to increment the count for.
>>
>> If you set up Metachunk::_container in Metachunk::_initialize you
>> could also skip the wrapper for ChunkManager::chunk_freelist_allocate
>> inside VirtualSpaceList and just add:
>>
>> if (next != NULL) {
>>   next->container()->inc_container_count();
>> }
>> at the end of VirtualSpaceList::get_new_chunk
>>
>> You are not decreasing the _container_count when returning humongous
>> chunks in ~SpaceManager:
>> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
>> // here you could do a
>> humongous_chunks->container()->dec_container_count();
>> 2124
>> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>>
>> You are already incrementing _container_count for humongous chunks
>> allocated from the hum chunk free list because those allocations go
>> through the chunk_freelist_allocate wrapper function you added.
>>
>> It also feels strange that inc_container_count() is private but
>> dec_container_count and container_count() are public. I realize that
>> it works currently because VirtualSpaceList is a friend of
>> VirtualSpaceNode but it seems like a strange level of encapsulation.
>>
>>
>> The class space only contains one VirtualSpaceNode currently, should
>> we add some code to make sure that we don't accidentally free that
>> memory?
>>
>
> The class space can contain >1 virtual space nodes if
> !UseCompressedKlassPointers right now so you can purge unused spaces.
> I'm making this go away.
>
> It looks like you find the containing virtual space node when you
> deallocate the chunks which looks really expensive.   Why not have all
> the chunks have a field with their container when they are created or
> reused?  Am I reading this wrong?   These two "contains()" calls at
> lines 2033, 2034 are going to be killer.

This is exactly what I was saying above:

 >> Why don't you set the Metachunk::_container field in
 >> Metachunk::initialize():
 >>
 >>  776   // Point the chunk at the space
 >>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
 >> chunk_word_size);

We could easily pass on the VirtualSpaceNode to Metachunk::initialize.


>
>
> At 932, you should not purge the current virtual space, I think, because
> you might just allocate it again.

There might be loads and loads of free chunks in the other virtual 
spaces and we may be recovering from a spike in metaspace allocation.
If we are able to release metaspace memory I think we should.
It feels pretty unlikely that we'll end up with a VirtualSpaceNode with 
a count of 0 so we should take every chance we get to free one up IMO.

/Mikael

>
> Around 928, why do you have to walk the virtual space itself?  Why not
> walk the linked list of free chunks for the container entry that matches
> the virtual space node if the virtual space count is null? You could do
> one walk and remove all entries with all virtual space nodes that are
> matching if you are worried about the loop in the loop.   It has to find
> the chunk in the free list anyway to remove it.
>
> This is a nit of mine.   Can you move the declaration at 805 to 807
> where the initial value is returned?
>
> Thanks!
> Coleen
>
>> /Mikael
>>
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>
>>> Thanks.
>>>
>>> Jon
>


From alejandro.murillo at oracle.com  Fri Apr  5 11:23:47 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 05 Apr 2013 11:23:47 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 42 new changesets
Message-ID: <20130405112519.55B5E480CD@hg.openjdk.java.net>

Changeset: ac242ddfa319
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ac242ddfa319

Added tag jdk8-b84 for changeset af788b85010e

! .hgtags

Changeset: 0c3ee6f1fa23
Author:    coleenp
Date:      2013-03-27 08:19 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0c3ee6f1fa23

8009531: Crash when redefining class with annotated method
Summary: Neglected to copy the annotations in clone_with_new_data when they were moved to ConstMethod.
Reviewed-by: acorn, sspitsyn, dcubed

! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/method.cpp

Changeset: aa758f0c5b1c
Author:    hseigel
Date:      2013-03-27 11:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aa758f0c5b1c

8010833: Test7116786.java is failing on most configs after fix for 8010667
Summary: Update test to recognize that non-zero pad bytes for lookupswitch/tablewsitch opcodes are now valid.
Reviewed-by: dcubed, twisti, kvn, coleenp, dholmes

! test/runtime/7116786/Test7116786.java

Changeset: b601102d00c8
Author:    hseigel
Date:      2013-03-27 13:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b601102d00c8

Merge


Changeset: cd3089a56438
Author:    acorn
Date:      2013-03-27 14:10 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cd3089a56438

8009731: Confusing error message for loader constraint violation
Summary: Fix text, overwritten type and holder for resolved method
Reviewed-by: coleenp, dcubed, minqi, dholmes

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/klassVtable.cpp

Changeset: 53f4040e809c
Author:    acorn
Date:      2013-03-27 16:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/53f4040e809c

Merge


Changeset: b5bae74160b7
Author:    zgu
Date:      2013-03-27 15:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b5bae74160b7

8010474: [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp
Summary: Fixed functions that miss return values
Reviewed-by: coleenp, acorn, kvn

! src/share/vm/services/memTracker.hpp

Changeset: 26e0c03da92c
Author:    zgu
Date:      2013-03-27 13:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/26e0c03da92c

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw

Changeset: f044c45bee68
Author:    zgu
Date:      2013-03-27 22:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f044c45bee68

Merge


Changeset: 1b90c7607451
Author:    minqi
Date:      2013-03-27 17:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1b90c7607451

2178143: JVM crashes if the number of bound CPUs changed during runtime
Summary: Supply a new flag -XX:+AssumeMP to workaround the problem. With the flag is turned on, assume VM run on MP platform so is_MP() will return true that sync calls will not skip away.
Reviewed-by: dholmes, acorn, dcubed, jmasa
Contributed-by: yumin.qi at oracle.com

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: d7adf726b18a
Author:    minqi
Date:      2013-03-28 00:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d7adf726b18a

Merge


Changeset: c0f9217203b2
Author:    dcubed
Date:      2013-03-29 08:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c0f9217203b2

Merge

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

Changeset: d886ac1dfd36
Author:    coleenp
Date:      2013-03-31 21:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d886ac1dfd36

8010723: fatal error: acquiring lock Metaspace allocation lock/5 out of order
Summary: Avoid holding SystemDictionary_lock while calling Klass::remove_unshareable_info
Reviewed-by: coleenp, acorn
Contributed-by: ioi.lam at oracle.com

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

Changeset: e458120c6e1a
Author:    sla
Date:      2013-03-28 15:39 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e458120c6e1a

8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM
Reviewed-by: sspitsyn, zgu
Contributed-by: peter.allwin at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java

Changeset: ede380e13960
Author:    mgerdin
Date:      2013-04-02 11:28 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ede380e13960

8009763: Add WB test for String.intern()
Summary: Add convenience method in StringTable, add WhiteBox method and simple sanity test
Reviewed-by: mgerdin, zgu
Contributed-by: leonid.mesnik at oracle.com

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/prims/whitebox.cpp
+ test/runtime/interned/SanityTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 8c03fc47511d
Author:    iklam
Date:      2013-04-01 14:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8c03fc47511d

8011048: Possible reading from unmapped memory in UTF8::as_quoted_ascii()
Summary: Pass utf_length parameter to UTF8::as_quoted_ascii()
Reviewed-by: dcubed, minqi

! src/share/vm/oops/symbol.cpp
! src/share/vm/utilities/utf8.cpp
! src/share/vm/utilities/utf8.hpp

Changeset: a4e8dac9db8c
Author:    zgu
Date:      2013-04-02 07:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a4e8dac9db8c

Merge


Changeset: 0c039865ef2b
Author:    mgerdin
Date:      2013-04-04 19:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0c039865ef2b

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: 46f6f063b272
Author:    roland
Date:      2013-03-21 09:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/46f6f063b272

7153771: array bound check elimination for c1
Summary: when possible optimize out array bound checks, inserting predicates when needed.
Reviewed-by: never, kvn, twisti
Contributed-by: thomaswue <thomas.wuerthinger at oracle.com>

! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_Instruction.cpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_Optimizer.cpp
+ src/share/vm/c1/c1_RangeCheckElimination.cpp
+ src/share/vm/c1/c1_RangeCheckElimination.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_ValueMap.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a57fc14f798a
Author:    roland
Date:      2013-03-21 22:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a57fc14f798a

Merge


Changeset: e370f63dc5b1
Author:    bharadwaj
Date:      2013-03-22 07:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e370f63dc5b1

8009539: JVM crash when run lambda testng tests
Summary: Ensure class pointer is non-null before dereferencing it to check if it is loaded.
Reviewed-by: kvn

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

Changeset: 360ce06580b8
Author:    bharadwaj
Date:      2013-03-22 13:35 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/360ce06580b8

Merge


Changeset: 3c786355ffb4
Author:    morris
Date:      2013-03-23 06:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c786355ffb4

8009026: [parfait] Null pointer deference in hotspot/src/share/vm/code/nmethod.cpp
Summary: add guarantee() to nmethod constructor and checks to ensure CodeCache has space before allocation
Reviewed-by: kvn

! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp

Changeset: 818a1ac7da7a
Author:    morris
Date:      2013-03-24 12:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/818a1ac7da7a

Merge


Changeset: 16885e702c88
Author:    twisti
Date:      2013-03-25 17:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/16885e702c88

7198429: need checked categorization of caller-sensitive methods in the JDK
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! 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/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframe.hpp

Changeset: b808febcad9a
Author:    neliasso
Date:      2013-03-26 10:05 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b808febcad9a

8010281: Remove code that is never executed
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

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

Changeset: 30f42e691e70
Author:    kvn
Date:      2013-03-26 12:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/30f42e691e70

8004640: C2 assert failure in memnode.cpp: NULL+offs not RAW address
Summary: always transform AddP nodes in IdealKit by calling _gvn.transform().
Reviewed-by: roland, twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/phaseX.cpp

Changeset: d595e8ddadd9
Author:    roland
Date:      2013-03-29 17:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d595e8ddadd9

8010934: assert failure in c1_LinearScan.cpp: "asumption: non-Constant instructions have only virtual operands"
Summary: incorrect code to skip some ArrayLength instructions in LIRGenerator
Reviewed-by: kvn

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

Changeset: cd9ad42dfde0
Author:    bharadwaj
Date:      2013-03-29 20:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cd9ad42dfde0

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 6b19fe41b577
Author:    kmo
Date:      2013-03-30 08:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6b19fe41b577

8011009: Use do-while(0) instead of while(0) in EC_TRACE and RC_TRACE* macros
Summary: Improve EC_TRACE and RC_TRACE* to use the do-while(0) trick for statement-like macro
Reviewed-by: sspitsyn, dcubed

! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp

Changeset: 53028d751155
Author:    neliasso
Date:      2013-04-02 09:30 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/53028d751155

7034299: Faulty winsock initialization code
Reviewed-by: dholmes, sla, ctornqvi

! src/os/windows/vm/os_windows.cpp

Changeset: e961c11b85fe
Author:    kvn
Date:      2013-04-03 11:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e961c11b85fe

8011102: Clear AVX registers after return from JNI call
Summary: Execute vzeroupper instruction after JNI call and on exits in jit compiled code which use 256bit vectors.
Reviewed-by: roland

! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
! src/os_cpu/linux_x86/vm/linux_x86_64.ad
! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
! src/os_cpu/windows_x86/vm/windows_x86_64.ad

Changeset: 0a8c2ea3902d
Author:    rasbold
Date:      2013-04-03 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0a8c2ea3902d

8010437: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset
Summary: Fix shorten_branches() to accurately count an initial nop that may be inserted in a block that starts with a safepoint.
Reviewed-by: kvn

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

Changeset: 70c52efb2cbd
Author:    neliasso
Date:      2013-04-04 09:18 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/70c52efb2cbd

8006008: Memory leak in hotspot/src/share/vm/adlc/archDesc.cpp
Reviewed-by: roland, kvn
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/archDesc.cpp

Changeset: 6c4abd4a9595
Author:    roland
Date:      2013-04-04 09:33 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6c4abd4a9595

8010399: Test8009761.java "Failed: init recursive calls: 5498. After deopt 5494".
Summary: test from 8009761 shouldn't be run with -Xcomp
Reviewed-by: kvn

! test/compiler/8009761/Test8009761.java

Changeset: 9125a548c1eb
Author:    roland
Date:      2013-04-04 02:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9125a548c1eb

Merge


Changeset: 573cf206e381
Author:    neliasso
Date:      2013-04-04 09:30 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/573cf206e381

8006014: Memory leak in hotspot/src/share/vm/adlc/dfa.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/dfa.cpp

Changeset: bab5cbf74b5f
Author:    kvn
Date:      2013-04-04 12:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bab5cbf74b5f

8011198: LP64 setting is not preserved on Solaris after 8006965
Summary: Fixed incremental build makefiles generated by buildtree.make. Consolidated unix build.sh.
Reviewed-by: twisti

- make/bsd/build.sh
! make/bsd/makefiles/buildtree.make
+ make/build.sh
- make/linux/build.sh
! make/linux/makefiles/buildtree.make
- make/solaris/build.sh
! make/solaris/makefiles/buildtree.make
! src/os/posix/launcher/launcher.script

Changeset: 0ca3dd0ffaba
Author:    bharadwaj
Date:      2013-04-04 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0ca3dd0ffaba

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh
! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a947f40fb536
Author:    amurillo
Date:      2013-04-04 21:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a947f40fb536

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh

Changeset: 42fe530cd478
Author:    amurillo
Date:      2013-04-04 21:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/42fe530cd478

Added tag hs25-b26 for changeset a947f40fb536

! .hgtags

Changeset: dcdeb150988c
Author:    amurillo
Date:      2013-04-04 21:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dcdeb150988c

8011584: new hotspot build - hs25-b27
Reviewed-by: jcoomes

! make/hotspot_version



From bengt.rutisson at oracle.com  Fri Apr  5 11:35:10 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 05 Apr 2013 13:35:10 +0200
Subject: RFE (m): JDK-7197666: java -d64 -version core dumps in a box
	with lots of memory
In-Reply-To: <515DB456.6020904@oracle.com>
References: <5154BF9A.2080208@oracle.com> <515D6F44.4050909@oracle.com>
	<515DB456.6020904@oracle.com>
Message-ID: <515EB6EE.8020906@oracle.com>


Hi John,

Thanks for looking at this!

On 4/4/13 7:11 PM, John Cuthbertson wrote:
> Hi Bengt,
>
> This looks good. One minor nit: the comment in allocation.hpp is 
> slightly inconsistent with the setting of the malloc limit in 
> globals.hpp. The limit will be 64K on sparc as well.

Good catch. I updated the comment.

>
> Thanks for doing this. We/I can use this to reduce malloc usage for 
> some other large mallocs.

Yes, that's my intention. :)

Thanks again for looking at this!
Bengt

>
> JohnC
>
> On 4/4/2013 5:17 AM, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Coleen and Thomas have already looked at the preliminary version of 
>> this request. Thanks!
>>
>> Removing the preliminary part of this request now and asking for full 
>> reviews.
>>
>> Here is an updated webrev based on the comments from Coleen and Thomas:
>>
>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/
>>
>> Thanks,
>> Bengt
>>
>>
>> On 3/28/13 11:09 PM, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Sending this to both runtime and GC since I think it concerns both 
>>> areas.
>>>
>>> I'd like some feedback on this preliminary change. I still want to 
>>> do some more testing and evaluation before I ask for final reviews:
>>>
>>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>>>
>>> In particular I would like some feedback on these questions:
>>>
>>> - I am adding a flag that has the same value on all platforms except 
>>> Solaris x86. There is the product_pd flag macro to support this. But 
>>> there is no experimental_pd marcro. I would have preferred to make 
>>> my new flag experimental. Should I add experimental_pd or should I 
>>> just use a product flag?
>>>
>>> - Even with product_pd I think I still have to go in to all the 
>>> different platform files and add the exact same code to give the 
>>> flag a default value on all platforms. Is there a way to have a 
>>> default value and only override it on Solaris x86?
>>>
>>> - The class I am adding, ArrayAllocator, wants to choose between 
>>> doing malloc and mmap. Normally we use ReservedSpace and 
>>> VirtualSpace to get mapped memory. However, those classes are kind 
>>> of clumsy when I just want to allocate one chunk of memory. It is 
>>> much simpler to use the os::reserve_memory() and os::commit_memory() 
>>> methods directly. I think my use case here motivate using these 
>>> methods directly, but is there some reason not to do that?
>>>
>>> Some background on the change:
>>>
>>> The default implementation of malloc on Solaris has several 
>>> limitation compared to malloc on other platforms. One limitation is 
>>> that it can only use one consecutive chunk of memory. Another 
>>> limitation is that it always allocates in this single chunk of 
>>> memory no matter how large the requested amount of memory is. Other 
>>> malloc implementations normally use mapped memory for large allocations.
>>>
>>> The Java heap is mapped in memory and we try to pick a good address 
>>> for it. The lowest allowed address is controlled by 
>>> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other 
>>> platforms have at least 2 GB). Since the C heap ends up below the 
>>> Java heap it means that in some cases it is limited to 256 MB.
>>>
>>> When we run with ParallelOldGC we get three task queues per GC 
>>> thread. Each task queue takes mallocs 1MB. The failing machine in 
>>> the bug report has lots of CPUs and ends up with 83 GC threads. This 
>>> is 249 MB, which is more than we can get out of the 256 MB limited C 
>>> heap considering that there are other things that get malloced too.
>>>
>>> So, the problems occur mostly on Solaris x86. My suggested fix tries 
>>> to address this by letting the task queues be mapped instead of 
>>> malloced on Solaris x86. Instead of inlining this logic in 
>>> taskqueue.cpp I added a more general class. The reason for this is 
>>> that I think we need to use the same logic in more places, 
>>> especially for G1, which is mallocing quite a lot.
>>>
>>> Since I think malloc on other platforms use mapped memory for large 
>>> malloc requests I think it is enough for this change to have effect 
>>> on Solaris. The other platforms probably have better heuristics than 
>>> I can come up with for which sizes should be mapped. On Sparc we 
>>> have the same limitation with malloc, but we have more memory 
>>> available for the C heap. This is why I have only enabled this for 
>>> Solaris x86.
>>>
>>> Also, I will be on vacation for a few days. Back in the office 
>>> Thrusday April 4. I'm happy for any feedback on this, but if I don't 
>>> respond until next week you know why :)
>>>
>>> Thanks,
>>> Bengt
>>
>

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

From coleen.phillimore at oracle.com  Fri Apr  5 12:01:27 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 05 Apr 2013 08:01:27 -0400
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515EAB40.6070206@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
	<515E01A0.4090604@oracle.com> <515EAB40.6070206@oracle.com>
Message-ID: <515EBD17.5070803@oracle.com>

On 4/5/2013 6:45 AM, Mikael Gerdin wrote:
>
>
> On 2013-04-05 00:41, Coleen Phillimore wrote:
>>
>> Hi Jon,
>>
>> Mikael's review is more thorough than what I've looked at so far.  I
>> wanted to add to it and my own comments at the end.   I didn't realize
>> you were working on this.  This is far less code than changing our
>> allocation scheme to malloc!
>>
>> On 04/04/2013 08:28 AM, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2013-04-04 06:00, Jon Masamitsu wrote:
>>>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>>
>>> The webrev is a bit confusing since it says for metaspace.cpp:
>>> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with
>>> class FreeList<Metachunk>
>>> Reviewed-by: mgerdin
>>>
>>> this implies to me that the 8011173 patch is included in this webrev
>>> when in fact this webrev is incremental on top of that patch.
>>> I don't know if that was intentional or not but it confused me a bit
>>> when trying to apply this patch.
>>>
>>> I'm totally fine with incremental webrevs though, just as long as they
>>> are advertised as such :)
>>>
>>>>
>>>> When the classes for a dead class loader are unloaded, all the
>>>> Metachunks
>>>> that had been used by that class loader are put on the Metachunk
>>>> free list for later reuse.   If all the Metachunks allocated out of a
>>>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>>>   from the free list and deallocate the VirtualSpaceNode.
>>>>
>>>> The constructor for VirtualSpaceNode was moved to be below the
>>>> definition of
>>>> SpaceManager.
>>>
>>> I'm not sure why you moved the VirtualSpaceNode constructor to after
>>> the definition of SpaceManager, but I see that
>>> {inc,dec}_container_count need to reference the expand_lock().
>>>
>>
>> You moved the constructor for VirtualSpaceNode but the gc baseline
>> doesn't have changes I made to it recently, so moving it will not get
>> the most recent changes from hotspot-rt.
>
> FWIW those changes are actually in hotspot-gc so Jon will need to 
> merge with them before pushing.

He should merge before moving this because I think a trivial mercurial 
merge might miss these changes, or mercurial might barf on the whole 
thing.  I don't know.  Just a warning.  I don't mind that it's moved.

>
>>
>>
>>> Also, when I applied your patch and looked at the code in eclipse it
>>> helpfully notified me that you are forgetting to initialize
>>> _container_count in the VirtualSpaceNode constructor that you moved.
>>>
>>> Why don't you set the Metachunk::_container field in
>>> Metachunk::initialize():
>>>
>>>  776   // Point the chunk at the space
>>>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
>>> chunk_word_size);
>>>  778   return result;
>>
>> In fact, I believe the Metachunk constructor is never called. Pointers
>> are transformed into these.  If that's the case the Metachunk
>> constructors should be removed.
>
> I don't see where I said anything about the Metachunk constructor.
>
> But the line where we call Metachunk::initialize is where we 
> initialize the memory that we allocated for the chunk is set up.
>
> I would prefer it if we could replace this with a call to the 
> placement new operator and use a constructor to set up the Metachunk 
> object but I'm not going to go into that argument.

Yes, I agree with you, placement new would be a lot nicer and then the 
constructor would be called.   Right now it isn't and it's a bit 
confusing having a way to initialize these that you think might be 
called.  (I know you didn't say this, I'm piling, I mean adding, on).

>
>>
>>>
>>>  It's called from VirtualSpaceNode so you should be able to pass
>>> "this" along to Metachunk::initialize. That will save us the walking
>>> of VirtualSpaceList to find the correct node to increment the count 
>>> for.
>>>
>>> If you set up Metachunk::_container in Metachunk::_initialize you
>>> could also skip the wrapper for ChunkManager::chunk_freelist_allocate
>>> inside VirtualSpaceList and just add:
>>>
>>> if (next != NULL) {
>>>   next->container()->inc_container_count();
>>> }
>>> at the end of VirtualSpaceList::get_new_chunk
>>>
>>> You are not decreasing the _container_count when returning humongous
>>> chunks in ~SpaceManager:
>>> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
>>> // here you could do a
>>> humongous_chunks->container()->dec_container_count();
>>> 2124
>>> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>>>
>>> You are already incrementing _container_count for humongous chunks
>>> allocated from the hum chunk free list because those allocations go
>>> through the chunk_freelist_allocate wrapper function you added.
>>>
>>> It also feels strange that inc_container_count() is private but
>>> dec_container_count and container_count() are public. I realize that
>>> it works currently because VirtualSpaceList is a friend of
>>> VirtualSpaceNode but it seems like a strange level of encapsulation.
>>>
>>>
>>> The class space only contains one VirtualSpaceNode currently, should
>>> we add some code to make sure that we don't accidentally free that
>>> memory?
>>>
>>
>> The class space can contain >1 virtual space nodes if
>> !UseCompressedKlassPointers right now so you can purge unused spaces.
>> I'm making this go away.
>>
>> It looks like you find the containing virtual space node when you
>> deallocate the chunks which looks really expensive.   Why not have all
>> the chunks have a field with their container when they are created or
>> reused?  Am I reading this wrong?   These two "contains()" calls at
>> lines 2033, 2034 are going to be killer.
>
> This is exactly what I was saying above:
>
> >> Why don't you set the Metachunk::_container field in
> >> Metachunk::initialize():
> >>
> >>  776   // Point the chunk at the space
> >>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
> >> chunk_word_size);
>
> We could easily pass on the VirtualSpaceNode to Metachunk::initialize.
>

Ok. I didn't read the counter code so didn't match your comment.
>
>>
>>
>> At 932, you should not purge the current virtual space, I think, because
>> you might just allocate it again.
>
> There might be loads and loads of free chunks in the other virtual 
> spaces and we may be recovering from a spike in metaspace allocation.
> If we are able to release metaspace memory I think we should.
> It feels pretty unlikely that we'll end up with a VirtualSpaceNode 
> with a count of 0 so we should take every chance we get to free one up 
> IMO.

Maybe, I guess.   What were the tracing results of this change? (ques 
for Jon).   Do we see these things going away on our favorite nashorn 
application?

thanks,
Coleen

>
> /Mikael
>
>>
>> Around 928, why do you have to walk the virtual space itself? Why not
>> walk the linked list of free chunks for the container entry that matches
>> the virtual space node if the virtual space count is null? You could do
>> one walk and remove all entries with all virtual space nodes that are
>> matching if you are worried about the loop in the loop.   It has to find
>> the chunk in the free list anyway to remove it.
>>
>> This is a nit of mine.   Can you move the declaration at 805 to 807
>> where the initial value is returned?
>>
>> Thanks!
>> Coleen
>>
>>> /Mikael
>>>
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>>
>>>> Thanks.
>>>>
>>>> Jon
>>



From jon.masamitsu at oracle.com  Fri Apr  5 14:52:41 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 05 Apr 2013 07:52:41 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515E01A0.4090604@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
	<515E01A0.4090604@oracle.com>
Message-ID: <515EE539.6040509@oracle.com>

Coleen,

Thanks for taking a look.

On 4/4/2013 3:41 PM, Coleen Phillimore wrote:
>
> Hi Jon,
>
> Mikael's review is more thorough than what I've looked at so far. I 
> wanted to add to it and my own comments at the end.   I didn't realize 
> you were working on this.  This is far less code than changing our 
> allocation scheme to malloc!

Yes, but it doesn't do as good a job either.

>
> On 04/04/2013 08:28 AM, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2013-04-04 06:00, Jon Masamitsu wrote:
>>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>
>> The webrev is a bit confusing since it says for metaspace.cpp:
>> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with 
>> class FreeList<Metachunk>
>> Reviewed-by: mgerdin
>>
>> this implies to me that the 8011173 patch is included in this webrev 
>> when in fact this webrev is incremental on top of that patch.
>> I don't know if that was intentional or not but it confused me a bit 
>> when trying to apply this patch.
>>
>> I'm totally fine with incremental webrevs though, just as long as 
>> they are advertised as such :)
>>
>>>
>>> When the classes for a dead class loader are unloaded, all the 
>>> Metachunks
>>> that had been used by that class loader are put on the Metachunk
>>> free list for later reuse.   If all the Metachunks allocated out of a
>>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>>   from the free list and deallocate the VirtualSpaceNode.
>>>
>>> The constructor for VirtualSpaceNode was moved to be below the
>>> definition of
>>> SpaceManager.
>>
>> I'm not sure why you moved the VirtualSpaceNode constructor to after 
>> the definition of SpaceManager, but I see that 
>> {inc,dec}_container_count need to reference the expand_lock().
>>
>
> You moved the constructor for VirtualSpaceNode but the gc baseline 
> doesn't have changes I made to it recently, so moving it will not get 
> the most recent changes from hotspot-rt.

I'll move it back.

>
>
>> Also, when I applied your patch and looked at the code in eclipse it 
>> helpfully notified me that you are forgetting to initialize 
>> _container_count in the VirtualSpaceNode constructor that you moved.
>>
>> Why don't you set the Metachunk::_container field in 
>> Metachunk::initialize():
>>
>>  776   // Point the chunk at the space
>>  777   Metachunk* result = Metachunk::initialize(chunk_limit, 
>> chunk_word_size);
>>  778   return result;
>
> In fact, I believe the Metachunk constructor is never called. Pointers 
> are transformed into these.  If that's the case the Metachunk 
> constructors should be removed.

Removed.

>
>>
>>  It's called from VirtualSpaceNode so you should be able to pass 
>> "this" along to Metachunk::initialize. That will save us the walking 
>> of VirtualSpaceList to find the correct node to increment the count for.
>>
>> If you set up Metachunk::_container in Metachunk::_initialize you 
>> could also skip the wrapper for ChunkManager::chunk_freelist_allocate 
>> inside VirtualSpaceList and just add:
>>
>> if (next != NULL) {
>>   next->container()->inc_container_count();
>> }
>> at the end of VirtualSpaceList::get_new_chunk
>>
>> You are not decreasing the _container_count when returning humongous 
>> chunks in ~SpaceManager:
>> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
>> // here you could do a
>> humongous_chunks->container()->dec_container_count();
>> 2124 
>> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>>
>> You are already incrementing _container_count for humongous chunks 
>> allocated from the hum chunk free list because those allocations go 
>> through the chunk_freelist_allocate wrapper function you added.
>>
>> It also feels strange that inc_container_count() is private but 
>> dec_container_count and container_count() are public. I realize that 
>> it works currently because VirtualSpaceList is a friend of 
>> VirtualSpaceNode but it seems like a strange level of encapsulation.
>>
>>
>> The class space only contains one VirtualSpaceNode currently, should 
>> we add some code to make sure that we don't accidentally free that 
>> memory?
>>
>
> The class space can contain >1 virtual space nodes if 
> !UseCompressedKlassPointers right now so you can purge unused 
> spaces.   I'm making this go away.
>
> It looks like you find the containing virtual space node when you 
> deallocate the chunks which looks really expensive.   Why not have all 
> the chunks have a field with their container when they are created or 
> reused?  Am I reading this wrong?   These two "contains()" calls at 
> lines 2033, 2034 are going to be killer.
>
Yes, there we two.  I'm following Mikael and your suggestion setting the 
container at
allocation.

>
> At 932, you should not purge the current virtual space, I think, 
> because you might just allocate it again.

Fixed.

>
> Around 928, why do you have to walk the virtual space itself?  Why not 
> walk the linked list of free chunks for the container entry that 
> matches the virtual space node if the virtual space count is null? You 
> could do one walk and remove all entries with all virtual space nodes 
> that are matching if you are worried about the loop in the loop.   It 
> has to find the chunk in the free list anyway to remove it.

That code is gone now.

When I changed the ChunkList to be FreeList<Metachunk> the list became 
doubly linked
so I didn't have to walk the whole list to remove a chunk.

>
> This is a nit of mine.   Can you move the declaration at 805 to 807 
> where the initial value is returned?

Done.

Thanks.

Jon

>
> Thanks!
> Coleen
>
>> /Mikael
>>
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>
>>> Thanks.
>>>
>>> Jon
>



From bengt.rutisson at oracle.com  Fri Apr  5 15:15:18 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 05 Apr 2013 17:15:18 +0200
Subject: RFE (m): JDK-7197666: java -d64 -version core dumps in a box
	with lots of memory
In-Reply-To: <515DDA75.1090707@oracle.com>
References: <5154BF9A.2080208@oracle.com> <515D6F44.4050909@oracle.com>
	<515DDA75.1090707@oracle.com>
Message-ID: <515EEA86.5000701@oracle.com>


Hi Jon,

Thanks for looking at this!

On 4/4/13 9:54 PM, Jon Masamitsu wrote:
> Bengt,
>
> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/src/share/vm/memory/allocation.inline.hpp.frames.html
>
>   118   if (_use_malloc) {
>   119     _addr = AllocateHeap(_size, F);
>   120     return (E*)_addr;
>   121   }
>
>
> Did you consider checking the value of _addr and going on
> to the mmap based allocation if the malloc() failed?

That's a good idea! I added that logic. I only try mmap if the size is 
larger than one page. It seems to me that if we are failing really small 
allocations we should not be trying to continue and if we would start 
mmapping really small sizes we will waste a lot of memory since mmapped 
memory needs to be page aligned.

Here is an updated webrev including the fixed comment suggested by John 
Cuthbertson too:

http://cr.openjdk.java.net/~brutisso/7197666/webrev.02/

Thanks,
Bengt

>
> Jon
>
> On 4/4/13 5:17 AM, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Coleen and Thomas have already looked at the preliminary version of 
>> this request. Thanks!
>>
>> Removing the preliminary part of this request now and asking for full 
>> reviews.
>>
>> Here is an updated webrev based on the comments from Coleen and Thomas:
>>
>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/
>>
>> Thanks,
>> Bengt
>>
>>
>> On 3/28/13 11:09 PM, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Sending this to both runtime and GC since I think it concerns both 
>>> areas.
>>>
>>> I'd like some feedback on this preliminary change. I still want to 
>>> do some more testing and evaluation before I ask for final reviews:
>>>
>>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>>>
>>> In particular I would like some feedback on these questions:
>>>
>>> - I am adding a flag that has the same value on all platforms except 
>>> Solaris x86. There is the product_pd flag macro to support this. But 
>>> there is no experimental_pd marcro. I would have preferred to make 
>>> my new flag experimental. Should I add experimental_pd or should I 
>>> just use a product flag?
>>>
>>> - Even with product_pd I think I still have to go in to all the 
>>> different platform files and add the exact same code to give the 
>>> flag a default value on all platforms. Is there a way to have a 
>>> default value and only override it on Solaris x86?
>>>
>>> - The class I am adding, ArrayAllocator, wants to choose between 
>>> doing malloc and mmap. Normally we use ReservedSpace and 
>>> VirtualSpace to get mapped memory. However, those classes are kind 
>>> of clumsy when I just want to allocate one chunk of memory. It is 
>>> much simpler to use the os::reserve_memory() and os::commit_memory() 
>>> methods directly. I think my use case here motivate using these 
>>> methods directly, but is there some reason not to do that?
>>>
>>> Some background on the change:
>>>
>>> The default implementation of malloc on Solaris has several 
>>> limitation compared to malloc on other platforms. One limitation is 
>>> that it can only use one consecutive chunk of memory. Another 
>>> limitation is that it always allocates in this single chunk of 
>>> memory no matter how large the requested amount of memory is. Other 
>>> malloc implementations normally use mapped memory for large allocations.
>>>
>>> The Java heap is mapped in memory and we try to pick a good address 
>>> for it. The lowest allowed address is controlled by 
>>> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other 
>>> platforms have at least 2 GB). Since the C heap ends up below the 
>>> Java heap it means that in some cases it is limited to 256 MB.
>>>
>>> When we run with ParallelOldGC we get three task queues per GC 
>>> thread. Each task queue takes mallocs 1MB. The failing machine in 
>>> the bug report has lots of CPUs and ends up with 83 GC threads. This 
>>> is 249 MB, which is more than we can get out of the 256 MB limited C 
>>> heap considering that there are other things that get malloced too.
>>>
>>> So, the problems occur mostly on Solaris x86. My suggested fix tries 
>>> to address this by letting the task queues be mapped instead of 
>>> malloced on Solaris x86. Instead of inlining this logic in 
>>> taskqueue.cpp I added a more general class. The reason for this is 
>>> that I think we need to use the same logic in more places, 
>>> especially for G1, which is mallocing quite a lot.
>>>
>>> Since I think malloc on other platforms use mapped memory for large 
>>> malloc requests I think it is enough for this change to have effect 
>>> on Solaris. The other platforms probably have better heuristics than 
>>> I can come up with for which sizes should be mapped. On Sparc we 
>>> have the same limitation with malloc, but we have more memory 
>>> available for the C heap. This is why I have only enabled this for 
>>> Solaris x86.
>>>
>>> Also, I will be on vacation for a few days. Back in the office 
>>> Thrusday April 4. I'm happy for any feedback on this, but if I don't 
>>> respond until next week you know why :)
>>>
>>> Thanks,
>>> Bengt
>>
>

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

From jon.masamitsu at oracle.com  Fri Apr  5 15:37:23 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 05 Apr 2013 08:37:23 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515EAB40.6070206@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
	<515E01A0.4090604@oracle.com> <515EAB40.6070206@oracle.com>
Message-ID: <515EEFB3.1020509@oracle.com>


On 4/5/2013 3:45 AM, Mikael Gerdin wrote:
>
>
> On 2013-04-05 00:41, Coleen Phillimore wrote:
>>
>> Hi Jon,
>>
>> Mikael's review is more thorough than what I've looked at so far.  I
>> wanted to add to it and my own comments at the end.   I didn't realize
>> you were working on this.  This is far less code than changing our
>> allocation scheme to malloc!
>>
>> On 04/04/2013 08:28 AM, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2013-04-04 06:00, Jon Masamitsu wrote:
>>>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>>
>>> The webrev is a bit confusing since it says for metaspace.cpp:
>>> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with
>>> class FreeList<Metachunk>
>>> Reviewed-by: mgerdin
>>>
>>> this implies to me that the 8011173 patch is included in this webrev
>>> when in fact this webrev is incremental on top of that patch.
>>> I don't know if that was intentional or not but it confused me a bit
>>> when trying to apply this patch.
>>>
>>> I'm totally fine with incremental webrevs though, just as long as they
>>> are advertised as such :)
>>>
>>>>
>>>> When the classes for a dead class loader are unloaded, all the
>>>> Metachunks
>>>> that had been used by that class loader are put on the Metachunk
>>>> free list for later reuse.   If all the Metachunks allocated out of a
>>>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>>>   from the free list and deallocate the VirtualSpaceNode.
>>>>
>>>> The constructor for VirtualSpaceNode was moved to be below the
>>>> definition of
>>>> SpaceManager.
>>>
>>> I'm not sure why you moved the VirtualSpaceNode constructor to after
>>> the definition of SpaceManager, but I see that
>>> {inc,dec}_container_count need to reference the expand_lock().
>>>
>>
>> You moved the constructor for VirtualSpaceNode but the gc baseline
>> doesn't have changes I made to it recently, so moving it will not get
>> the most recent changes from hotspot-rt.
>
> FWIW those changes are actually in hotspot-gc so Jon will need to 
> merge with them before pushing.

I moved it back and will do a merge and look really hard at the 
constructor  (before and after)

>
>>
>>
>>> Also, when I applied your patch and looked at the code in eclipse it
>>> helpfully notified me that you are forgetting to initialize
>>> _container_count in the VirtualSpaceNode constructor that you moved.
>>>
>>> Why don't you set the Metachunk::_container field in
>>> Metachunk::initialize():
>>>
>>>  776   // Point the chunk at the space
>>>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
>>> chunk_word_size);
>>>  778   return result;
>>
>> In fact, I believe the Metachunk constructor is never called. Pointers
>> are transformed into these.  If that's the case the Metachunk
>> constructors should be removed.
>
> I don't see where I said anything about the Metachunk constructor.
>
> But the line where we call Metachunk::initialize is where we 
> initialize the memory that we allocated for the chunk is set up.
>
> I would prefer it if we could replace this with a call to the 
> placement new operator and use a constructor to set up the Metachunk 
> object but I'm not going to go into that argument.

Will do.

>
>>
>>>
>>>  It's called from VirtualSpaceNode so you should be able to pass
>>> "this" along to Metachunk::initialize. That will save us the walking
>>> of VirtualSpaceList to find the correct node to increment the count 
>>> for.
>>>
>>> If you set up Metachunk::_container in Metachunk::_initialize you
>>> could also skip the wrapper for ChunkManager::chunk_freelist_allocate
>>> inside VirtualSpaceList and just add:
>>>
>>> if (next != NULL) {
>>>   next->container()->inc_container_count();
>>> }
>>> at the end of VirtualSpaceList::get_new_chunk
>>>
>>> You are not decreasing the _container_count when returning humongous
>>> chunks in ~SpaceManager:
>>> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
>>> // here you could do a
>>> humongous_chunks->container()->dec_container_count();
>>> 2124
>>> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>>>
>>> You are already incrementing _container_count for humongous chunks
>>> allocated from the hum chunk free list because those allocations go
>>> through the chunk_freelist_allocate wrapper function you added.
>>>
>>> It also feels strange that inc_container_count() is private but
>>> dec_container_count and container_count() are public. I realize that
>>> it works currently because VirtualSpaceList is a friend of
>>> VirtualSpaceNode but it seems like a strange level of encapsulation.
>>>
>>>
>>> The class space only contains one VirtualSpaceNode currently, should
>>> we add some code to make sure that we don't accidentally free that
>>> memory?
>>>
>>
>> The class space can contain >1 virtual space nodes if
>> !UseCompressedKlassPointers right now so you can purge unused spaces.
>> I'm making this go away.
>>
>> It looks like you find the containing virtual space node when you
>> deallocate the chunks which looks really expensive.   Why not have all
>> the chunks have a field with their container when they are created or
>> reused?  Am I reading this wrong?   These two "contains()" calls at
>> lines 2033, 2034 are going to be killer.
>
> This is exactly what I was saying above:
>
> >> Why don't you set the Metachunk::_container field in
> >> Metachunk::initialize():
> >>
> >>  776   // Point the chunk at the space
> >>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
> >> chunk_word_size);
>
> We could easily pass on the VirtualSpaceNode to Metachunk::initialize.
>
>
>>
>>
>> At 932, you should not purge the current virtual space, I think, because
>> you might just allocate it again.
>
> There might be loads and loads of free chunks in the other virtual 
> spaces and we may be recovering from a spike in metaspace allocation.
> If we are able to release metaspace memory I think we should.
> It feels pretty unlikely that we'll end up with a VirtualSpaceNode 
> with a count of 0 so we should take every chance we get to free one up 
> IMO.

I think the common case will be that the current_virtual_list will not have
a container count that  is 0 so most of the time it will not matter.  If 
we do
free the current_virtual_list, the replacement will most often already
be full (that's why it is not the current one), so we'll need a new one.
I'm like to not free the current_virtual_list and see how it does.

Jon

>
> /Mikael
>
>>
>> Around 928, why do you have to walk the virtual space itself? Why not
>> walk the linked list of free chunks for the container entry that matches
>> the virtual space node if the virtual space count is null? You could do
>> one walk and remove all entries with all virtual space nodes that are
>> matching if you are worried about the loop in the loop.   It has to find
>> the chunk in the free list anyway to remove it.
>>
>> This is a nit of mine.   Can you move the declaration at 805 to 807
>> where the initial value is returned?
>>
>> Thanks!
>> Coleen
>>
>>> /Mikael
>>>
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>>
>>>> Thanks.
>>>>
>>>> Jon
>>



From jon.masamitsu at oracle.com  Fri Apr  5 15:42:16 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 05 Apr 2013 08:42:16 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515EBD17.5070803@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
	<515E01A0.4090604@oracle.com> <515EAB40.6070206@oracle.com>
	<515EBD17.5070803@oracle.com>
Message-ID: <515EF0D8.6080405@oracle.com>


On 4/5/2013 5:01 AM, Coleen Phillimore wrote:
> On 4/5/2013 6:45 AM, Mikael Gerdin wrote:
>>
>>
>> On 2013-04-05 00:41, Coleen Phillimore wrote:
>>>
>>> Hi Jon,
>>>
>>> Mikael's review is more thorough than what I've looked at so far.  I
>>> wanted to add to it and my own comments at the end.   I didn't realize
>>> you were working on this.  This is far less code than changing our
>>> allocation scheme to malloc!
>>>
>>> On 04/04/2013 08:28 AM, Mikael Gerdin wrote:
>>>> Jon,
>>>>
>>>> On 2013-04-04 06:00, Jon Masamitsu wrote:
>>>>> After class unloading deallocate any VirtualSpaceNodes not being 
>>>>> used.
>>>>
>>>> The webrev is a bit confusing since it says for metaspace.cpp:
>>>> rev 4373 : 8011173: NPG: Replace the ChunkList implementation with
>>>> class FreeList<Metachunk>
>>>> Reviewed-by: mgerdin
>>>>
>>>> this implies to me that the 8011173 patch is included in this webrev
>>>> when in fact this webrev is incremental on top of that patch.
>>>> I don't know if that was intentional or not but it confused me a bit
>>>> when trying to apply this patch.
>>>>
>>>> I'm totally fine with incremental webrevs though, just as long as they
>>>> are advertised as such :)
>>>>
>>>>>
>>>>> When the classes for a dead class loader are unloaded, all the
>>>>> Metachunks
>>>>> that had been used by that class loader are put on the Metachunk
>>>>> free list for later reuse.   If all the Metachunks allocated out of a
>>>>> VirtualSpaceNode are on the Metachunk free list, remove the 
>>>>> Metachunks
>>>>>   from the free list and deallocate the VirtualSpaceNode.
>>>>>
>>>>> The constructor for VirtualSpaceNode was moved to be below the
>>>>> definition of
>>>>> SpaceManager.
>>>>
>>>> I'm not sure why you moved the VirtualSpaceNode constructor to after
>>>> the definition of SpaceManager, but I see that
>>>> {inc,dec}_container_count need to reference the expand_lock().
>>>>
>>>
>>> You moved the constructor for VirtualSpaceNode but the gc baseline
>>> doesn't have changes I made to it recently, so moving it will not get
>>> the most recent changes from hotspot-rt.
>>
>> FWIW those changes are actually in hotspot-gc so Jon will need to 
>> merge with them before pushing.
>
> He should merge before moving this because I think a trivial mercurial 
> merge might miss these changes, or mercurial might barf on the whole 
> thing.  I don't know.  Just a warning.  I don't mind that it's moved.

I'll merge and look hard at the constructor to be sure I get your changes.


>
>>
>>>
>>>
>>>> Also, when I applied your patch and looked at the code in eclipse it
>>>> helpfully notified me that you are forgetting to initialize
>>>> _container_count in the VirtualSpaceNode constructor that you moved.
>>>>
>>>> Why don't you set the Metachunk::_container field in
>>>> Metachunk::initialize():
>>>>
>>>>  776   // Point the chunk at the space
>>>>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
>>>> chunk_word_size);
>>>>  778   return result;
>>>
>>> In fact, I believe the Metachunk constructor is never called. Pointers
>>> are transformed into these.  If that's the case the Metachunk
>>> constructors should be removed.
>>
>> I don't see where I said anything about the Metachunk constructor.
>>
>> But the line where we call Metachunk::initialize is where we 
>> initialize the memory that we allocated for the chunk is set up.
>>
>> I would prefer it if we could replace this with a call to the 
>> placement new operator and use a constructor to set up the Metachunk 
>> object but I'm not going to go into that argument.
>
> Yes, I agree with you, placement new would be a lot nicer and then the 
> constructor would be called.   Right now it isn't and it's a bit 
> confusing having a way to initialize these that you think might be 
> called.  (I know you didn't say this, I'm piling, I mean adding, on).

On the way.

>
>>
>>>
>>>>
>>>>  It's called from VirtualSpaceNode so you should be able to pass
>>>> "this" along to Metachunk::initialize. That will save us the walking
>>>> of VirtualSpaceList to find the correct node to increment the count 
>>>> for.
>>>>
>>>> If you set up Metachunk::_container in Metachunk::_initialize you
>>>> could also skip the wrapper for ChunkManager::chunk_freelist_allocate
>>>> inside VirtualSpaceList and just add:
>>>>
>>>> if (next != NULL) {
>>>>   next->container()->inc_container_count();
>>>> }
>>>> at the end of VirtualSpaceList::get_new_chunk
>>>>
>>>> You are not decreasing the _container_count when returning humongous
>>>> chunks in ~SpaceManager:
>>>> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
>>>> // here you could do a
>>>> humongous_chunks->container()->dec_container_count();
>>>> 2124
>>>> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>>>>
>>>> You are already incrementing _container_count for humongous chunks
>>>> allocated from the hum chunk free list because those allocations go
>>>> through the chunk_freelist_allocate wrapper function you added.
>>>>
>>>> It also feels strange that inc_container_count() is private but
>>>> dec_container_count and container_count() are public. I realize that
>>>> it works currently because VirtualSpaceList is a friend of
>>>> VirtualSpaceNode but it seems like a strange level of encapsulation.
>>>>
>>>>
>>>> The class space only contains one VirtualSpaceNode currently, should
>>>> we add some code to make sure that we don't accidentally free that
>>>> memory?
>>>>
>>>
>>> The class space can contain >1 virtual space nodes if
>>> !UseCompressedKlassPointers right now so you can purge unused spaces.
>>> I'm making this go away.
>>>
>>> It looks like you find the containing virtual space node when you
>>> deallocate the chunks which looks really expensive.   Why not have all
>>> the chunks have a field with their container when they are created or
>>> reused?  Am I reading this wrong?   These two "contains()" calls at
>>> lines 2033, 2034 are going to be killer.
>>
>> This is exactly what I was saying above:
>>
>> >> Why don't you set the Metachunk::_container field in
>> >> Metachunk::initialize():
>> >>
>> >>  776   // Point the chunk at the space
>> >>  777   Metachunk* result = Metachunk::initialize(chunk_limit,
>> >> chunk_word_size);
>>
>> We could easily pass on the VirtualSpaceNode to Metachunk::initialize.
>>
>
> Ok. I didn't read the counter code so didn't match your comment.
>>
>>>
>>>
>>> At 932, you should not purge the current virtual space, I think, 
>>> because
>>> you might just allocate it again.
>>
>> There might be loads and loads of free chunks in the other virtual 
>> spaces and we may be recovering from a spike in metaspace allocation.
>> If we are able to release metaspace memory I think we should.
>> It feels pretty unlikely that we'll end up with a VirtualSpaceNode 
>> with a count of 0 so we should take every chance we get to free one 
>> up IMO.
>
> Maybe, I guess.   What were the tracing results of this change? (ques 
> for Jon).   Do we see these things going away on our favorite nashorn 
> application?

I ran runThese -quick that I know has at some point lots of excess 
capacity.  Nashorn as I
recall has Metaspace usage that rises and then levels off and stays at 
the level
(keeps freeing and reallocating metadata so no excessive capacity that 
is not
used).

Jon

>
> thanks,
> Coleen
>
>>
>> /Mikael
>>
>>>
>>> Around 928, why do you have to walk the virtual space itself? Why not
>>> walk the linked list of free chunks for the container entry that 
>>> matches
>>> the virtual space node if the virtual space count is null? You could do
>>> one walk and remove all entries with all virtual space nodes that are
>>> matching if you are worried about the loop in the loop.   It has to 
>>> find
>>> the chunk in the free list anyway to remove it.
>>>
>>> This is a nit of mine.   Can you move the declaration at 805 to 807
>>> where the initial value is returned?
>>>
>>> Thanks!
>>> Coleen
>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jon
>>>
>



From jon.masamitsu at oracle.com  Sat Apr  6 01:48:59 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 05 Apr 2013 18:48:59 -0700
Subject: RFE (m): JDK-7197666: java -d64 -version core dumps in a box
	with lots of memory
In-Reply-To: <515EEA86.5000701@oracle.com>
References: <5154BF9A.2080208@oracle.com> <515D6F44.4050909@oracle.com>
	<515DDA75.1090707@oracle.com> <515EEA86.5000701@oracle.com>
Message-ID: <515F7F0B.5070307@oracle.com>


On 4/5/2013 8:15 AM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Thanks for looking at this!
>
> On 4/4/13 9:54 PM, Jon Masamitsu wrote:
>> Bengt,
>>
>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/src/share/vm/memory/allocation.inline.hpp.frames.html 
>>
>>
>>   118   if (_use_malloc) {
>>   119     _addr = AllocateHeap(_size, F);
>>   120     return (E*)_addr;
>>   121   }
>>
>>
>> Did you consider checking the value of _addr and going on
>> to the mmap based allocation if the malloc() failed?
>
> That's a good idea! I added that logic. I only try mmap if the size is 
> larger than one page. It seems to me that if we are failing really 
> small allocations we should not be trying to continue and if we would 
> start mmapping really small sizes we will waste a lot of memory since 
> mmapped memory needs to be page aligned.
>
> Here is an updated webrev including the fixed comment suggested by 
> John Cuthbertson too:
>
> http://cr.openjdk.java.net/~brutisso/7197666/webrev.02/

Thanks.  Looks good.

Jon

>
> Thanks,
> Bengt
>
>>
>> Jon
>>
>> On 4/4/13 5:17 AM, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Coleen and Thomas have already looked at the preliminary version of 
>>> this request. Thanks!
>>>
>>> Removing the preliminary part of this request now and asking for 
>>> full reviews.
>>>
>>> Here is an updated webrev based on the comments from Coleen and Thomas:
>>>
>>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.01/
>>>
>>> Thanks,
>>> Bengt
>>>
>>>
>>> On 3/28/13 11:09 PM, Bengt Rutisson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Sending this to both runtime and GC since I think it concerns both 
>>>> areas.
>>>>
>>>> I'd like some feedback on this preliminary change. I still want to 
>>>> do some more testing and evaluation before I ask for final reviews:
>>>>
>>>> http://cr.openjdk.java.net/~brutisso/7197666/webrev.00/
>>>>
>>>> In particular I would like some feedback on these questions:
>>>>
>>>> - I am adding a flag that has the same value on all platforms 
>>>> except Solaris x86. There is the product_pd flag macro to support 
>>>> this. But there is no experimental_pd marcro. I would have 
>>>> preferred to make my new flag experimental. Should I add 
>>>> experimental_pd or should I just use a product flag?
>>>>
>>>> - Even with product_pd I think I still have to go in to all the 
>>>> different platform files and add the exact same code to give the 
>>>> flag a default value on all platforms. Is there a way to have a 
>>>> default value and only override it on Solaris x86?
>>>>
>>>> - The class I am adding, ArrayAllocator, wants to choose between 
>>>> doing malloc and mmap. Normally we use ReservedSpace and 
>>>> VirtualSpace to get mapped memory. However, those classes are kind 
>>>> of clumsy when I just want to allocate one chunk of memory. It is 
>>>> much simpler to use the os::reserve_memory() and 
>>>> os::commit_memory() methods directly. I think my use case here 
>>>> motivate using these methods directly, but is there some reason not 
>>>> to do that?
>>>>
>>>> Some background on the change:
>>>>
>>>> The default implementation of malloc on Solaris has several 
>>>> limitation compared to malloc on other platforms. One limitation is 
>>>> that it can only use one consecutive chunk of memory. Another 
>>>> limitation is that it always allocates in this single chunk of 
>>>> memory no matter how large the requested amount of memory is. Other 
>>>> malloc implementations normally use mapped memory for large 
>>>> allocations.
>>>>
>>>> The Java heap is mapped in memory and we try to pick a good address 
>>>> for it. The lowest allowed address is controlled by 
>>>> HeapBaseMinAddress. This is only 256 MB on Solaris x86 (other 
>>>> platforms have at least 2 GB). Since the C heap ends up below the 
>>>> Java heap it means that in some cases it is limited to 256 MB.
>>>>
>>>> When we run with ParallelOldGC we get three task queues per GC 
>>>> thread. Each task queue takes mallocs 1MB. The failing machine in 
>>>> the bug report has lots of CPUs and ends up with 83 GC threads. 
>>>> This is 249 MB, which is more than we can get out of the 256 MB 
>>>> limited C heap considering that there are other things that get 
>>>> malloced too.
>>>>
>>>> So, the problems occur mostly on Solaris x86. My suggested fix 
>>>> tries to address this by letting the task queues be mapped instead 
>>>> of malloced on Solaris x86. Instead of inlining this logic in 
>>>> taskqueue.cpp I added a more general class. The reason for this is 
>>>> that I think we need to use the same logic in more places, 
>>>> especially for G1, which is mallocing quite a lot.
>>>>
>>>> Since I think malloc on other platforms use mapped memory for large 
>>>> malloc requests I think it is enough for this change to have effect 
>>>> on Solaris. The other platforms probably have better heuristics 
>>>> than I can come up with for which sizes should be mapped. On Sparc 
>>>> we have the same limitation with malloc, but we have more memory 
>>>> available for the C heap. This is why I have only enabled this for 
>>>> Solaris x86.
>>>>
>>>> Also, I will be on vacation for a few days. Back in the office 
>>>> Thrusday April 4. I'm happy for any feedback on this, but if I 
>>>> don't respond until next week you know why :)
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>
>
>



From john.cuthbertson at oracle.com  Sat Apr  6 02:06:48 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Sat, 06 Apr 2013 02:06:48 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011343: Add new flag for verifying the
	heap during startup
Message-ID: <20130406020652.A98AC4810A@hg.openjdk.java.net>

Changeset: 68fe50d4f1d5
Author:    johnc
Date:      2013-04-05 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/68fe50d4f1d5

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java



From jon.masamitsu at oracle.com  Sat Apr  6 16:21:56 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Sat, 06 Apr 2013 09:21:56 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515E4DEF.2060702@oracle.com>
References: <515CFAE6.8010903@oracle.com> <515D71E3.9000300@oracle.com>
	<515E4DEF.2060702@oracle.com>
Message-ID: <51604BA4.8080707@oracle.com>


On 4/4/2013 9:07 PM, Jon Masamitsu wrote:
> ...
>
>>
>> You are not decreasing the _container_count when returning humongous 
>> chunks in ~SpaceManager:
>> 2123     Metachunk* next_humongous_chunks = humongous_chunks->next();
>> // here you could do a
>> humongous_chunks->container()->dec_container_count();
>> 2124 
>> chunk_manager->humongous_dictionary()->return_chunk(humongous_chunks);
>>
>> You are already incrementing _container_count for humongous chunks 
>> allocated from the hum chunk free list because those allocations go 
>> through the chunk_freelist_allocate wrapper function you added.
>
> A VirtualSpace that contains 1 Metachunk holds nothing else so that 
> decrementing
> the count on such a VirtualSpace will deallocate it.  I'll try it but 
> may revert it.
>
>

My statement above is wrong.  A VirtualSpace can hold more than 1 
humongous block.

Jon
>>
>> It also feels strange that inc_container_count() is private but 
>> dec_container_count and container_count() are public. I realize that 
>> it works currently because VirtualSpaceList is a friend of 
>> VirtualSpaceNode but it seems like a strange level of encapsulation.
>
> Isn't incrementing the counter done by a VirtualSpaceNode
> and decrementing done by a SpaceManager for the dec_container_count()
> needs to be public?
>>
>>
>> The class space only contains one VirtualSpaceNode currently, should 
>> we add some code to make sure that we don't accidentally free that 
>> memory?
>
> Let me defer this because I think Coleen had something to say.
>
> Thanks.
>
> Jon
>>
>> /Mikael
>>
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>
>>> Thanks.
>>>
>>> Jon
>



From jon.masamitsu at oracle.com  Sun Apr  7 04:33:25 2013
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Sun, 07 Apr 2013 04:33:25 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8008508: CMS does not correctly reduce
	heap size after a Full GC
Message-ID: <20130407043331.0C1AF4811B@hg.openjdk.java.net>

Changeset: 8617e38bb4cb
Author:    jmasa
Date:      2013-02-11 10:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8617e38bb4cb

8008508: CMS does not correctly reduce heap size after a Full GC
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/runtime/vmStructs.cpp



From jesper.wilhelmsson at oracle.com  Sun Apr  7 06:54:09 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Sun, 07 Apr 2013 08:54:09 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <5154B427.2060503@oracle.com>
References: <51549110.2010208@oracle.com> <5154B427.2060503@oracle.com>
Message-ID: <51611811.2010403@oracle.com>

Bengt, all,

A new webrev is now available:

http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/

The main difference is that now we have an array in G1CollectedHeap that keeps 
track the EvacuationFailedInfo-objects between the different parallel parts of 
G1 so that each thread only sends a single EvacuationFailed event in the end.

To achieve this some logic was added to find the correct info object in the 
array since the threads does not have the same queue number each time.

Thanks,
/Jesper


Bengt Rutisson skrev 28/3/13 10:20 PM:
>
> Jesper,
>
> This looks much better!
>
> Have you tested it to see that you get a maximum of one event per GC thread and
> GC? It looks to me like you risk getting multiple events sent for each GC thread
> every GC.
>
> You send the events in the G1ParScanThreadState destructor. I am not that
> familiar with G1ParScanThreadState but it looks to me like we create new
> G1ParScanThreadState instances for the different phases of a GC. Here are the
> places where we create new instances of G1ParScanThreadState:
>
> G1CollectedHeap::process_discovered_references()
> G1ParPreserveCMReferentsTask::work()
> G1ParTask::work()
> G1STWRefProcTaskProxy::work()
>
> So, it looks to me like we risk getting 4 events sent per thread and GC.
>
>
> Some minor comments:
>
> In G1CollectedHeap::handle_evacuation_failure_par() you pass the ef_info on to
> G1CollectedHeap::handle_evacuation_failure_common(). But the ef_info is now
> thread local so you don't have to take the lock to use it. One way to simplify
> this would be to do "ef_info->register_copy_failure(old->size());" in
> G1CollectedHeap::handle_evacuation_failure_par() just before "if
> (_evac_failure_closure != cl)" instead. Then you don't have to pass it on to
> handle_evacuation_failure_common().
>
> (As a side note, I don't think setting _evacuation_failed to true has to be
> protected by the lock either. It is a shared variable but all writes to it from
> different threads will be to set it to true, so I think racing on it is benign.
> But you have it in the same place as before, which might be good.)
>
> In G1ParCopyClosure::copy_to_survivor_space() you are now picking out two thing
> from the _par_scan_state and passing them on to
> G1CollectedHeap::handle_evacuation_failure_par(). Have you considered passing a
> reference to _par_scan_state instead and let handle_evacuation_failure_par()
> extract the data it needs?
>
> If you move the implementation of the destructor of G1ParScanThreadState in to
> the cpp file you don't have to add the include for gcTrace.hpp to
> g1CollectedHeap.hpp.
>
> Why did you decide to remove set_evactuation_failed()?
>
> Finally, you have several quite unrelated spelling corrections in this change.
> This makes it a bit hard to review. I'm not sure I think it is worth the extra
> review time to get those fixed.
>
> Bengt
>
>
> On 3/28/13 7:50 PM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> A new version of the evacuation failed event for G1. Now, each thread sends an
>> event with the info it has collected during the collection in the same way as
>> the other collectors do with promotion failed events.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>
>> Thanks,
>> /Jesper
>


From tao.mao at oracle.com  Mon Apr  8 05:22:44 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Sun, 07 Apr 2013 22:22:44 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
Message-ID: <51625424.4050209@oracle.com>

6761744 Hotspot crashes if process size limit is exceeded
https://jbs.oracle.com/bugs/browse/JDK-6761744

webrev:
http://cr.openjdk.java.net/~tamao/6761744/webrev.00/

changeset:
The fix only needs to go to hsx24 since there's no perm gen in 
hotspot-25. Thus, the webrev is based on hsx24 repo.

It provides for 32-bit builds a preventive check of the size of "the 
object heap + perm gen" before reserving VM memory. The total size 
should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the 
total doesn't make sense and, what's worse, overflow occurs. It will 
consequentially trigger anther error of memory access violation, which 
was not protected.

jtreg testing java code is also written, checking both 32-bit and 
(trivially) 64-bit builds.

testing:
check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
-XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and builds 
of 32-bit and 64-bit. All passed.

Needs JPRT test when pushing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130407/ecf627e7/attachment.htm>

From bengt.rutisson at oracle.com  Mon Apr  8 08:33:21 2013
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Mon, 08 Apr 2013 08:33:21 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 7197666: java -d64 -version core dumps in
	a box with lots of memory
Message-ID: <20130408083326.0A22348136@hg.openjdk.java.net>

Changeset: 83f27710f5f7
Author:    brutisso
Date:      2013-04-08 07:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/83f27710f5f7

7197666: java -d64 -version core dumps in a box with lots of memory
Summary: Allow task queues to be mmapped instead of malloced on Solaris
Reviewed-by: coleenp, jmasa, johnc, tschatzl

! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.hpp



From bengt.rutisson at oracle.com  Mon Apr  8 12:35:31 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 08 Apr 2013 14:35:31 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <51611811.2010403@oracle.com>
References: <51549110.2010208@oracle.com> <5154B427.2060503@oracle.com>
	<51611811.2010403@oracle.com>
Message-ID: <5162B993.3010008@oracle.com>


Hi Jesper,

I'm a bit worried about 
G1ParScanThreadState::setup_evacuation_failed_info().

First, you will never enter the first case "if 
(_g1h->_evacuation_failed_info_array[queue_num] == NULL)" since you have 
set up _evacuation_failed_info_array completely in the G1CollectedHeap 
constructor.

The rest of the method tries to handle the fact that a worker thread 
does not always have the same worker_id (or queue_num). But to handle 
this with an O(N2) search does not seem to scale. If we should have this 
logic we need to find a better data structure for the thread->worker_id 
mapping, such as a hash table.

Having said that I am not convinced that this is a problem worth 
solving. What I mean is, does it really matter to the user which thread 
actually got the evacuation failure or is it enough that we report all 
occurrences of evacuation failures that threads had? Rather than having 
a complex mapping from thread->worker_id, I think I would prefer to 
either just use the first thread that got a failure or to skip the 
thread information all together and just have a worker_id in the event.

This way you probably don't have to propagate EvacuationFailedInfo 
through the _par_scan_state at all. 
G1CollectedHeap::handle_evacuation_failure_par() can look up the 
EvacuationFailedInfo directly from the 
G1CollectedHeap::_evacuation_failed_info_array using the _worker_id.

If it is really important to have the correct thread information in 
there I would prefer to do what I suggested earlier; possibly send 
several events per thread by doing what your last webrev did: send the 
event in the G1ParScanThreadState destructor. But add information about 
when this evacuation failure happened. This way you get the thread right 
and you give the user some information to work with.


Some minor comments:

G1CollectedHeap::G1CollectedHeap()

If _evacuation_failed_info_array was a EvacuationFailedInfo* rather than 
a EvacuationFailedInfo** and you initialize it as:

_evacuation_failed_info_array = NEW_C_HEAP_ARRAY(EvacuationFailedInfo, 
ParallelGCThreads + 1, mtGC);

you probably don't need the rest of the initialization code on lines 
1971-1976.



G1CollectedHeap::do_collection_pause_at_safepoint()

why do we need this line?

3813 
_evacuation_failed_info_array[ParallelGCThreads]->bind_to_thread(Thread::current()->osthread());



gcTrace.hpp: report_evacuation_failed(const EvacuationFailedInfo& cf_info);

can G1CollectedHeap::_evacuation_failed_info_array be private rather 
than protected?

can G1ParScanThreadState::_evacuation_failed_info be private rather than 
protected?


Finally, just a thought, do we need to somehow guard the setup of 
_evacuation_failed_info_array with whether or not the event is enabled? 
On a large machine it can become a fairly large data structure. Not 
really sure what is reasonable to do here.

Thanks,
Bengt


On 4/7/13 8:54 AM, Jesper Wilhelmsson wrote:
> Bengt, all,
>
> A new webrev is now available:
>
> http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/
>
> The main difference is that now we have an array in G1CollectedHeap 
> that keeps track the EvacuationFailedInfo-objects between the 
> different parallel parts of G1 so that each thread only sends a single 
> EvacuationFailed event in the end.
>
> To achieve this some logic was added to find the correct info object 
> in the array since the threads does not have the same queue number 
> each time.
>
> Thanks,
> /Jesper
>
>
> Bengt Rutisson skrev 28/3/13 10:20 PM:
>>
>> Jesper,
>>
>> This looks much better!
>>
>> Have you tested it to see that you get a maximum of one event per GC 
>> thread and
>> GC? It looks to me like you risk getting multiple events sent for 
>> each GC thread
>> every GC.
>>
>> You send the events in the G1ParScanThreadState destructor. I am not 
>> that
>> familiar with G1ParScanThreadState but it looks to me like we create new
>> G1ParScanThreadState instances for the different phases of a GC. Here 
>> are the
>> places where we create new instances of G1ParScanThreadState:
>>
>> G1CollectedHeap::process_discovered_references()
>> G1ParPreserveCMReferentsTask::work()
>> G1ParTask::work()
>> G1STWRefProcTaskProxy::work()
>>
>> So, it looks to me like we risk getting 4 events sent per thread and GC.
>>
>>
>> Some minor comments:
>>
>> In G1CollectedHeap::handle_evacuation_failure_par() you pass the 
>> ef_info on to
>> G1CollectedHeap::handle_evacuation_failure_common(). But the ef_info 
>> is now
>> thread local so you don't have to take the lock to use it. One way to 
>> simplify
>> this would be to do "ef_info->register_copy_failure(old->size());" in
>> G1CollectedHeap::handle_evacuation_failure_par() just before "if
>> (_evac_failure_closure != cl)" instead. Then you don't have to pass 
>> it on to
>> handle_evacuation_failure_common().
>>
>> (As a side note, I don't think setting _evacuation_failed to true has 
>> to be
>> protected by the lock either. It is a shared variable but all writes 
>> to it from
>> different threads will be to set it to true, so I think racing on it 
>> is benign.
>> But you have it in the same place as before, which might be good.)
>>
>> In G1ParCopyClosure::copy_to_survivor_space() you are now picking out 
>> two thing
>> from the _par_scan_state and passing them on to
>> G1CollectedHeap::handle_evacuation_failure_par(). Have you considered 
>> passing a
>> reference to _par_scan_state instead and let 
>> handle_evacuation_failure_par()
>> extract the data it needs?
>>
>> If you move the implementation of the destructor of 
>> G1ParScanThreadState in to
>> the cpp file you don't have to add the include for gcTrace.hpp to
>> g1CollectedHeap.hpp.
>>
>> Why did you decide to remove set_evactuation_failed()?
>>
>> Finally, you have several quite unrelated spelling corrections in 
>> this change.
>> This makes it a bit hard to review. I'm not sure I think it is worth 
>> the extra
>> review time to get those fixed.
>>
>> Bengt
>>
>>
>> On 3/28/13 7:50 PM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> A new version of the evacuation failed event for G1. Now, each 
>>> thread sends an
>>> event with the info it has collected during the collection in the 
>>> same way as
>>> the other collectors do with promotion failed events.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>>
>>> Thanks,
>>> /Jesper
>>



From mikael.gerdin at oracle.com  Mon Apr  8 13:49:23 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 08 Apr 2013 15:49:23 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation lock
	-- possible deadlock
Message-ID: <5162CAE3.1020708@oracle.com>

Hi

The problem is that when running the G1 garbage collector a call to 
objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card 
queue buffer to fill up and this will cause G1 to take 
DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.

Adding dependencies to a ClassLoaderData is currently protected by the 
per-metaspace "Metaspace allocation lock"/5 (which protects more than 
just allocations).

Because I want to avoid messing around with the lock ordering I suggest 
that we use an ObjectLocker on the _dependencies oop in ClassLoaderData.
_dependencies is a 2-element objArrayOop, in effect it's an ad-hoc 
linked list of ClassLoaders/Classes which must be kept alive by this CLD.

Using an ObjectLocker on the head element of the linked list should be 
at least as good as using the metaspace_lock(). There should not be any 
new deadlock issues with VM mutexes since any application thread could 
use a similar synchronized linked list construct.

As a bonus I suggest that we factor out the dependency handling from 
ClassLoaderData into a inner class: ClassLoaderData::Dependencies and 
let Dependencies manage the head of the linked list by itself. This 
should make it more clear that the dependency list is not guarded by the 
metaspace lock anymore.

Buglinks:
https://jbs.oracle.com/bugs/browse/JDK-8010196
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196

Testing:
default jprt run
jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the 
issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)

Webrevs:
Incremental:
http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
Everything:
http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev

Thanks
/Mikael


From leonid.mesnik at oracle.com  Mon Apr  8 14:19:48 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Mon, 08 Apr 2013 18:19:48 +0400
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5162CAE3.1020708@oracle.com>
References: <5162CAE3.1020708@oracle.com>
Message-ID: <5162D204.20904@oracle.com>

Mikael

Is it possible to include regression test which reproduce problem? 
(based on BigArityTest.java)

Leonid

On 04/08/2013 05:49 PM, Mikael Gerdin wrote:
> Hi
>
> The problem is that when running the G1 garbage collector a call to 
> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card 
> queue buffer to fill up and this will cause G1 to take 
> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>
> Adding dependencies to a ClassLoaderData is currently protected by the 
> per-metaspace "Metaspace allocation lock"/5 (which protects more than 
> just allocations).
>
> Because I want to avoid messing around with the lock ordering I 
> suggest that we use an ObjectLocker on the _dependencies oop in 
> ClassLoaderData.
> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc 
> linked list of ClassLoaders/Classes which must be kept alive by this CLD.
>
> Using an ObjectLocker on the head element of the linked list should be 
> at least as good as using the metaspace_lock(). There should not be 
> any new deadlock issues with VM mutexes since any application thread 
> could use a similar synchronized linked list construct.
>
> As a bonus I suggest that we factor out the dependency handling from 
> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and 
> let Dependencies manage the head of the linked list by itself. This 
> should make it more clear that the dependency list is not guarded by 
> the metaspace lock anymore.
>
> Buglinks:
> https://jbs.oracle.com/bugs/browse/JDK-8010196
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>
> Testing:
> default jprt run
> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the 
> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>
> Webrevs:
> Incremental:
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
> Everything:
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>
> Thanks
> /Mikael


-- 
Leonid Mesnik
JVM SQE



From leonid.mesnik at oracle.com  Mon Apr  8 14:23:10 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Mon, 08 Apr 2013 18:23:10 +0400
Subject: RFR: 8009808 TEST-BUG : test case is using bash style tests.
	Default shell for jtreg is bourne. thus failure
In-Reply-To: <515D6AC0.7030502@oracle.com>
References: <5149A89B.9020001@oracle.com> <514C0312.6000203@oracle.com>
	<5151A2E3.60507@oracle.com> <51556105.2040900@oracle.com>
	<515AAB8A.4060109@oracle.com> <515D571F.8070002@oracle.com>
	<515D6AC0.7030502@oracle.com>
Message-ID: <5162D2CE.5020803@oracle.com>

I still need approval from reviewers for this fix.

Could anyone take a look on it?

Leonid
On 04/04/2013 03:57 PM, Mikael Gerdin wrote:
> Leonid,
>
> On 2013-04-04 12:34, Leonid Mesnik wrote:
>> Mikael
>>
>> Here is updated webrev:
>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.2
>>
>> Streams were redirected, toArray() was updated.
>
> Looks good to me.
>
> /Mikael
>
>>
>> Leonid
>> On 04/02/2013 01:57 PM, Mikael Gerdin wrote:
>>> Leonid,
>>>
>>> On 2013-03-29 10:38, Leonid Mesnik wrote:
>>>> Hi
>>>>
>>>> Here is new version of test. (pass jprt)
>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.1/
>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.1/>
>>>
>>> Overall it looks good. The test is nicely specified and in a
>>> controlled environment.
>>>
>>> Can you please make the test save the stdout/stderr of the launched
>>> process and print it out in case of failure?
>>> If the launch fails with some exit code we won't know its cause. I
>>> suggest something like:
>>> pb.redirectErrorStream(true)
>>> pb.redirectOutput("output.log")
>>>
>>> I also have one small comment in:
>>> args.toArray(externalVMopts)
>>>
>>> Even though it may be correct to pass exernalVMopts to toArray(T[]) it
>>> looks a bit confusing.
>>> Can you please change it to either
>>> "toArray(new String[0])" or
>>> "toArray(new String[args.size()])"
>>>
>>> /Mikael
>>>
>>>>
>>>> See my comment inline.
>>>> On 03/26/2013 05:30 PM, Mikael Gerdin wrote:
>>>>> Leonid,
>>>>>
>>>>> On 2013-03-22 08:06, Leonid Mesnik wrote:
>>>>>> Could anyone please review this small test fix.
>>>>>>
>>>>>> Leonid
>>>>>> On 03/20/2013 04:16 PM, Leonid Mesnik wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Could you please review fix for  8009808 TEST-BUG : test case is
>>>>>>> using
>>>>>>> bash style tests. Default shell for jtreg is bourne. thus failure.
>>>>>>>
>>>>>>> I've completely rewritten test in java without major changes it 
>>>>>>> test
>>>>>>> logic.
>>>>>>> I remove CMS so test could be run when CMS is not supported. Also I
>>>>>>> changed max memory to 128M to reduce memory load and increase 
>>>>>>> number
>>>>>>> of GC log entries.
>>>>>
>>>>> Do you think it would be useful to run this test with different GCs?
>>>>> In that case you can pick up the test.vm.opts and test.java.opts
>>>>> system properties and add them to the java command line you launch.
>>>> I've added test.java.opts properties. They are used during testing to
>>>> set additional GC.
>>>>>
>>>>>>>
>>>>>>> Here is the link:
>>>>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/
>>>>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.0/> 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> Are you sure about this:
>>>>> static final File currentDirectory = new
>>>>> File(System.getProperty("user.dir"));
>>>>>
>>>>> isn't user.dir the home directory? Current directory should be 
>>>>> just "."
>>>>> Something like new File(".").getAbsoluteFile() should give you the
>>>>> current work dir.
>>>> System.getProperty("user.dir") is current directory. However I changed
>>>> it to "." to make it more evident.
>>>>>
>>>>> What is the relation between "numberOfFiles" and "minutesToRun"??
>>>>> How do you know that running for 3 minutes will cause a log rotation?
>>>> I've updated test to invoke fullGC and estimate lower bound of needed
>>>> invocation. Now test check that exactly 3 logs are generated.
>>>>
>>>> Leonid
>>>>>
>>>>> I know that you've just adapted the existing test but it seems 
>>>>> strange
>>>>> to me.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


-- 
Leonid Mesnik
JVM SQE



From mikael.gerdin at oracle.com  Mon Apr  8 16:34:20 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 08 Apr 2013 18:34:20 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5162D204.20904@oracle.com>
References: <5162CAE3.1020708@oracle.com> <5162D204.20904@oracle.com>
Message-ID: <5162F18C.6060602@oracle.com>

Leonid,

On 04/08/2013 04:19 PM, Leonid Mesnik wrote:
> Mikael
>
> Is it possible to include regression test which reproduce problem?
> (based on BigArityTest.java)

I can't say I understand what BigArityTest does that makes it introduce 
cross-CLD dependencies.
I did write a test which does cause dependencies but I failed to make it 
reproduce the problem, even though some of the dependencies were added 
during a G1 concurrent mark cycle.

/Mikael

>
> Leonid
>
> On 04/08/2013 05:49 PM, Mikael Gerdin wrote:
>> Hi
>>
>> The problem is that when running the G1 garbage collector a call to
>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>> queue buffer to fill up and this will cause G1 to take
>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>
>> Adding dependencies to a ClassLoaderData is currently protected by the
>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>> just allocations).
>>
>> Because I want to avoid messing around with the lock ordering I
>> suggest that we use an ObjectLocker on the _dependencies oop in
>> ClassLoaderData.
>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>> linked list of ClassLoaders/Classes which must be kept alive by this CLD.
>>
>> Using an ObjectLocker on the head element of the linked list should be
>> at least as good as using the metaspace_lock(). There should not be
>> any new deadlock issues with VM mutexes since any application thread
>> could use a similar synchronized linked list construct.
>>
>> As a bonus I suggest that we factor out the dependency handling from
>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>> let Dependencies manage the head of the linked list by itself. This
>> should make it more clear that the dependency list is not guarded by
>> the metaspace lock anymore.
>>
>> Buglinks:
>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>
>> Testing:
>> default jprt run
>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>
>> Webrevs:
>> Incremental:
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>> Everything:
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>
>> Thanks
>> /Mikael
>
>



From john.cuthbertson at oracle.com  Mon Apr  8 18:14:43 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 08 Apr 2013 11:14:43 -0700
Subject: RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
In-Reply-To: <50F5E6BE.9040901@oracle.com>
References: <50F5E6BE.9040901@oracle.com>
Message-ID: <51630913.6070506@oracle.com>

Hi Everyone,

I've synched up this webrev up with the latest changes in hotspot-gc and 
made one additional refactoring change that was suggested offline. The 
new webrev is at:

http://cr.openjdk.java.net/~johnc/7176479/webrev.2/

I'd like to use this webrev as the basis of some other refactoring work 
I'd like to do in RSet updating and this will make it easier.

Thanks,

JohnC

On 1/15/2013 3:31 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of people look over the changes for this CR - the 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7176479/webrev.0/
>
> Background:
> The issue here was that we were encoding the card index into the card 
> counts table entries along with the GC number so that we could 
> determine if the count associated with was valid. We had a check to 
> ensure that the maximum card index could be encoded in an int. With 
> such large heap size - the number of cards could not be encoded and so 
> the check failed.
>
> The previous mechanism was an attempt to solve the problem of one 
> thread arriving late to the actual GC work. The thread in question was 
> being held up zeroing the card counts table at the start of the GC. 
> The card counts table is used to determine which cards are being 
> refined frequently. Once a card has been refined frequently enough, 
> further refinements of that card are delayed by placing the card into 
> a fixed size evicting table - the hot card cache. The card would then 
> be refined when it was evicted from the hot card cache or when the 
> cache was drained during the next GC.
>
> To solve the problem of zeroing we added an epoch (GC number) to the 
> entries in the counts table and, eliminate the increase in footprint, 
> we made the counts table into a cache which would expand if needed. 
> This approach had some negatives: we might have to refine two cards 
> during a single refinement operation, hashing the card, and performing 
> CAS operations increasing the overhead of concurrent refinement. Also 
> expanding the counts table during a GC incurred a penalty.
>
> This approach also limited the heap size to just under 1TB - which the 
> systems team ran into.
>
> The new approach effectively undoes the previous mechanism and 
> re-simplifies the card counts table.
>
> Summary of Changes:
> The hot card cache and card counts table have been moved from the 
> concurrent refinement code into their own files.
>
> The hot card cache can now exist independently of whether the counts 
> table exists. In this case refining a card once adds it to the hot 
> card cache, i.e. all cards are treated as 'hot'.
>
> The interface to the hot card cache has been simplified - a simple 
> query and a simple drain routine. This simplifies the calling code in 
> g1RemSet.cpp and results in up to only a single card being refined for 
> every call to "refine_card" instead of possibly two. This should 
> reduce the overhead of concurrent refinement.
>
> The number of cards that the hot card cache can hold before cards 
> start getting evicted is controlled by the flag G1ConcRSLogCacheSize, 
> which is now product flag. The default value is 10 giving a hot card 
> cache that can hold 1K cards.
>
> The card counts table has been greatly simplified. It is a simple 
> array of counts how many times a card has been refined. The space for 
> the table is now allocated from virtual memory instead of C heap. The 
> space for the table is committed when the heap is initially committed 
> and the spans the committed size of the heap. When the committed size 
> of the heap is expanded, the counts table is also expanded to cover 
> the newly expanded heap. If we fail to commit the memory for the 
> counts table, cards that map to the uncommitted space will be treated 
> as cold, i.e. they will be refined immediately. Having a simpler 
> counts table also should reduce the overhead of concurrent refinement 
> (there is no need to hash the card index and there are no CAS 
> operations) Having a simpler interface will allow us to change the 
> underlying data structure to an alternative that's perhaps more sparse 
> in the future.
>
> During an incremental GC we no longer zero the entire counts table. We 
> now zero the cards spanned by a region when the region is freed (i.e. 
> when we free the collection set at the end of a GC and when we free 
> regions at the end of a cleanup).  If a card was "hot" before a GC 
> then we will consider it hot after the GC and the first refinement 
> after the GC will insert the card into the hot card cache. 
> Furthermore, since we don't refine cards in young regions, we only 
> need to clear the counts associated with cards spanned by non-young 
> regions.
>
> During a full GC we still discard the entries in the hot card cache 
> and zero the counts for all the cards in the heap.
>
> Testing:
> GC Test suite with MaxTenuringThreshold=0 (to increase the amount of 
> refinement) and a low IHOP value (to force cleanups).
> SPECjbb2005 with a 1.5TB heap size and 256GB young size, 
> MaxTenuringThreshold=0 and a low IHOP value (1%). The systems team are 
> continuing to test with very large heaps.
>



From john.cuthbertson at oracle.com  Mon Apr  8 18:49:48 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 08 Apr 2013 11:49:48 -0700
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
Message-ID: <5163114C.8070900@oracle.com>

Hi Everyone,

Can I have a couple of reviews of these changes: 
http://cr.openjdk.java.net/~johnc/8011724/webrev.0 ?

Summary:
I've changed RSet scanning to stack allocate instances of the 
HeapRegionRemSet iterator and removed the pre-allocated instances 
(created during heap initialization).

Testing:
GC test suite with MaxTenuringThreshold=0, IHOP=1, and VerifyAfterGC to 
create a lot of old data.; jprt.

Thanks,

JohnC


From john.cuthbertson at oracle.com  Mon Apr  8 18:56:30 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 08 Apr 2013 11:56:30 -0700
Subject: RFR(S): 8010780: G1: Eden occupancy/capacity output wrong after
	a full GC
In-Reply-To: <51536EE1.1010308@oracle.com>
References: <51536EE1.1010308@oracle.com>
Message-ID: <516312DE.9030207@oracle.com>

Hi Everyone,

Thomas Schatzl has reviewed these change (thanks Thomas!) so I'm looking 
for one additional reviewer. Any takers?

Thanks,

JohnC

On 3/27/2013 3:12 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers look review this fix? The webrev can 
> be found at: http://cr.openjdk.java.net/~johnc/8010780/webrev.0/
>
> Summary:
> One of the performance team spotted and error in the G1 logs following 
> a full GC:
>
> 411.322: [G1Ergonomics (Mixed GCs)  (to-space exhausted), 0.4279260 secs]
>   ....
>    [Eden: 0.0B(1840.0M)->0.0B(1840.0M) Survivors: 0.0B->0.0B Heap: 
> 36.0G(36.0G)->36.0G(36.0G)]
>  [Times: user=1.13 sys=0.10, real=0.43 secs]
>
> 411.336: [Full GC (Allocation Failure) 35G->18G(36G), 8.0471890 secs]
>  [Times: user=8.50 sys=0.01, real=8.05 secs]
>
> 433.639: [GC pause (G1 Evacuation Pause) (young) 433.640: 
> [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 
> 26203, predicted base time: 13.50 ms, remaining time: 186.50 ms, 
> target pause time: 200.00 ms]
>  433.640: [G1Ergonomics (CSet Construction) add young regions to CSet, 
> eden: 148 regions, survivors: 0 regions, predicted young region time: 
> 164.22 ms]
>  433.640: [G1Ergonomics (CSet Construction) finish choosing CSet, 
> eden: 148 regions, survivors: 0 regions, old: 0 regions, predicted 
> pause time: 177.72 ms, target pause time: 200.00 ms]
>
>  433.895: [G1Ergonomics (Concurrent Cycles) request concurrent cycle 
> initiation, reason: occupancy higher than threshold, occupancy: 
> 21458059264 bytes, allocation request: 0 bytes, threshold: 17394617520 
> bytes (45.00 %), source: end of GC]
> , 0.2552910 secs]
> ....
>    [Eden: 2368.0M(1840.0M)->0.0B(1632.0M) Survivors: 0.0B->304.0M 
> Heap: 20.7G(36.0G)->20.2G(36.0G)]
>
> The heap transition line for the GC after the full GC was displaying 
> the eden capacity that was calculated by the GC preceding the full GC 
> rather than the eden capacity calculated at the end of the of the full 
> GC. As a result the reported eden occupancy is much larger than the 
> reported capacity.
>
> The main part of the fix is the moving of 
> G1CollectorPolicy::_prev_eden_capacity from 
> G1CollectorPolicy::print_detailed_heap_transition() to 
> G1CollectorPolicy::record_collection_pause_start(). The code that 
> records the heap state before the GC has been refactored into a 
> separate routine and is invoked at the start of both an incremental 
> and full GC.
>
> Additionally I added a more detailed heap transition message to the 
> full GC output:
>
>> 1.989: [Full GC (Allocation Failure) 256M->234M(256M), 2.3966795 secs]
>>    [Eden: 0.0B(12.0M)->0.0B(12.0M) Survivors: 0.0B->0.0B Heap: 
>> 256.0M(256.0M)->234.7M(256.0M)]
>>  [Times: user=3.00 sys=0.00, real=2.40 secs]
>>
>
> for validation purposes.
>
> Testing:
> GCOld with a small heap (128m) and +G1PrintHeapRegions
>
> Thanks,
>
> JohnC
>



From jon.masamitsu at oracle.com  Mon Apr  8 21:42:24 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 08 Apr 2013 14:42:24 -0700
Subject: Request for review (m) - 8008508: CMS does not correctly reduce
	heap size after a Full GC
In-Reply-To: <51510541.5070509@oracle.com>
References: <51245F1E.9000701@oracle.com> <512D4987.9040401@oracle.com>
	<CABzyjymrY2rQoBVyfHUP+bnmdysg6UEvNVFPjPgK8mpLTbxTRg@mail.gmail.com>
	<514149CC.6000003@oracle.com> <51510541.5070509@oracle.com>
Message-ID: <516339C0.5080405@oracle.com>

I've integrated the main change (webrev.02)
to gc_baseline.  Still no review on the refactoring
(webrev02.1) so that will not go back.

Jon

On 03/25/13 19:17, Jon Masamitsu wrote:
> I have reviews for the principle part of the change
> (webrev.02) (thanks JohnCu and Ramki) so will push
> that change.  The second part (webrev02.1) is a
> refactoring to share code.  I don't have any reviews
> for that so will not push it.
>
> Jon
>
>
> On 3/13/2013 8:53 PM, Jon Masamitsu wrote:
>> Ramki,
>>
>> I've replied to your coding comments below.
>>
>> All,
>>
>>  I've update the webrev for all the changes so far.
>>
>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.02/
>>
>> I've also added two helper functions for compute_new_size()
>> so that code could be shared as appropriate.  Just the
>> refactoring changes are in this webrev.
>>
>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.02.1/
>>
>> Thanks.
>>
>> Jon
>>
>> On 3/2/2013 12:42 AM, Srinivas Ramakrishna wrote:
>>> Hi Jon --
>>>
>>> I'll give a couple of code-level comments, but there's a high-level
>>> comment at the end, which
>>> might be worth pondering over.
>>>
>>> On Tue, Feb 26, 2013 at 3:47 PM, Jon 
>>> Masamitsu<jon.masamitsu at oracle.com>  wrote:
>>>> I've updated the webrev for review comments (thanks, JohnCu)
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8008508/webrev.01/
>>>>
>>> concurrent MarkSweepGeneration.cpp:
>>>
>>>   949   // compute expansion delta needed for reaching desired free 
>>> percentage
>>>   950   if (free_percentage < desired_free_percentage) {
>>>   951     size_t desired_capacity = (size_t)(used() / ((double) 1 -
>>> desired_free_percentage));
>>>   952     assert(desired_capacity >= capacity(), "invalid expansion 
>>> size");
>>>   953     size_t expand_bytes = MAX2(desired_capacity - capacity(),
>>> MinHeapDeltaBytes);
>>>
>>>   954     if (expand_bytes > 0) {
>>>
>>> The if test at 954 (in your changed code) will always be true because
>>> MinHeapDeltaBytes > 0
>>> and we are taking the max at line 953.
>>
>> Ok.  MinHeapDeltaBytes is a product flag so it could be set to 0 but 
>> other
>> collectors ignore that possibility so I'll take out the test.
>>
>>
>>> On reading your shrinking code further below at lines 989-994, it
>>> struck me that there's a small
>>> existing bug in the shrink/expand code here. It's probably more of a
>>> factor in the shrink code though
>>> because we can live with more free space than we'd ideally want, but
>>> not less than we ideally want,
>>> and we certainly do not want to chatter around the desired free
>>> percentage (hence the delta).
>>>
>>> Your shrinking arm looks like this:-
>>>
>>>   989   } else {
>>>   990     size_t desired_capacity = (size_t)(used() / ((double) 1 -
>>> desired_free_percentage));
>>>   991     assert(desired_capacity <= capacity(), "invalid expansion 
>>> size");
>>>   992     size_t shrink_bytes = MAX2(capacity() - desired_capacity,
>>> MinHeapDeltaBytes);
>>>   993     shrink_free_list_by(shrink_bytes);
>>>   994   }
>>>
>>> I'd modify it to:-
>>>
>>>   989   } else {
>>>   990     size_t desired_capacity = (size_t)(used() / ((double) 1 -
>>> desired_free_percentage));
>>>   991     assert(desired_capacity <= capacity(), "invalid expansion 
>>> size");
>>>              size_t shrink_bytes = capacity() - desired_capacity;
>>>              // Don't shrink unless the delta is greater than the
>>> minimum shrink we want
>>>   992     if (shrink_bytes >= MinHeapDeltaBytes) {
>>>   993         shrink_free_list_by(shrink_bytes);
>>>              }
>>>   994   }
>>
>> I changed the code as you suggested.  Thanks for catching this.
>>
>>> Note the asymmetry between expansion and shrinking, where we expand by
>>> the min if we feel we are below the desired free, but we don't shrink
>>> even if we are above desired free unless the gap exceeds the min
>>> delta.
>>
>> Seems right.
>>> This seems to be the correct policy.  (Of course none of that is moot
>>> until shrink_free_list_by() starts doing shrinking, but probably best
>>> to fix the policy now, so that it doesn't cause chatter later.
>>>
>>> concurrentMarkSweepGeneration.hpp:
>>>
>>> 1298   virtual void compute_new_size();
>>> 1299   void compute_new_size_free_list();
>>>
>>> I think it would be good to add a 1-line doc comment for each of the
>>> above methods.
>>
>> Added
>>
>>   // Resize the generation after a compacting GC.  The
>>   // generation can be treated as a contiguous space
>>   // after the compaction.
>>   virtual void compute_new_size();
>>   // Resize the generation after a non-compacting
>>   // collection.
>>   void compute_new_size_free_list();
>>
>>
>>> vmStructs.cpp:
>>>
>>> I think you also have to adjust the fields _capacity_at_prologue and
>>> _used_at_prologue into the superclass. I'd also move the decls up to
>>> CardGeneration, since that's how the original code is laid out.
>>
>> Done
>>
>>> Finally, a high level comment. While I see the reason for these
>>> mechanics, I worry a little bit
>>> about the somewhat schizophrenic expansion/shrinkage policy, as it
>>> swings between one policy
>>> used when we are presumably doing well and keeping up with the 
>>> application's
>>> allocation/promotion rates and not running into concurrent mode
>>> failure, but then suddenly switching
>>> to a completely different expansion/shrinking policy when we do a
>>> compaction (presumably because
>>> we had a concurrent mode failure). I'd much rather have divorced the
>>> two, by using a more uniform
>>> policy specifically for CMS, perhaps predicated by whether this was
>>> happening after a
>>> compaction or not, but keeping it separate from the policy that might
>>> be used for stop-world
>>>   kind of collectors (hence TenuredGeneraion).
>>>
>>> I'd appreciate it if you could give some thought to this final high
>>> level comment regarding the
>>> general policy approach taken here. (Also it is somewhat troubling to
>>> push policy so high up
>>> into the class hierarchy, so that every subclass must live with it;
>>> I'd much rather the policy
>>> were separated from the mechanics of what would be done when an
>>> expansion or shrinkage
>>> was needed.)
>>>
>>> -- ramki
>>
>


From jon.masamitsu at oracle.com  Mon Apr  8 22:16:09 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 08 Apr 2013 15:16:09 -0700
Subject: RFR(S): 8010780: G1: Eden occupancy/capacity output wrong after
	a full GC
In-Reply-To: <516312DE.9030207@oracle.com>
References: <51536EE1.1010308@oracle.com> <516312DE.9030207@oracle.com>
Message-ID: <516341A9.8090006@oracle.com>

Changes look good.

Jon

On 04/08/13 11:56, John Cuthbertson wrote:
> Hi Everyone,
>
> Thomas Schatzl has reviewed these change (thanks Thomas!) so I'm 
> looking for one additional reviewer. Any takers?
>
> Thanks,
>
> JohnC
>
> On 3/27/2013 3:12 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers look review this fix? The webrev 
>> can be found at: http://cr.openjdk.java.net/~johnc/8010780/webrev.0/
>>
>> Summary:
>> One of the performance team spotted and error in the G1 logs 
>> following a full GC:
>>
>> 411.322: [G1Ergonomics (Mixed GCs)  (to-space exhausted), 0.4279260 
>> secs]
>>   ....
>>    [Eden: 0.0B(1840.0M)->0.0B(1840.0M) Survivors: 0.0B->0.0B Heap: 
>> 36.0G(36.0G)->36.0G(36.0G)]
>>  [Times: user=1.13 sys=0.10, real=0.43 secs]
>>
>> 411.336: [Full GC (Allocation Failure) 35G->18G(36G), 8.0471890 secs]
>>  [Times: user=8.50 sys=0.01, real=8.05 secs]
>>
>> 433.639: [GC pause (G1 Evacuation Pause) (young) 433.640: 
>> [G1Ergonomics (CSet Construction) start choosing CSet, 
>> _pending_cards: 26203, predicted base time: 13.50 ms, remaining time: 
>> 186.50 ms, target pause time: 200.00 ms]
>>  433.640: [G1Ergonomics (CSet Construction) add young regions to 
>> CSet, eden: 148 regions, survivors: 0 regions, predicted young region 
>> time: 164.22 ms]
>>  433.640: [G1Ergonomics (CSet Construction) finish choosing CSet, 
>> eden: 148 regions, survivors: 0 regions, old: 0 regions, predicted 
>> pause time: 177.72 ms, target pause time: 200.00 ms]
>>
>>  433.895: [G1Ergonomics (Concurrent Cycles) request concurrent cycle 
>> initiation, reason: occupancy higher than threshold, occupancy: 
>> 21458059264 bytes, allocation request: 0 bytes, threshold: 
>> 17394617520 bytes (45.00 %), source: end of GC]
>> , 0.2552910 secs]
>> ....
>>    [Eden: 2368.0M(1840.0M)->0.0B(1632.0M) Survivors: 0.0B->304.0M 
>> Heap: 20.7G(36.0G)->20.2G(36.0G)]
>>
>> The heap transition line for the GC after the full GC was displaying 
>> the eden capacity that was calculated by the GC preceding the full GC 
>> rather than the eden capacity calculated at the end of the of the 
>> full GC. As a result the reported eden occupancy is much larger than 
>> the reported capacity.
>>
>> The main part of the fix is the moving of 
>> G1CollectorPolicy::_prev_eden_capacity from 
>> G1CollectorPolicy::print_detailed_heap_transition() to 
>> G1CollectorPolicy::record_collection_pause_start(). The code that 
>> records the heap state before the GC has been refactored into a 
>> separate routine and is invoked at the start of both an incremental 
>> and full GC.
>>
>> Additionally I added a more detailed heap transition message to the 
>> full GC output:
>>
>>> 1.989: [Full GC (Allocation Failure) 256M->234M(256M), 2.3966795 secs]
>>>    [Eden: 0.0B(12.0M)->0.0B(12.0M) Survivors: 0.0B->0.0B Heap: 
>>> 256.0M(256.0M)->234.7M(256.0M)]
>>>  [Times: user=3.00 sys=0.00, real=2.40 secs]
>>>
>>
>> for validation purposes.
>>
>> Testing:
>> GCOld with a small heap (128m) and +G1PrintHeapRegions
>>
>> Thanks,
>>
>> JohnC
>>
>


From david.holmes at oracle.com  Tue Apr  9 00:17:24 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Apr 2013 10:17:24 +1000
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5162CAE3.1020708@oracle.com>
References: <5162CAE3.1020708@oracle.com>
Message-ID: <51635E14.3020500@oracle.com>

Hi Mikael,

This approach sounds (and looks) reasonable to me, but I'll leav eit to 
others to officially Review.

One concern I did have was whether the initialization of the array could 
fail and what that would mean for how this particular cld was used. That 
led me to the following code which looks suspect to me:

// ClassLoaderData into the java/lang/ClassLoader object as a hidden field
ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData** cld_addr, 
Handle loader, TRAPS) {
   ...
   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);

   if (cld_addr != NULL) {
     // First, Atomically set it
     ClassLoaderData* old = (ClassLoaderData*) Atomic::cmpxchg_ptr(cld, 
cld_addr, NULL);
     if (old != NULL) {
       delete cld;
       // Returns the data.
       return old;
     }
   }

   // We won the race, and therefore the task of adding the data to the 
list of
   // class loader data
   do {
     cld->set_next(next);
     ClassLoaderData* exchanged = 
(ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
     if (exchanged == next) {
       ...
       // Create dependencies after the CLD is added to the list. 
Otherwise,
       // the GC GC will not find the CLD and the _class_loader field will
       // not be updated.
       cld->init_dependencies(CHECK_NULL);
       return cld;
     }
     next = exchanged;
   } while (true);
}

So it explicitly states that we create dependencies after adding to the 
list, but if creating the dependencies fails we return null, but leave 
the new cld in the list. Is that a valid thing to do ??

David
-----

On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
> Hi
>
> The problem is that when running the G1 garbage collector a call to
> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
> queue buffer to fill up and this will cause G1 to take
> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>
> Adding dependencies to a ClassLoaderData is currently protected by the
> per-metaspace "Metaspace allocation lock"/5 (which protects more than
> just allocations).
>
> Because I want to avoid messing around with the lock ordering I suggest
> that we use an ObjectLocker on the _dependencies oop in ClassLoaderData.
> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
> linked list of ClassLoaders/Classes which must be kept alive by this CLD.
>
> Using an ObjectLocker on the head element of the linked list should be
> at least as good as using the metaspace_lock(). There should not be any
> new deadlock issues with VM mutexes since any application thread could
> use a similar synchronized linked list construct.
>
> As a bonus I suggest that we factor out the dependency handling from
> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
> let Dependencies manage the head of the linked list by itself. This
> should make it more clear that the dependency list is not guarded by the
> metaspace lock anymore.
>
> Buglinks:
> https://jbs.oracle.com/bugs/browse/JDK-8010196
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>
> Testing:
> default jprt run
> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>
> Webrevs:
> Incremental:
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
> Everything:
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>
> Thanks
> /Mikael


From john.cuthbertson at oracle.com  Tue Apr  9 00:50:58 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 08 Apr 2013 17:50:58 -0700
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <51611811.2010403@oracle.com>
References: <51549110.2010208@oracle.com> <5154B427.2060503@oracle.com>
	<51611811.2010403@oracle.com>
Message-ID: <516365F2.2000204@oracle.com>

Hi Jesper,

A quick question before going on with the actual review....

Do you need the native thread ID in the event or just the worker IDs?

As you have seen tying something to specific worker native IDs across 
multiple gang tasks is not easy. If you actually need the native thread 
IDs then I'm not sure what the best approach is. The most obvious is to 
have some sequential number in each worker that is fixed for the life of 
that worker (i.e. the life the JVM) and use that value to index into the 
evacuation_failed_info_array. Fortunately, I think we have that - it's 
the WorkerThread::_id field:

>   for (uint worker = 0; worker < total_workers(); worker += 1) {
>     GangWorker* new_worker = allocate_worker(worker);

and:

> GangWorker* WorkGang::allocate_worker(uint which) {
>   GangWorker* new_worker = new GangWorker(this, which);
>   return new_worker;
> }
> GangWorker::GangWorker(AbstractWorkGang* gang, uint id) {
>   _gang = gang;
>   set_id(id);
>   set_name("Gang worker#%d (%s)", id, gang->name());
> }

So instead of associating the entries in the 
evacuation_failed_info_array with worker_id/queue_num, they are 
associated with Thread::current()->as_Worker_thread()->id(). Note if 
ParallelGCThreads=0 then the worker threads are not created but you are 
using ParallelGCThreads as the index for the VM thread - that's OK (but 
is a break with convention). You comment it (and why).

Now on to the actual review:

g1CollectedHeap.hpp:

Line 888:
I think you can make this an array of EvacFailureInfo instances rather 
than pointers. I think it's safer to do this. Once you establish the 
mapping between worker thread and EvacFailureInfo instance - you don't 
want it to change.

Line 930:
The change is unnecessary - but it's OK to leave it.

Line 1817:
Again since the mapping between worker thread and evac failed info 
instance is fixed, there's no need to embed a pointer to the object into 
the PSS but it's OK to leave it but I would initialize in the 
constructor, i.e. have something like the following in the PSS constructor:

// The value of native_id is used to index into the 
evacuation_failed_info array
Thread* me = Thread::current();
uint native_id = 0;
if (me->is_Worker_thread()) {
   native_id = me->as_Worker_thread()->id();
} else {
   assert(me->is_VMThread(), "who else?");
   native_id = ParallelGCThreads;
}
_evac_failed_info = _g1h->evacuation_failed_instance_for(native_id);

Alternatively store the native worker ID as well as queue_num in the PSS 
- you can use that to access the instance.

Line 1863:
This line is unnecessary. You no longer need the routine.

Line 1951:
This line may be unnecessary. You could return the _native_id stored in 
the PSS and fetch the evac_failed_info object for that _native_id from 
the array. I'll leave it up to you.

g1CollectedHeap.cpp

Line 1970 - 1976
I really don't like that you  allocate ParallelGCThreads+1 entries - I 
would prefer to use n_queues but I can see why you need to - if parallel 
reference processing is not enabled. The convention is that if 
ParallelGCThreads==0, n_queues will be 1 and we use queue[0] and 
worker_id 0. I want lots of comments here since you're breaking with 
convention.

Fold the initialization of the evac_failed_info array into one of the 
other loops or fold all three loops into one:

> 1954   for (int i = 0; i < n_queues; i++) {
> 1955     iter_arr[i] = new HeapRegionRemSetIterator();
> 1956   }

> 1962   for (int i = 0; i < n_queues; i++) {
> 1963     RefToScanQueue* q = new RefToScanQueue();
> 1964     q->initialize();
> 1965     _task_queues->register_queue(i, q);
> 1966   }
> 1971   for (uint n = 0; n < ParallelGCThreads; n++) {
> 1972     _evacuation_failed_info_array[n] = NULL;
> 1973   }

I think you also want to allocate/reset/initialize the evac_failure_info 
objects. You could also bind to the worker thread:

if (G1CollectedHeap::use_parallel_gc_threads()) {
   assert(workers()->total_workers == n_queues(), "check this code 
otherwise");
   for (uint k = 0; k < workers()->total_workers()l k += 1) {
     GangWorker *worker = workers()->gang_worker(k);
     uint id = worker->id();
     _evac_failed_info[id].bind_to_thread(worker);
   }
}

// The following is unconditional.
  _evac_failed_info[ParallelGCThreads].bind_to_thread(VMThread::vm_thread());

But binding as the first thing in G1ParTask::work() would be OK too.

Line 3813:
You don't need  to do this here. It can be done in G1ParTask::work() or 
during initialization. Again lot's of comments about why the 
evac_failure_info instance for the VMThread is not encoded at index 0.

4051-4056:
Use the use_parallel_gc_threads idiom:

if (G1CollectedHeap::use_parallel_gc_threads()) {
   // Since there are multiple parallel tasks where an evacuation 
failure could occur
   // and (in the future) each task may have been executed by a 
different number of workers,
   // we need to check them all.
   for (uint i = 0; i < workers()->total_workers(); i += 1) {
     ....
   }
}
// Now check the VM thread as it could have seen an evacuation failure 
during serial
// reference processing
...

Line 4480:
This line may not be necessary.

Lines 4507-4533:
Routine may not be necessary. The loop in particular:

> 4521     while (_evacuation_failed_info == NULL) {
> 4522       EvacuationFailedInfo* current = _g1h->_evacuation_failed_info_array[n];
> 4523       assert(current != NULL, "All info objects should have been allocated already");
> 4524       if (current->thread() == Thread::current()->osthread()) {
> 4525         _evacuation_failed_info = current;
> 4526       } else {
> 4527         n++;
> 4528         assert(n <= ParallelGCThreads, "There shouldn't be more threads than ParallelGThreads + the main GC thread");
> 4529       }
> 4530     }

is a big concern.This is an O(n) lookup for each of n threads, for each 
of the distinct parallel tasks (3).

The other files look OK.

JohnC

On 4/6/2013 11:54 PM, Jesper Wilhelmsson wrote:
> Bengt, all,
>
> A new webrev is now available:
>
> http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/
>
> The main difference is that now we have an array in G1CollectedHeap 
> that keeps track the EvacuationFailedInfo-objects between the 
> different parallel parts of G1 so that each thread only sends a single 
> EvacuationFailed event in the end.
>
> To achieve this some logic was added to find the correct info object 
> in the array since the threads does not have the same queue number 
> each time.
>
> Thanks,
> /Jesper
>
>
> Bengt Rutisson skrev 28/3/13 10:20 PM:
>>
>> Jesper,
>>
>> This looks much better!
>>
>> Have you tested it to see that you get a maximum of one event per GC 
>> thread and
>> GC? It looks to me like you risk getting multiple events sent for 
>> each GC thread
>> every GC.
>>
>> You send the events in the G1ParScanThreadState destructor. I am not 
>> that
>> familiar with G1ParScanThreadState but it looks to me like we create new
>> G1ParScanThreadState instances for the different phases of a GC. Here 
>> are the
>> places where we create new instances of G1ParScanThreadState:
>>
>> G1CollectedHeap::process_discovered_references()
>> G1ParPreserveCMReferentsTask::work()
>> G1ParTask::work()
>> G1STWRefProcTaskProxy::work()
>>
>> So, it looks to me like we risk getting 4 events sent per thread and GC.
>>
>>
>> Some minor comments:
>>
>> In G1CollectedHeap::handle_evacuation_failure_par() you pass the 
>> ef_info on to
>> G1CollectedHeap::handle_evacuation_failure_common(). But the ef_info 
>> is now
>> thread local so you don't have to take the lock to use it. One way to 
>> simplify
>> this would be to do "ef_info->register_copy_failure(old->size());" in
>> G1CollectedHeap::handle_evacuation_failure_par() just before "if
>> (_evac_failure_closure != cl)" instead. Then you don't have to pass 
>> it on to
>> handle_evacuation_failure_common().
>>
>> (As a side note, I don't think setting _evacuation_failed to true has 
>> to be
>> protected by the lock either. It is a shared variable but all writes 
>> to it from
>> different threads will be to set it to true, so I think racing on it 
>> is benign.
>> But you have it in the same place as before, which might be good.)
>>
>> In G1ParCopyClosure::copy_to_survivor_space() you are now picking out 
>> two thing
>> from the _par_scan_state and passing them on to
>> G1CollectedHeap::handle_evacuation_failure_par(). Have you considered 
>> passing a
>> reference to _par_scan_state instead and let 
>> handle_evacuation_failure_par()
>> extract the data it needs?
>>
>> If you move the implementation of the destructor of 
>> G1ParScanThreadState in to
>> the cpp file you don't have to add the include for gcTrace.hpp to
>> g1CollectedHeap.hpp.
>>
>> Why did you decide to remove set_evactuation_failed()?
>>
>> Finally, you have several quite unrelated spelling corrections in 
>> this change.
>> This makes it a bit hard to review. I'm not sure I think it is worth 
>> the extra
>> review time to get those fixed.
>>
>> Bengt
>>
>>
>> On 3/28/13 7:50 PM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> A new version of the evacuation failed event for G1. Now, each 
>>> thread sends an
>>> event with the info it has collected during the collection in the 
>>> same way as
>>> the other collectors do with promotion failed events.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>>
>>> Thanks,
>>> /Jesper
>>



From coleen.phillimore at oracle.com  Tue Apr  9 03:20:00 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Apr 2013 23:20:00 -0400
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <51635E14.3020500@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
Message-ID: <516388E0.8030509@oracle.com>

Mikael,
This looks good including the refactoring.

On 4/8/2013 8:17 PM, David Holmes wrote:
> Hi Mikael,
>
> This approach sounds (and looks) reasonable to me, but I'll leav eit 
> to others to officially Review.
>
> One concern I did have was whether the initialization of the array 
> could fail and what that would mean for how this particular cld was 
> used. That led me to the following code which looks suspect to me:
>
> // ClassLoaderData into the java/lang/ClassLoader object as a hidden 
> field
> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData** cld_addr, 
> Handle loader, TRAPS) {
>   ...
>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>
>   if (cld_addr != NULL) {
>     // First, Atomically set it
>     ClassLoaderData* old = (ClassLoaderData*) Atomic::cmpxchg_ptr(cld, 
> cld_addr, NULL);
>     if (old != NULL) {
>       delete cld;
>       // Returns the data.
>       return old;
>     }
>   }
>
>   // We won the race, and therefore the task of adding the data to the 
> list of
>   // class loader data
>   do {
>     cld->set_next(next);
>     ClassLoaderData* exchanged = 
> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>     if (exchanged == next) {
>       ...
>       // Create dependencies after the CLD is added to the list. 
> Otherwise,
>       // the GC GC will not find the CLD and the _class_loader field will
>       // not be updated.
>       cld->init_dependencies(CHECK_NULL);
>       return cld;
>     }
>     next = exchanged;
>   } while (true);
> }
>
> So it explicitly states that we create dependencies after adding to 
> the list, but if creating the dependencies fails we return null, but 
> leave the new cld in the list. Is that a valid thing to do ??
>

Not really.  If we hit OOM here there isn't a good recovery. We 
shouldn't return NULL in any case.   I will file a bug.  In the 
meantime, Mikael can you change it to CATCH_NULL and fix the comment 
above (remove "the GC" before "GC")?

Coleen




> David
> -----
>
> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>> Hi
>>
>> The problem is that when running the G1 garbage collector a call to
>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>> queue buffer to fill up and this will cause G1 to take
>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>
>> Adding dependencies to a ClassLoaderData is currently protected by the
>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>> just allocations).
>>
>> Because I want to avoid messing around with the lock ordering I suggest
>> that we use an ObjectLocker on the _dependencies oop in ClassLoaderData.
>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>> linked list of ClassLoaders/Classes which must be kept alive by this 
>> CLD.
>>
>> Using an ObjectLocker on the head element of the linked list should be
>> at least as good as using the metaspace_lock(). There should not be any
>> new deadlock issues with VM mutexes since any application thread could
>> use a similar synchronized linked list construct.
>>
>> As a bonus I suggest that we factor out the dependency handling from
>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>> let Dependencies manage the head of the linked list by itself. This
>> should make it more clear that the dependency list is not guarded by the
>> metaspace lock anymore.
>>
>> Buglinks:
>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>
>> Testing:
>> default jprt run
>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>
>> Webrevs:
>> Incremental:
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>> Everything:
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>
>> Thanks
>> /Mikael



From coleen.phillimore at oracle.com  Tue Apr  9 03:58:11 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Apr 2013 23:58:11 -0400
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <516388E0.8030509@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
	<516388E0.8030509@oracle.com>
Message-ID: <516391D3.7070306@oracle.com>


Minor correction below.

On 4/8/2013 11:20 PM, Coleen Phillimore wrote:
> Mikael,
> This looks good including the refactoring.
>
> On 4/8/2013 8:17 PM, David Holmes wrote:
>> Hi Mikael,
>>
>> This approach sounds (and looks) reasonable to me, but I'll leav eit 
>> to others to officially Review.
>>
>> One concern I did have was whether the initialization of the array 
>> could fail and what that would mean for how this particular cld was 
>> used. That led me to the following code which looks suspect to me:
>>
>> // ClassLoaderData into the java/lang/ClassLoader object as a hidden 
>> field
>> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData** 
>> cld_addr, Handle loader, TRAPS) {
>>   ...
>>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>>
>>   if (cld_addr != NULL) {
>>     // First, Atomically set it
>>     ClassLoaderData* old = (ClassLoaderData*) 
>> Atomic::cmpxchg_ptr(cld, cld_addr, NULL);
>>     if (old != NULL) {
>>       delete cld;
>>       // Returns the data.
>>       return old;
>>     }
>>   }
>>
>>   // We won the race, and therefore the task of adding the data to 
>> the list of
>>   // class loader data
>>   do {
>>     cld->set_next(next);
>>     ClassLoaderData* exchanged = 
>> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>>     if (exchanged == next) {
>>       ...
>>       // Create dependencies after the CLD is added to the list. 
>> Otherwise,
>>       // the GC GC will not find the CLD and the _class_loader field 
>> will
>>       // not be updated.
>>       cld->init_dependencies(CHECK_NULL);
>>       return cld;
>>     }
>>     next = exchanged;
>>   } while (true);
>> }
>>
>> So it explicitly states that we create dependencies after adding to 
>> the list, but if creating the dependencies fails we return null, but 
>> leave the new cld in the list. Is that a valid thing to do ??
>>
>
> Not really.  If we hit OOM here there isn't a good recovery. We 
> shouldn't return NULL in any case.   I will file a bug.  In the 
> meantime, Mikael can you change it to CATCH_NULL and fix the comment 
> above (remove "the GC" before "GC")?

David is right, it can return null with the pending exception but should 
be removed from the list and from the class_loader hidden field in this 
case.   This function is dangerous because it has unhandled oops (the 
address passed in).  For now, I think you can leave it Mikael.  It'll 
throw the OOM anyway.

Coleen

>
> Coleen
>
>
>
>
>> David
>> -----
>>
>> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>>> Hi
>>>
>>> The problem is that when running the G1 garbage collector a call to
>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>>> queue buffer to fill up and this will cause G1 to take
>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>
>>> Adding dependencies to a ClassLoaderData is currently protected by the
>>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>>> just allocations).
>>>
>>> Because I want to avoid messing around with the lock ordering I suggest
>>> that we use an ObjectLocker on the _dependencies oop in 
>>> ClassLoaderData.
>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>> linked list of ClassLoaders/Classes which must be kept alive by this 
>>> CLD.
>>>
>>> Using an ObjectLocker on the head element of the linked list should be
>>> at least as good as using the metaspace_lock(). There should not be any
>>> new deadlock issues with VM mutexes since any application thread could
>>> use a similar synchronized linked list construct.
>>>
>>> As a bonus I suggest that we factor out the dependency handling from
>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>>> let Dependencies manage the head of the linked list by itself. This
>>> should make it more clear that the dependency list is not guarded by 
>>> the
>>> metaspace lock anymore.
>>>
>>> Buglinks:
>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>
>>> Testing:
>>> default jprt run
>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>
>>> Webrevs:
>>> Incremental:
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>> Everything:
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>
>>> Thanks
>>> /Mikael
>



From david.holmes at oracle.com  Tue Apr  9 04:13:02 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Apr 2013 14:13:02 +1000
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <516391D3.7070306@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
	<516388E0.8030509@oracle.com> <516391D3.7070306@oracle.com>
Message-ID: <5163954E.7070802@oracle.com>

On 9/04/2013 1:58 PM, Coleen Phillimore wrote:
>
> Minor correction below.
>
> On 4/8/2013 11:20 PM, Coleen Phillimore wrote:
>> Mikael,
>> This looks good including the refactoring.
>>
>> On 4/8/2013 8:17 PM, David Holmes wrote:
>>> Hi Mikael,
>>>
>>> This approach sounds (and looks) reasonable to me, but I'll leav eit
>>> to others to officially Review.
>>>
>>> One concern I did have was whether the initialization of the array
>>> could fail and what that would mean for how this particular cld was
>>> used. That led me to the following code which looks suspect to me:
>>>
>>> // ClassLoaderData into the java/lang/ClassLoader object as a hidden
>>> field
>>> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData**
>>> cld_addr, Handle loader, TRAPS) {
>>>   ...
>>>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>>>
>>>   if (cld_addr != NULL) {
>>>     // First, Atomically set it
>>>     ClassLoaderData* old = (ClassLoaderData*)
>>> Atomic::cmpxchg_ptr(cld, cld_addr, NULL);
>>>     if (old != NULL) {
>>>       delete cld;
>>>       // Returns the data.
>>>       return old;
>>>     }
>>>   }
>>>
>>>   // We won the race, and therefore the task of adding the data to
>>> the list of
>>>   // class loader data
>>>   do {
>>>     cld->set_next(next);
>>>     ClassLoaderData* exchanged =
>>> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>>>     if (exchanged == next) {
>>>       ...
>>>       // Create dependencies after the CLD is added to the list.
>>> Otherwise,
>>>       // the GC GC will not find the CLD and the _class_loader field
>>> will
>>>       // not be updated.
>>>       cld->init_dependencies(CHECK_NULL);
>>>       return cld;
>>>     }
>>>     next = exchanged;
>>>   } while (true);
>>> }
>>>
>>> So it explicitly states that we create dependencies after adding to
>>> the list, but if creating the dependencies fails we return null, but
>>> leave the new cld in the list. Is that a valid thing to do ??
>>>
>>
>> Not really.  If we hit OOM here there isn't a good recovery. We
>> shouldn't return NULL in any case.   I will file a bug.  In the
>> meantime, Mikael can you change it to CATCH_NULL and fix the comment
>> above (remove "the GC" before "GC")?
>
> David is right, it can return null with the pending exception but should
> be removed from the list and from the class_loader hidden field in this
> case.   This function is dangerous because it has unhandled oops (the
> address passed in).  For now, I think you can leave it Mikael.  It'll
> throw the OOM anyway.

So getting back to the original fix my concern is whether after 
init_dependencies fails, can we ever call add_dependency for that cld 
and so attempt to lock on a NULL object?

David

> Coleen
>
>>
>> Coleen
>>
>>
>>
>>
>>> David
>>> -----
>>>
>>> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>>>> Hi
>>>>
>>>> The problem is that when running the G1 garbage collector a call to
>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>>>> queue buffer to fill up and this will cause G1 to take
>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>
>>>> Adding dependencies to a ClassLoaderData is currently protected by the
>>>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>>>> just allocations).
>>>>
>>>> Because I want to avoid messing around with the lock ordering I suggest
>>>> that we use an ObjectLocker on the _dependencies oop in
>>>> ClassLoaderData.
>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>>> CLD.
>>>>
>>>> Using an ObjectLocker on the head element of the linked list should be
>>>> at least as good as using the metaspace_lock(). There should not be any
>>>> new deadlock issues with VM mutexes since any application thread could
>>>> use a similar synchronized linked list construct.
>>>>
>>>> As a bonus I suggest that we factor out the dependency handling from
>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>>>> let Dependencies manage the head of the linked list by itself. This
>>>> should make it more clear that the dependency list is not guarded by
>>>> the
>>>> metaspace lock anymore.
>>>>
>>>> Buglinks:
>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>
>>>> Testing:
>>>> default jprt run
>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>
>>>> Webrevs:
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>> Everything:
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>
>>>> Thanks
>>>> /Mikael
>>
>


From bengt.rutisson at oracle.com  Tue Apr  9 06:05:06 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 09 Apr 2013 08:05:06 +0200
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
In-Reply-To: <5163114C.8070900@oracle.com>
References: <5163114C.8070900@oracle.com>
Message-ID: <5163AF92.5000802@oracle.com>


Hi John,

Thanks for doing this cleanup! It really looks much better!

Changes look good.

One minor request if you feel like it:

Since you anyway updated a comment in the class 
HeapRegionRemSetIterator. Could you also update (or just remove) this 
comment?

   // If true we're iterating over the coarse table; if false the fine
   // table.
   enum IterState {
     Sparse,
     Fine,
     Coarse
   };

Also, have you measured any performance impact of this? I'm not 
suggesting that you should put any extra work into doing that. Just, in 
case you have some numbers, have you seen any improvements? I could 
imagine that there was a fair amount of false sharing going on with the 
old array of iterators, so I'm guess that we might see some perf 
improvements with this change. Just curious.

Thanks,
Bengt

On 4/8/13 8:49 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of reviews of these changes: 
> http://cr.openjdk.java.net/~johnc/8011724/webrev.0 ?
>
> Summary:
> I've changed RSet scanning to stack allocate instances of the 
> HeapRegionRemSet iterator and removed the pre-allocated instances 
> (created during heap initialization).
>
> Testing:
> GC test suite with MaxTenuringThreshold=0, IHOP=1, and VerifyAfterGC 
> to create a lot of old data.; jprt.
>
> Thanks,
>
> JohnC



From mikael.gerdin at oracle.com  Tue Apr  9 08:54:19 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 09 Apr 2013 10:54:19 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5163954E.7070802@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
	<516388E0.8030509@oracle.com> <516391D3.7070306@oracle.com>
	<5163954E.7070802@oracle.com>
Message-ID: <5163D73B.6080209@oracle.com>



On 2013-04-09 06:13, David Holmes wrote:
> On 9/04/2013 1:58 PM, Coleen Phillimore wrote:
>>
>> Minor correction below.
>>
>> On 4/8/2013 11:20 PM, Coleen Phillimore wrote:
>>> Mikael,
>>> This looks good including the refactoring.
>>>
>>> On 4/8/2013 8:17 PM, David Holmes wrote:
>>>> Hi Mikael,
>>>>
>>>> This approach sounds (and looks) reasonable to me, but I'll leav eit
>>>> to others to officially Review.
>>>>
>>>> One concern I did have was whether the initialization of the array
>>>> could fail and what that would mean for how this particular cld was
>>>> used. That led me to the following code which looks suspect to me:
>>>>
>>>> // ClassLoaderData into the java/lang/ClassLoader object as a hidden
>>>> field
>>>> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData**
>>>> cld_addr, Handle loader, TRAPS) {
>>>>   ...
>>>>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>>>>
>>>>   if (cld_addr != NULL) {
>>>>     // First, Atomically set it
>>>>     ClassLoaderData* old = (ClassLoaderData*)
>>>> Atomic::cmpxchg_ptr(cld, cld_addr, NULL);
>>>>     if (old != NULL) {
>>>>       delete cld;
>>>>       // Returns the data.
>>>>       return old;
>>>>     }
>>>>   }
>>>>
>>>>   // We won the race, and therefore the task of adding the data to
>>>> the list of
>>>>   // class loader data
>>>>   do {
>>>>     cld->set_next(next);
>>>>     ClassLoaderData* exchanged =
>>>> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>>>>     if (exchanged == next) {
>>>>       ...
>>>>       // Create dependencies after the CLD is added to the list.
>>>> Otherwise,
>>>>       // the GC GC will not find the CLD and the _class_loader field
>>>> will
>>>>       // not be updated.
>>>>       cld->init_dependencies(CHECK_NULL);
>>>>       return cld;
>>>>     }
>>>>     next = exchanged;
>>>>   } while (true);
>>>> }
>>>>
>>>> So it explicitly states that we create dependencies after adding to
>>>> the list, but if creating the dependencies fails we return null, but
>>>> leave the new cld in the list. Is that a valid thing to do ??
>>>>
>>>
>>> Not really.  If we hit OOM here there isn't a good recovery. We
>>> shouldn't return NULL in any case.   I will file a bug.  In the
>>> meantime, Mikael can you change it to CATCH_NULL and fix the comment
>>> above (remove "the GC" before "GC")?
>>
>> David is right, it can return null with the pending exception but should
>> be removed from the list and from the class_loader hidden field in this
>> case.   This function is dangerous because it has unhandled oops (the
>> address passed in).  For now, I think you can leave it Mikael.  It'll
>> throw the OOM anyway.
>
> So getting back to the original fix my concern is whether after
> init_dependencies fails, can we ever call add_dependency for that cld
> and so attempt to lock on a NULL object?

If _dependencies is NULL when we call record_dependency I have a hard 
time seeing how the current code would avoid crashing.

In fact, it looks pretty likely that we'll crash if we ever fail 
init_dependencies.


If we survive all the way to record_dependency the current version of 
the code looks like it will assert twice in debug builds and then SEGV 
at the call to last->obj_at{_put} in locked_add_dependency.

/Mikael

>
> David
>
>> Coleen
>>
>>>
>>> Coleen
>>>
>>>
>>>
>>>
>>>> David
>>>> -----
>>>>
>>>> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>>>>> Hi
>>>>>
>>>>> The problem is that when running the G1 garbage collector a call to
>>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>>>>> queue buffer to fill up and this will cause G1 to take
>>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>>
>>>>> Adding dependencies to a ClassLoaderData is currently protected by the
>>>>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>>>>> just allocations).
>>>>>
>>>>> Because I want to avoid messing around with the lock ordering I
>>>>> suggest
>>>>> that we use an ObjectLocker on the _dependencies oop in
>>>>> ClassLoaderData.
>>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>>>> CLD.
>>>>>
>>>>> Using an ObjectLocker on the head element of the linked list should be
>>>>> at least as good as using the metaspace_lock(). There should not be
>>>>> any
>>>>> new deadlock issues with VM mutexes since any application thread could
>>>>> use a similar synchronized linked list construct.
>>>>>
>>>>> As a bonus I suggest that we factor out the dependency handling from
>>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>>>>> let Dependencies manage the head of the linked list by itself. This
>>>>> should make it more clear that the dependency list is not guarded by
>>>>> the
>>>>> metaspace lock anymore.
>>>>>
>>>>> Buglinks:
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>>
>>>>> Testing:
>>>>> default jprt run
>>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>>>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>>
>>>>> Webrevs:
>>>>> Incremental:
>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>>> Everything:
>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>>
>>>>> Thanks
>>>>> /Mikael
>>>
>>


From mikael.gerdin at oracle.com  Tue Apr  9 09:44:12 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 09 Apr 2013 11:44:12 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5162F18C.6060602@oracle.com>
References: <5162CAE3.1020708@oracle.com> <5162D204.20904@oracle.com>
	<5162F18C.6060602@oracle.com>
Message-ID: <5163E2EC.8050409@oracle.com>

Good news!
I managed to write a regression test by adding a bit more dependencies 
every iteration:

http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-regtest/webrev/

/Mikael


On 04/08/2013 06:34 PM, Mikael Gerdin wrote:
> Leonid,
>
> On 04/08/2013 04:19 PM, Leonid Mesnik wrote:
>> Mikael
>>
>> Is it possible to include regression test which reproduce problem?
>> (based on BigArityTest.java)
>
> I can't say I understand what BigArityTest does that makes it introduce
> cross-CLD dependencies.
> I did write a test which does cause dependencies but I failed to make it
> reproduce the problem, even though some of the dependencies were added
> during a G1 concurrent mark cycle.
>
> /Mikael
>
>>
>> Leonid
>>
>> On 04/08/2013 05:49 PM, Mikael Gerdin wrote:
>>> Hi
>>>
>>> The problem is that when running the G1 garbage collector a call to
>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>>> queue buffer to fill up and this will cause G1 to take
>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>
>>> Adding dependencies to a ClassLoaderData is currently protected by the
>>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>>> just allocations).
>>>
>>> Because I want to avoid messing around with the lock ordering I
>>> suggest that we use an ObjectLocker on the _dependencies oop in
>>> ClassLoaderData.
>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>> CLD.
>>>
>>> Using an ObjectLocker on the head element of the linked list should be
>>> at least as good as using the metaspace_lock(). There should not be
>>> any new deadlock issues with VM mutexes since any application thread
>>> could use a similar synchronized linked list construct.
>>>
>>> As a bonus I suggest that we factor out the dependency handling from
>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>>> let Dependencies manage the head of the linked list by itself. This
>>> should make it more clear that the dependency list is not guarded by
>>> the metaspace lock anymore.
>>>
>>> Buglinks:
>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>
>>> Testing:
>>> default jprt run
>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>
>>> Webrevs:
>>> Incremental:
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>> Everything:
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>
>>> Thanks
>>> /Mikael
>>
>>
>



From leonid.mesnik at oracle.com  Tue Apr  9 11:18:19 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 09 Apr 2013 15:18:19 +0400
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5163E2EC.8050409@oracle.com>
References: <5162CAE3.1020708@oracle.com> <5162D204.20904@oracle.com>
	<5162F18C.6060602@oracle.com> <5163E2EC.8050409@oracle.com>
Message-ID: <5163F8FB.50403@oracle.com>

Great!

Leonid
On 04/09/2013 01:44 PM, Mikael Gerdin wrote:
> Good news!
> I managed to write a regression test by adding a bit more dependencies 
> every iteration:
>
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-regtest/webrev/
>
> /Mikael
>
>
> On 04/08/2013 06:34 PM, Mikael Gerdin wrote:
>> Leonid,
>>
>> On 04/08/2013 04:19 PM, Leonid Mesnik wrote:
>>> Mikael
>>>
>>> Is it possible to include regression test which reproduce problem?
>>> (based on BigArityTest.java)
>>
>> I can't say I understand what BigArityTest does that makes it introduce
>> cross-CLD dependencies.
>> I did write a test which does cause dependencies but I failed to make it
>> reproduce the problem, even though some of the dependencies were added
>> during a G1 concurrent mark cycle.
>>
>> /Mikael
>>
>>>
>>> Leonid
>>>
>>> On 04/08/2013 05:49 PM, Mikael Gerdin wrote:
>>>> Hi
>>>>
>>>> The problem is that when running the G1 garbage collector a call to
>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>>>> queue buffer to fill up and this will cause G1 to take
>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>
>>>> Adding dependencies to a ClassLoaderData is currently protected by the
>>>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>>>> just allocations).
>>>>
>>>> Because I want to avoid messing around with the lock ordering I
>>>> suggest that we use an ObjectLocker on the _dependencies oop in
>>>> ClassLoaderData.
>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>>> CLD.
>>>>
>>>> Using an ObjectLocker on the head element of the linked list should be
>>>> at least as good as using the metaspace_lock(). There should not be
>>>> any new deadlock issues with VM mutexes since any application thread
>>>> could use a similar synchronized linked list construct.
>>>>
>>>> As a bonus I suggest that we factor out the dependency handling from
>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>>>> let Dependencies manage the head of the linked list by itself. This
>>>> should make it more clear that the dependency list is not guarded by
>>>> the metaspace lock anymore.
>>>>
>>>> Buglinks:
>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>
>>>> Testing:
>>>> default jprt run
>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>
>>>> Webrevs:
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>> Everything:
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>
>>>> Thanks
>>>> /Mikael
>>>
>>>
>>
>


-- 
Leonid Mesnik
JVM SQE



From mikael.gerdin at oracle.com  Tue Apr  9 12:19:41 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 09 Apr 2013 14:19:41 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <042601ce3511$6ec42eb0$4c4c8c10$@tornqvist@oracle.com>
References: <5162CAE3.1020708@oracle.com>
	<5162D204.20904@oracle.com>	<5162F18C.6060602@oracle.com>
	<5163E2EC.8050409@oracle.com>
	<042601ce3511$6ec42eb0$4c4c8c10$@tornqvist@oracle.com>
Message-ID: <5164075D.4070108@oracle.com>

Christian,

On 2013-04-09 13:00, Christian Tornqvist wrote:
> Hi Mikael,
>
> Test looks good apart from two minor issues:
>
> Spelling error:
> 43         throw new RuntimeException("Unalbe to load class file");
>
> Don't use System.exit() in jtreg
> (http://openjdk.java.net/jtreg/faq.html#question2.6):
> 120       System.exit(1);

Thanks for looking at this.
I've fixed the issues you mentioned.
I also took the liberty to fix some of the inconsistent naming and 
correcting the "@bug" tag.

New webrev at:
http://cr.openjdk.java.net/~mgerdin/8010196/webrev.1-regtest/webrev/

/Mikael

>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Mikael
> Gerdin
> Sent: den 9 april 2013 11:44
> To: Leonid Mesnik
> Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
> lock -- possible deadlock
>
> Good news!
> I managed to write a regression test by adding a bit more dependencies every
> iteration:
>
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-regtest/webrev/
>
> /Mikael
>
>
> On 04/08/2013 06:34 PM, Mikael Gerdin wrote:
>> Leonid,
>>
>> On 04/08/2013 04:19 PM, Leonid Mesnik wrote:
>>> Mikael
>>>
>>> Is it possible to include regression test which reproduce problem?
>>> (based on BigArityTest.java)
>>
>> I can't say I understand what BigArityTest does that makes it
>> introduce cross-CLD dependencies.
>> I did write a test which does cause dependencies but I failed to make
>> it reproduce the problem, even though some of the dependencies were
>> added during a G1 concurrent mark cycle.
>>
>> /Mikael
>>
>>>
>>> Leonid
>>>
>>> On 04/08/2013 05:49 PM, Mikael Gerdin wrote:
>>>> Hi
>>>>
>>>> The problem is that when running the G1 garbage collector a call to
>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty
>>>> card queue buffer to fill up and this will cause G1 to take
>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>
>>>> Adding dependencies to a ClassLoaderData is currently protected by
>>>> the per-metaspace "Metaspace allocation lock"/5 (which protects more
>>>> than just allocations).
>>>>
>>>> Because I want to avoid messing around with the lock ordering I
>>>> suggest that we use an ObjectLocker on the _dependencies oop in
>>>> ClassLoaderData.
>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>>> CLD.
>>>>
>>>> Using an ObjectLocker on the head element of the linked list should
>>>> be at least as good as using the metaspace_lock(). There should not
>>>> be any new deadlock issues with VM mutexes since any application
>>>> thread could use a similar synchronized linked list construct.
>>>>
>>>> As a bonus I suggest that we factor out the dependency handling from
>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies
>>>> and let Dependencies manage the head of the linked list by itself.
>>>> This should make it more clear that the dependency list is not
>>>> guarded by the metaspace lock anymore.
>>>>
>>>> Buglinks:
>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>
>>>> Testing:
>>>> default jprt run
>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce
>>>> the issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>
>>>> Webrevs:
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webr
>>>> ev
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>> Everything:
>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>
>>>> Thanks
>>>> /Mikael
>>>
>>>
>>
>
>


From bengt.rutisson at oracle.com  Tue Apr  9 13:16:29 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 09 Apr 2013 15:16:29 +0200
Subject: Fwd: Re: Fwd: Re: RFR: 8009808 TEST-BUG : test case is using bash
	style tests. Default shell for jtreg is bourne. thus failure
In-Reply-To: <51640C29.2090307@oracle.com>
References: <51640C29.2090307@oracle.com>
Message-ID: <516414AD.20501@oracle.com>


Including the correct email list.

Bengt


-------- Original Message --------
Subject: 	Re: Fwd: Re: RFR: 8009808 TEST-BUG : test case is using bash 
style tests. Default shell for jtreg is bourne. thus failure
Date: 	Tue, 09 Apr 2013 14:40:09 +0200
From: 	Bengt Rutisson <bengt.rutisson at oracle.com>
To: 	Mikael Gerdin <mikael.gerdin at oracle.com>
CC: 	hotspot_gc_staff_ww_grp <hotspot_gc_staff_ww_grp at oracle.com>




Leonid,

I think the test looks good.

One minor nit: I think the the @summary comment could maybe be a bit 
different. It says:

@summary test new added flags for gc log rotation

In a while these flags won't be newly added. I think it is enough to say:

@summary test flags for gc log rotation

Thanks,
Bengt


On 4/9/13 1:45 PM, Mikael Gerdin wrote:
> Can one of our Reviewers please look at this, it's a good cleanup of a 
> messy test for gc log rotation.
>
> /m
>
> -------- Original Message --------
> Subject: Re: RFR: 8009808 TEST-BUG : test case is using bash style 
> tests. Default shell for jtreg is bourne. thus failure
> Date: Mon, 08 Apr 2013 18:23:10 +0400
> From: Leonid Mesnik <leonid.mesnik at oracle.com>
> CC: hotspot-gc-dev at openjdk.java.net <hotspot-gc-dev at openjdk.java.net>
>
> I still need approval from reviewers for this fix.
>
> Could anyone take a look on it?
>
> Leonid
> On 04/04/2013 03:57 PM, Mikael Gerdin wrote:
>> Leonid,
>>
>> On 2013-04-04 12:34, Leonid Mesnik wrote:
>>> Mikael
>>>
>>> Here is updated webrev:
>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.2
>>>
>>> Streams were redirected, toArray() was updated.
>>
>> Looks good to me.
>>
>> /Mikael
>>
>>>
>>> Leonid
>>> On 04/02/2013 01:57 PM, Mikael Gerdin wrote:
>>>> Leonid,
>>>>
>>>> On 2013-03-29 10:38, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> Here is new version of test. (pass jprt)
>>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.1/
>>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.1/> 
>>>>>
>>>>
>>>> Overall it looks good. The test is nicely specified and in a
>>>> controlled environment.
>>>>
>>>> Can you please make the test save the stdout/stderr of the launched
>>>> process and print it out in case of failure?
>>>> If the launch fails with some exit code we won't know its cause. I
>>>> suggest something like:
>>>> pb.redirectErrorStream(true)
>>>> pb.redirectOutput("output.log")
>>>>
>>>> I also have one small comment in:
>>>> args.toArray(externalVMopts)
>>>>
>>>> Even though it may be correct to pass exernalVMopts to toArray(T[]) it
>>>> looks a bit confusing.
>>>> Can you please change it to either
>>>> "toArray(new String[0])" or
>>>> "toArray(new String[args.size()])"
>>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> See my comment inline.
>>>>> On 03/26/2013 05:30 PM, Mikael Gerdin wrote:
>>>>>> Leonid,
>>>>>>
>>>>>> On 2013-03-22 08:06, Leonid Mesnik wrote:
>>>>>>> Could anyone please review this small test fix.
>>>>>>>
>>>>>>> Leonid
>>>>>>> On 03/20/2013 04:16 PM, Leonid Mesnik wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Could you please review fix for  8009808 TEST-BUG : test case is
>>>>>>>> using
>>>>>>>> bash style tests. Default shell for jtreg is bourne. thus failure.
>>>>>>>>
>>>>>>>> I've completely rewritten test in java without major changes it
>>>>>>>> test
>>>>>>>> logic.
>>>>>>>> I remove CMS so test could be run when CMS is not supported. 
>>>>>>>> Also I
>>>>>>>> changed max memory to 128M to reduce memory load and increase
>>>>>>>> number
>>>>>>>> of GC log entries.
>>>>>>
>>>>>> Do you think it would be useful to run this test with different GCs?
>>>>>> In that case you can pick up the test.vm.opts and test.java.opts
>>>>>> system properties and add them to the java command line you launch.
>>>>> I've added test.java.opts properties. They are used during testing to
>>>>> set additional GC.
>>>>>>
>>>>>>>>
>>>>>>>> Here is the link:
>>>>>>>> http://cr.openjdk.java.net/~mgerdin/lmesnik/log_rot_test/webrev.0/
>>>>>>>> <http://cr.openjdk.java.net/%7Emgerdin/lmesnik/log_rot_test/webrev.0/> 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> Are you sure about this:
>>>>>> static final File currentDirectory = new
>>>>>> File(System.getProperty("user.dir"));
>>>>>>
>>>>>> isn't user.dir the home directory? Current directory should be
>>>>>> just "."
>>>>>> Something like new File(".").getAbsoluteFile() should give you the
>>>>>> current work dir.
>>>>> System.getProperty("user.dir") is current directory. However I 
>>>>> changed
>>>>> it to "." to make it more evident.
>>>>>>
>>>>>> What is the relation between "numberOfFiles" and "minutesToRun"??
>>>>>> How do you know that running for 3 minutes will cause a log 
>>>>>> rotation?
>>>>> I've updated test to invoke fullGC and estimate lower bound of needed
>>>>> invocation. Now test check that exactly 3 logs are generated.
>>>>>
>>>>> Leonid
>>>>>>
>>>>>> I know that you've just adapted the existing test but it seems
>>>>>> strange
>>>>>> to me.
>>>>>>
>>>>>> /Mikael
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>



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

From coleen.phillimore at oracle.com  Tue Apr  9 14:48:09 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Apr 2013 10:48:09 -0400
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5163D73B.6080209@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
	<516388E0.8030509@oracle.com> <516391D3.7070306@oracle.com>
	<5163954E.7070802@oracle.com> <5163D73B.6080209@oracle.com>
Message-ID: <51642A29.7030400@oracle.com>


On 04/09/2013 04:54 AM, Mikael Gerdin wrote:
>
>
> On 2013-04-09 06:13, David Holmes wrote:
>> On 9/04/2013 1:58 PM, Coleen Phillimore wrote:
>>>
>>> Minor correction below.
>>>
>>> On 4/8/2013 11:20 PM, Coleen Phillimore wrote:
>>>> Mikael,
>>>> This looks good including the refactoring.
>>>>
>>>> On 4/8/2013 8:17 PM, David Holmes wrote:
>>>>> Hi Mikael,
>>>>>
>>>>> This approach sounds (and looks) reasonable to me, but I'll leav eit
>>>>> to others to officially Review.
>>>>>
>>>>> One concern I did have was whether the initialization of the array
>>>>> could fail and what that would mean for how this particular cld was
>>>>> used. That led me to the following code which looks suspect to me:
>>>>>
>>>>> // ClassLoaderData into the java/lang/ClassLoader object as a hidden
>>>>> field
>>>>> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData**
>>>>> cld_addr, Handle loader, TRAPS) {
>>>>>   ...
>>>>>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>>>>>
>>>>>   if (cld_addr != NULL) {
>>>>>     // First, Atomically set it
>>>>>     ClassLoaderData* old = (ClassLoaderData*)
>>>>> Atomic::cmpxchg_ptr(cld, cld_addr, NULL);
>>>>>     if (old != NULL) {
>>>>>       delete cld;
>>>>>       // Returns the data.
>>>>>       return old;
>>>>>     }
>>>>>   }
>>>>>
>>>>>   // We won the race, and therefore the task of adding the data to
>>>>> the list of
>>>>>   // class loader data
>>>>>   do {
>>>>>     cld->set_next(next);
>>>>>     ClassLoaderData* exchanged =
>>>>> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>>>>>     if (exchanged == next) {
>>>>>       ...
>>>>>       // Create dependencies after the CLD is added to the list.
>>>>> Otherwise,
>>>>>       // the GC GC will not find the CLD and the _class_loader field
>>>>> will
>>>>>       // not be updated.
>>>>>       cld->init_dependencies(CHECK_NULL);
>>>>>       return cld;
>>>>>     }
>>>>>     next = exchanged;
>>>>>   } while (true);
>>>>> }
>>>>>
>>>>> So it explicitly states that we create dependencies after adding to
>>>>> the list, but if creating the dependencies fails we return null, but
>>>>> leave the new cld in the list. Is that a valid thing to do ??
>>>>>
>>>>
>>>> Not really.  If we hit OOM here there isn't a good recovery. We
>>>> shouldn't return NULL in any case.   I will file a bug.  In the
>>>> meantime, Mikael can you change it to CATCH_NULL and fix the comment
>>>> above (remove "the GC" before "GC")?
>>>
>>> David is right, it can return null with the pending exception but 
>>> should
>>> be removed from the list and from the class_loader hidden field in this
>>> case.   This function is dangerous because it has unhandled oops (the
>>> address passed in).  For now, I think you can leave it Mikael.  It'll
>>> throw the OOM anyway.
>>
>> So getting back to the original fix my concern is whether after
>> init_dependencies fails, can we ever call add_dependency for that cld
>> and so attempt to lock on a NULL object?
>
> If _dependencies is NULL when we call record_dependency I have a hard 
> time seeing how the current code would avoid crashing.
>
> In fact, it looks pretty likely that we'll crash if we ever fail 
> init_dependencies.

If we fail init_dependencies, we return a NULL CLD to the caller with 
the exception pending.  That'll do a CHECK_NULL() and the OOM will pop 
back out to some caller in Java.   But the CLD will still be attached to 
the class_loader() oop.

It should be removed from the CLD graph and unattached to the class 
loader oop.  Unfortunately the former needs more locking than this CAS 
that we have.

Do you want to fix this for your bug fix or file a new bug?

Coleen

>
>
> If we survive all the way to record_dependency the current version of 
> the code looks like it will assert twice in debug builds and then SEGV 
> at the call to last->obj_at{_put} in locked_add_dependency.
>
> /Mikael
>
>>
>> David
>>
>>> Coleen
>>>
>>>>
>>>> Coleen
>>>>
>>>>
>>>>
>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>>>>>> Hi
>>>>>>
>>>>>> The problem is that when running the G1 garbage collector a call to
>>>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty 
>>>>>> card
>>>>>> queue buffer to fill up and this will cause G1 to take
>>>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>>>
>>>>>> Adding dependencies to a ClassLoaderData is currently protected 
>>>>>> by the
>>>>>> per-metaspace "Metaspace allocation lock"/5 (which protects more 
>>>>>> than
>>>>>> just allocations).
>>>>>>
>>>>>> Because I want to avoid messing around with the lock ordering I
>>>>>> suggest
>>>>>> that we use an ObjectLocker on the _dependencies oop in
>>>>>> ClassLoaderData.
>>>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>>>>> CLD.
>>>>>>
>>>>>> Using an ObjectLocker on the head element of the linked list 
>>>>>> should be
>>>>>> at least as good as using the metaspace_lock(). There should not be
>>>>>> any
>>>>>> new deadlock issues with VM mutexes since any application thread 
>>>>>> could
>>>>>> use a similar synchronized linked list construct.
>>>>>>
>>>>>> As a bonus I suggest that we factor out the dependency handling from
>>>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies 
>>>>>> and
>>>>>> let Dependencies manage the head of the linked list by itself. This
>>>>>> should make it more clear that the dependency list is not guarded by
>>>>>> the
>>>>>> metaspace lock anymore.
>>>>>>
>>>>>> Buglinks:
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>>>
>>>>>> Testing:
>>>>>> default jprt run
>>>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could 
>>>>>> reproduce the
>>>>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>>>
>>>>>> Webrevs:
>>>>>> Incremental:
>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev 
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>>>> Everything:
>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>>>
>>>>>> Thanks
>>>>>> /Mikael
>>>>
>>>



From mikael.gerdin at oracle.com  Tue Apr  9 15:19:46 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 09 Apr 2013 17:19:46 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <51642A29.7030400@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
	<516388E0.8030509@oracle.com> <516391D3.7070306@oracle.com>
	<5163954E.7070802@oracle.com> <5163D73B.6080209@oracle.com>
	<51642A29.7030400@oracle.com>
Message-ID: <51643192.2040606@oracle.com>



On 2013-04-09 16:48, Coleen Phillimore wrote:
>
> On 04/09/2013 04:54 AM, Mikael Gerdin wrote:
>>
>>
>> On 2013-04-09 06:13, David Holmes wrote:
>>> On 9/04/2013 1:58 PM, Coleen Phillimore wrote:
>>>>
>>>> Minor correction below.
>>>>
>>>> On 4/8/2013 11:20 PM, Coleen Phillimore wrote:
>>>>> Mikael,
>>>>> This looks good including the refactoring.
>>>>>
>>>>> On 4/8/2013 8:17 PM, David Holmes wrote:
>>>>>> Hi Mikael,
>>>>>>
>>>>>> This approach sounds (and looks) reasonable to me, but I'll leav eit
>>>>>> to others to officially Review.
>>>>>>
>>>>>> One concern I did have was whether the initialization of the array
>>>>>> could fail and what that would mean for how this particular cld was
>>>>>> used. That led me to the following code which looks suspect to me:
>>>>>>
>>>>>> // ClassLoaderData into the java/lang/ClassLoader object as a hidden
>>>>>> field
>>>>>> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData**
>>>>>> cld_addr, Handle loader, TRAPS) {
>>>>>>   ...
>>>>>>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>>>>>>
>>>>>>   if (cld_addr != NULL) {
>>>>>>     // First, Atomically set it
>>>>>>     ClassLoaderData* old = (ClassLoaderData*)
>>>>>> Atomic::cmpxchg_ptr(cld, cld_addr, NULL);
>>>>>>     if (old != NULL) {
>>>>>>       delete cld;
>>>>>>       // Returns the data.
>>>>>>       return old;
>>>>>>     }
>>>>>>   }
>>>>>>
>>>>>>   // We won the race, and therefore the task of adding the data to
>>>>>> the list of
>>>>>>   // class loader data
>>>>>>   do {
>>>>>>     cld->set_next(next);
>>>>>>     ClassLoaderData* exchanged =
>>>>>> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>>>>>>     if (exchanged == next) {
>>>>>>       ...
>>>>>>       // Create dependencies after the CLD is added to the list.
>>>>>> Otherwise,
>>>>>>       // the GC GC will not find the CLD and the _class_loader field
>>>>>> will
>>>>>>       // not be updated.
>>>>>>       cld->init_dependencies(CHECK_NULL);
>>>>>>       return cld;
>>>>>>     }
>>>>>>     next = exchanged;
>>>>>>   } while (true);
>>>>>> }
>>>>>>
>>>>>> So it explicitly states that we create dependencies after adding to
>>>>>> the list, but if creating the dependencies fails we return null, but
>>>>>> leave the new cld in the list. Is that a valid thing to do ??
>>>>>>
>>>>>
>>>>> Not really.  If we hit OOM here there isn't a good recovery. We
>>>>> shouldn't return NULL in any case.   I will file a bug.  In the
>>>>> meantime, Mikael can you change it to CATCH_NULL and fix the comment
>>>>> above (remove "the GC" before "GC")?
>>>>
>>>> David is right, it can return null with the pending exception but
>>>> should
>>>> be removed from the list and from the class_loader hidden field in this
>>>> case.   This function is dangerous because it has unhandled oops (the
>>>> address passed in).  For now, I think you can leave it Mikael.  It'll
>>>> throw the OOM anyway.
>>>
>>> So getting back to the original fix my concern is whether after
>>> init_dependencies fails, can we ever call add_dependency for that cld
>>> and so attempt to lock on a NULL object?
>>
>> If _dependencies is NULL when we call record_dependency I have a hard
>> time seeing how the current code would avoid crashing.
>>
>> In fact, it looks pretty likely that we'll crash if we ever fail
>> init_dependencies.
>
> If we fail init_dependencies, we return a NULL CLD to the caller with
> the exception pending.  That'll do a CHECK_NULL() and the OOM will pop
> back out to some caller in Java.   But the CLD will still be attached to
> the class_loader() oop.
>
> It should be removed from the CLD graph and unattached to the class
> loader oop.  Unfortunately the former needs more locking than this CAS
> that we have.
>
> Do you want to fix this for your bug fix or file a new bug?

It would be good if we fix this with a new bug.
I'm already doing both a small refactor and a bug fix in the same one :)

/Mikael

>
> Coleen
>
>>
>>
>> If we survive all the way to record_dependency the current version of
>> the code looks like it will assert twice in debug builds and then SEGV
>> at the call to last->obj_at{_put} in locked_add_dependency.
>>
>> /Mikael
>>
>>>
>>> David
>>>
>>>> Coleen
>>>>
>>>>>
>>>>> Coleen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> The problem is that when running the G1 garbage collector a call to
>>>>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty
>>>>>>> card
>>>>>>> queue buffer to fill up and this will cause G1 to take
>>>>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>>>>
>>>>>>> Adding dependencies to a ClassLoaderData is currently protected
>>>>>>> by the
>>>>>>> per-metaspace "Metaspace allocation lock"/5 (which protects more
>>>>>>> than
>>>>>>> just allocations).
>>>>>>>
>>>>>>> Because I want to avoid messing around with the lock ordering I
>>>>>>> suggest
>>>>>>> that we use an ObjectLocker on the _dependencies oop in
>>>>>>> ClassLoaderData.
>>>>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>>>>> linked list of ClassLoaders/Classes which must be kept alive by this
>>>>>>> CLD.
>>>>>>>
>>>>>>> Using an ObjectLocker on the head element of the linked list
>>>>>>> should be
>>>>>>> at least as good as using the metaspace_lock(). There should not be
>>>>>>> any
>>>>>>> new deadlock issues with VM mutexes since any application thread
>>>>>>> could
>>>>>>> use a similar synchronized linked list construct.
>>>>>>>
>>>>>>> As a bonus I suggest that we factor out the dependency handling from
>>>>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies
>>>>>>> and
>>>>>>> let Dependencies manage the head of the linked list by itself. This
>>>>>>> should make it more clear that the dependency list is not guarded by
>>>>>>> the
>>>>>>> metaspace lock anymore.
>>>>>>>
>>>>>>> Buglinks:
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>>>>
>>>>>>> Testing:
>>>>>>> default jprt run
>>>>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could
>>>>>>> reproduce the
>>>>>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>>>>
>>>>>>> Webrevs:
>>>>>>> Incremental:
>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>>>>> Everything:
>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>>>>
>>>>>>> Thanks
>>>>>>> /Mikael
>>>>>
>>>>
>


From thomas.schatzl at oracle.com  Tue Apr  9 16:07:40 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 09 Apr 2013 18:07:40 +0200
Subject: RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
In-Reply-To: <51630913.6070506@oracle.com>
References: <50F5E6BE.9040901@oracle.com> <51630913.6070506@oracle.com>
Message-ID: <1365523660.2665.36.camel@cirrus>

Hi,

On Mon, 2013-04-08 at 11:14 -0700, John Cuthbertson wrote:
> Hi Everyone,
> 
> I've synched up this webrev up with the latest changes in hotspot-gc and 
> made one additional refactoring change that was suggested offline. The 
> new webrev is at:
> 
> http://cr.openjdk.java.net/~johnc/7176479/webrev.2/
> 
> I'd like to use this webrev as the basis of some other refactoring work 
> I'd like to do in RSet updating and this will make it easier.

Could you make the two new globals unsigned (e.g. "uintx")? I do not see
a reason to even indicate the user that they may have negative values. I
saw the bounds check in the initialization code.

Minor: G1CardCounts::add_card_count() returns an int, while it cannot be
< 0. The count table elements are of type jbyte too (but then again it's
all private).

> > The new approach effectively undoes the previous mechanism and 
> > re-simplifies the card counts table.
> >
> > Summary of Changes:
> > The hot card cache and card counts table have been moved from the 
> > concurrent refinement code into their own files.

Good!

> >
> > The hot card cache can now exist independently of whether the counts 
> > table exists. In this case refining a card once adds it to the hot 
> > card cache, i.e. all cards are treated as 'hot'.

G1CardCounts::add_card_count() seems to return zero in this case, i.e.
not hot?

In G1CardCounts::resize() the code checks whether _card_counts == 0
(note that _card_counts is a pointer, so maybe the code should compare
to NULL instead), and in this method the code uses
_committed_max_card_num. Maybe extract this into a predicate
has_count_table() and use it uniformly?
Same in G1CardCounts::clear() and the destructor.

The asserts checking the consistency of _cards_counts,
_committed_max_card_num, and G1ConcRSHotCardLimit can then be moved
there instead of repeating them.

I don't consider checking G1ConcRSHotCardLimit important here because
the vm would not even start up when this is set wrongly.

> > Testing:
> > GC Test suite with MaxTenuringThreshold=0 (to increase the amount of 
> > refinement) and a low IHOP value (to force cleanups).
> > SPECjbb2005 with a 1.5TB heap size and 256GB young size, 
> > MaxTenuringThreshold=0 and a low IHOP value (1%). The systems team are 
> > continuing to test with very large heaps.

Any idea about performance differences or efficiency of the hot card
cache? (Maybe you mentioned that already).

Thomas




From john.cuthbertson at oracle.com  Tue Apr  9 17:13:22 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 09 Apr 2013 10:13:22 -0700
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
In-Reply-To: <5163AF92.5000802@oracle.com>
References: <5163114C.8070900@oracle.com> <5163AF92.5000802@oracle.com>
Message-ID: <51644C32.6000409@oracle.com>

Hi Bengt,

Thanks for looking over the changes. As said - I was adding the 
instrumentation code to the iterator and this looked odd.

On 4/8/2013 11:05 PM, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for doing this cleanup! It really looks much better!

I expect as I look at the root scanning and RSet updating code more 
minor cleanups/refactoring will become apparent.

>
> Changes look good.
>
> One minor request if you feel like it:
>
> Since you anyway updated a comment in the class 
> HeapRegionRemSetIterator. Could you also update (or just remove) this 
> comment?
>
>   // If true we're iterating over the coarse table; if false the fine
>   // table.
>   enum IterState {
>     Sparse,
>     Fine,
>     Coarse
>   };

Sure. No problem. How about:

"Indicates the granularity of table that we're currently iterating over"?

>
> Also, have you measured any performance impact of this? I'm not 
> suggesting that you should put any extra work into doing that. Just, 
> in case you have some numbers, have you seen any improvements? I could 
> imagine that there was a fair amount of false sharing going on with 
> the old array of iterators, so I'm guess that we might see some perf 
> improvements with this change. Just curious.

I only did a cursory (i.e. untuned) measurement using SPECjvm98 (5x 
before and after) and didn't see any meaningful difference. The variance 
between the results was slightly smaller but I wouldn't draw any 
conclusion from that. This was on a system with 4 GC threads.

Thanks again,

JohnC


From john.cuthbertson at oracle.com  Tue Apr  9 17:23:39 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 09 Apr 2013 10:23:39 -0700
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
In-Reply-To: <5163AF92.5000802@oracle.com>
References: <5163114C.8070900@oracle.com> <5163AF92.5000802@oracle.com>
Message-ID: <51644E9B.3090503@oracle.com>

Hi Bengt,

I changed the comment to:

   // Indicates what granularity of table that we're currently iterating 
over.
   // We start iterating over the sparse table, progress to the fine grain
   // table, and then finish with the coarse table.
   // See HeapRegionRemSetIterator::has_next().

JohnC

On 4/8/2013 11:05 PM, Bengt Rutisson wrote:
>
> Hi John,
>
> Thanks for doing this cleanup! It really looks much better!
>
> Changes look good.
>
> One minor request if you feel like it:
>
> Since you anyway updated a comment in the class 
> HeapRegionRemSetIterator. Could you also update (or just remove) this 
> comment?
>
>   // If true we're iterating over the coarse table; if false the fine
>   // table.
>   enum IterState {
>     Sparse,
>     Fine,
>     Coarse
>   };
>
> Also, have you measured any performance impact of this? I'm not 
> suggesting that you should put any extra work into doing that. Just, 
> in case you have some numbers, have you seen any improvements? I could 
> imagine that there was a fair amount of false sharing going on with 
> the old array of iterators, so I'm guess that we might see some perf 
> improvements with this change. Just curious.
>
> Thanks,
> Bengt
>
> On 4/8/13 8:49 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of reviews of these changes: 
>> http://cr.openjdk.java.net/~johnc/8011724/webrev.0 ?
>>
>> Summary:
>> I've changed RSet scanning to stack allocate instances of the 
>> HeapRegionRemSet iterator and removed the pre-allocated instances 
>> (created during heap initialization).
>>
>> Testing:
>> GC test suite with MaxTenuringThreshold=0, IHOP=1, and VerifyAfterGC 
>> to create a lot of old data.; jprt.
>>
>> Thanks,
>>
>> JohnC
>



From john.cuthbertson at oracle.com  Tue Apr  9 17:27:06 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 09 Apr 2013 10:27:06 -0700
Subject: RFR(S): 8010780: G1: Eden occupancy/capacity output wrong after
	a full GC
In-Reply-To: <516341A9.8090006@oracle.com>
References: <51536EE1.1010308@oracle.com> <516312DE.9030207@oracle.com>
	<516341A9.8090006@oracle.com>
Message-ID: <51644F6A.5010603@oracle.com>

Hi Jon,

Thanks for looking over the changes.

JohnC

On 4/8/2013 3:16 PM, Jon Masamitsu wrote:
> Changes look good.
>
> Jon
>
> On 04/08/13 11:56, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Thomas Schatzl has reviewed these change (thanks Thomas!) so I'm 
>> looking for one additional reviewer. Any takers?
>>
>> Thanks,
>>
>> JohnC
>>
>> On 3/27/2013 3:12 PM, John Cuthbertson wrote:
>>> Hi Everyone,
>>>
>>> Can I have a couple of volunteers look review this fix? The webrev 
>>> can be found at: http://cr.openjdk.java.net/~johnc/8010780/webrev.0/
>>>
>>> Summary:
>>> One of the performance team spotted and error in the G1 logs 
>>> following a full GC:
>>>
>>> 411.322: [G1Ergonomics (Mixed GCs)  (to-space exhausted), 0.4279260 
>>> secs]
>>>   ....
>>>    [Eden: 0.0B(1840.0M)->0.0B(1840.0M) Survivors: 0.0B->0.0B Heap: 
>>> 36.0G(36.0G)->36.0G(36.0G)]
>>>  [Times: user=1.13 sys=0.10, real=0.43 secs]
>>>
>>> 411.336: [Full GC (Allocation Failure) 35G->18G(36G), 8.0471890 secs]
>>>  [Times: user=8.50 sys=0.01, real=8.05 secs]
>>>
>>> 433.639: [GC pause (G1 Evacuation Pause) (young) 433.640: 
>>> [G1Ergonomics (CSet Construction) start choosing CSet, 
>>> _pending_cards: 26203, predicted base time: 13.50 ms, remaining 
>>> time: 186.50 ms, target pause time: 200.00 ms]
>>>  433.640: [G1Ergonomics (CSet Construction) add young regions to 
>>> CSet, eden: 148 regions, survivors: 0 regions, predicted young 
>>> region time: 164.22 ms]
>>>  433.640: [G1Ergonomics (CSet Construction) finish choosing CSet, 
>>> eden: 148 regions, survivors: 0 regions, old: 0 regions, predicted 
>>> pause time: 177.72 ms, target pause time: 200.00 ms]
>>>
>>>  433.895: [G1Ergonomics (Concurrent Cycles) request concurrent cycle 
>>> initiation, reason: occupancy higher than threshold, occupancy: 
>>> 21458059264 bytes, allocation request: 0 bytes, threshold: 
>>> 17394617520 bytes (45.00 %), source: end of GC]
>>> , 0.2552910 secs]
>>> ....
>>>    [Eden: 2368.0M(1840.0M)->0.0B(1632.0M) Survivors: 0.0B->304.0M 
>>> Heap: 20.7G(36.0G)->20.2G(36.0G)]
>>>
>>> The heap transition line for the GC after the full GC was displaying 
>>> the eden capacity that was calculated by the GC preceding the full 
>>> GC rather than the eden capacity calculated at the end of the of the 
>>> full GC. As a result the reported eden occupancy is much larger than 
>>> the reported capacity.
>>>
>>> The main part of the fix is the moving of 
>>> G1CollectorPolicy::_prev_eden_capacity from 
>>> G1CollectorPolicy::print_detailed_heap_transition() to 
>>> G1CollectorPolicy::record_collection_pause_start(). The code that 
>>> records the heap state before the GC has been refactored into a 
>>> separate routine and is invoked at the start of both an incremental 
>>> and full GC.
>>>
>>> Additionally I added a more detailed heap transition message to the 
>>> full GC output:
>>>
>>>> 1.989: [Full GC (Allocation Failure) 256M->234M(256M), 2.3966795 secs]
>>>>    [Eden: 0.0B(12.0M)->0.0B(12.0M) Survivors: 0.0B->0.0B Heap: 
>>>> 256.0M(256.0M)->234.7M(256.0M)]
>>>>  [Times: user=3.00 sys=0.00, real=2.40 secs]
>>>>
>>>
>>> for validation purposes.
>>>
>>> Testing:
>>> GCOld with a small heap (128m) and +G1PrintHeapRegions
>>>
>>> Thanks,
>>>
>>> JohnC
>>>
>>



From coleen.phillimore at oracle.com  Tue Apr  9 17:47:08 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 09 Apr 2013 13:47:08 -0400
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <51643192.2040606@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51635E14.3020500@oracle.com>
	<516388E0.8030509@oracle.com> <516391D3.7070306@oracle.com>
	<5163954E.7070802@oracle.com> <5163D73B.6080209@oracle.com>
	<51642A29.7030400@oracle.com> <51643192.2040606@oracle.com>
Message-ID: <5164541C.7050909@oracle.com>


OK.
Coleen

On 04/09/2013 11:19 AM, Mikael Gerdin wrote:
>
>
> On 2013-04-09 16:48, Coleen Phillimore wrote:
>>
>> On 04/09/2013 04:54 AM, Mikael Gerdin wrote:
>>>
>>>
>>> On 2013-04-09 06:13, David Holmes wrote:
>>>> On 9/04/2013 1:58 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Minor correction below.
>>>>>
>>>>> On 4/8/2013 11:20 PM, Coleen Phillimore wrote:
>>>>>> Mikael,
>>>>>> This looks good including the refactoring.
>>>>>>
>>>>>> On 4/8/2013 8:17 PM, David Holmes wrote:
>>>>>>> Hi Mikael,
>>>>>>>
>>>>>>> This approach sounds (and looks) reasonable to me, but I'll leav 
>>>>>>> eit
>>>>>>> to others to officially Review.
>>>>>>>
>>>>>>> One concern I did have was whether the initialization of the array
>>>>>>> could fail and what that would mean for how this particular cld was
>>>>>>> used. That led me to the following code which looks suspect to me:
>>>>>>>
>>>>>>> // ClassLoaderData into the java/lang/ClassLoader object as a 
>>>>>>> hidden
>>>>>>> field
>>>>>>> ClassLoaderData* ClassLoaderDataGraph::add(ClassLoaderData**
>>>>>>> cld_addr, Handle loader, TRAPS) {
>>>>>>>   ...
>>>>>>>   ClassLoaderData* cld = new ClassLoaderData(loader, is_anonymous);
>>>>>>>
>>>>>>>   if (cld_addr != NULL) {
>>>>>>>     // First, Atomically set it
>>>>>>>     ClassLoaderData* old = (ClassLoaderData*)
>>>>>>> Atomic::cmpxchg_ptr(cld, cld_addr, NULL);
>>>>>>>     if (old != NULL) {
>>>>>>>       delete cld;
>>>>>>>       // Returns the data.
>>>>>>>       return old;
>>>>>>>     }
>>>>>>>   }
>>>>>>>
>>>>>>>   // We won the race, and therefore the task of adding the data to
>>>>>>> the list of
>>>>>>>   // class loader data
>>>>>>>   do {
>>>>>>>     cld->set_next(next);
>>>>>>>     ClassLoaderData* exchanged =
>>>>>>> (ClassLoaderData*)Atomic::cmpxchg_ptr(cld, list_head, next);
>>>>>>>     if (exchanged == next) {
>>>>>>>       ...
>>>>>>>       // Create dependencies after the CLD is added to the list.
>>>>>>> Otherwise,
>>>>>>>       // the GC GC will not find the CLD and the _class_loader 
>>>>>>> field
>>>>>>> will
>>>>>>>       // not be updated.
>>>>>>>       cld->init_dependencies(CHECK_NULL);
>>>>>>>       return cld;
>>>>>>>     }
>>>>>>>     next = exchanged;
>>>>>>>   } while (true);
>>>>>>> }
>>>>>>>
>>>>>>> So it explicitly states that we create dependencies after adding to
>>>>>>> the list, but if creating the dependencies fails we return null, 
>>>>>>> but
>>>>>>> leave the new cld in the list. Is that a valid thing to do ??
>>>>>>>
>>>>>>
>>>>>> Not really.  If we hit OOM here there isn't a good recovery. We
>>>>>> shouldn't return NULL in any case.   I will file a bug. In the
>>>>>> meantime, Mikael can you change it to CATCH_NULL and fix the comment
>>>>>> above (remove "the GC" before "GC")?
>>>>>
>>>>> David is right, it can return null with the pending exception but
>>>>> should
>>>>> be removed from the list and from the class_loader hidden field in 
>>>>> this
>>>>> case.   This function is dangerous because it has unhandled oops (the
>>>>> address passed in).  For now, I think you can leave it Mikael.  It'll
>>>>> throw the OOM anyway.
>>>>
>>>> So getting back to the original fix my concern is whether after
>>>> init_dependencies fails, can we ever call add_dependency for that cld
>>>> and so attempt to lock on a NULL object?
>>>
>>> If _dependencies is NULL when we call record_dependency I have a hard
>>> time seeing how the current code would avoid crashing.
>>>
>>> In fact, it looks pretty likely that we'll crash if we ever fail
>>> init_dependencies.
>>
>> If we fail init_dependencies, we return a NULL CLD to the caller with
>> the exception pending.  That'll do a CHECK_NULL() and the OOM will pop
>> back out to some caller in Java.   But the CLD will still be attached to
>> the class_loader() oop.
>>
>> It should be removed from the CLD graph and unattached to the class
>> loader oop.  Unfortunately the former needs more locking than this CAS
>> that we have.
>>
>> Do you want to fix this for your bug fix or file a new bug?
>
> It would be good if we fix this with a new bug.
> I'm already doing both a small refactor and a bug fix in the same one :)
>
> /Mikael
>
>>
>> Coleen
>>
>>>
>>>
>>> If we survive all the way to record_dependency the current version of
>>> the code looks like it will assert twice in debug builds and then SEGV
>>> at the call to last->obj_at{_put} in locked_add_dependency.
>>>
>>> /Mikael
>>>
>>>>
>>>> David
>>>>
>>>>> Coleen
>>>>>
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>> On 8/04/2013 11:49 PM, Mikael Gerdin wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> The problem is that when running the G1 garbage collector a 
>>>>>>>> call to
>>>>>>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty
>>>>>>>> card
>>>>>>>> queue buffer to fill up and this will cause G1 to take
>>>>>>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>>>>>>
>>>>>>>> Adding dependencies to a ClassLoaderData is currently protected
>>>>>>>> by the
>>>>>>>> per-metaspace "Metaspace allocation lock"/5 (which protects more
>>>>>>>> than
>>>>>>>> just allocations).
>>>>>>>>
>>>>>>>> Because I want to avoid messing around with the lock ordering I
>>>>>>>> suggest
>>>>>>>> that we use an ObjectLocker on the _dependencies oop in
>>>>>>>> ClassLoaderData.
>>>>>>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>>>>>>>> linked list of ClassLoaders/Classes which must be kept alive by 
>>>>>>>> this
>>>>>>>> CLD.
>>>>>>>>
>>>>>>>> Using an ObjectLocker on the head element of the linked list
>>>>>>>> should be
>>>>>>>> at least as good as using the metaspace_lock(). There should 
>>>>>>>> not be
>>>>>>>> any
>>>>>>>> new deadlock issues with VM mutexes since any application thread
>>>>>>>> could
>>>>>>>> use a similar synchronized linked list construct.
>>>>>>>>
>>>>>>>> As a bonus I suggest that we factor out the dependency handling 
>>>>>>>> from
>>>>>>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies
>>>>>>>> and
>>>>>>>> let Dependencies manage the head of the linked list by itself. 
>>>>>>>> This
>>>>>>>> should make it more clear that the dependency list is not 
>>>>>>>> guarded by
>>>>>>>> the
>>>>>>>> metaspace lock anymore.
>>>>>>>>
>>>>>>>> Buglinks:
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> default jprt run
>>>>>>>> jdk/test/java/lang/invoke/BigArityTest.java (which could
>>>>>>>> reproduce the
>>>>>>>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>>>>>>
>>>>>>>> Webrevs:
>>>>>>>> Incremental:
>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev 
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>>>>>>> Everything:
>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> /Mikael
>>>>>>
>>>>>
>>



From bengt.rutisson at oracle.com  Tue Apr  9 20:19:23 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 09 Apr 2013 22:19:23 +0200
Subject: RFR (S): 8010916: Add tenuring threshold to young garbage
	collection events
In-Reply-To: <515C649F.4060102@oracle.com>
References: <51594D88.6040905@oracle.com> <515AB3DE.60909@oracle.com>
	<515C649F.4060102@oracle.com>
Message-ID: <516477CB.3050702@oracle.com>


Erik,

Looks good.

Bengt

On 4/3/13 7:19 PM, Erik Helin wrote:
> Hi Jesper,
>
> thanks for the review! I would also like to thank Stefan for taking a 
> look at the code offline.
>
> On 04/02/2013 12:33 PM, Jesper Wilhelmsson wrote:
>> Erik,
>>
>> I'm OK with this change as is but I think it is unfortunate that you
>> chose not to follow the pattern used by the other events where we
>> register a value at some point and then, in the end, report the event. I
>> realize that in this case it would probably result in registering the
>> tenuring threshold and then at the next line reporting the YC event. I'm
>> not sure which is worse. I don't really like that you need to pass the
>> tenuring threshold to report_young_gc_end.
>
> The change has been updated to now saving the value in the young gc 
> tracer and then report it at the end. I would prefer to not have to 
> deal with this extra state, but it has to be this way because the 
> young gc event needs the GC end time, and the end time is only passed 
> to report_gc_end (thanks Stefan for pointing this out).
>
> Please see new webrev at:
> http://cr.openjdk.java.net/~ehelin/8010916/webrev.01/
>
> Thanks,
> Erik
>
>> /Jesper
>>
>>
>> Erik Helin skrev 1/4/13 11:04 AM:
>>> Hi all,
>>>
>>> this change adds the field "tenuringThreshold" to the
>>> "vm/gc/collector/young_garbage_collection" event.
>>>
>>> The code in gcTrace.hpp/cpp have been slightly adjusted to support 
>>> this.
>>> The hierarchy of tracers is:
>>>
>>>      G1NewTracer -> YoungGCTracer -> GCTracer
>>>
>>> where "->" means "inherits from".
>>>
>>> Previously, the method "report_gc_end_impl" was virtual in "GCTracer"
>>> to enable
>>> "YoungGCTracer" to send the young GC event when "report_gc_end" was
>>> called on a
>>> GCTracer, as in the following:
>>>
>>>      void GCTracer::report_gc_end(...) {
>>>        // do other stuff
>>>        report_gc_end_impl(...);
>>>      }
>>>
>>>      void YoungGCTracer::report_gc_end_impl(...) {
>>>        // send young gc event here
>>>      }
>>>
>>> In this change, YoungGCTracer now has a method "report_young_gc_end"
>>> that is
>>> virtual and that G1NewTracer overrides. This means that YoungGCTracer
>>> does not
>>> need to override the method "report_gc_end_impl" from GCTracer. This
>>> also means
>>> that all young collectors now also must call "report_young_gc_end".
>>>
>>> This change was needed, since report_young_gc_end must take the 
>>> tenuring
>>> threshold as a parameter, something that was not possible to do with
>>> "report_gc_end_impl".
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8010916/webrev.00/
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010916
>>>
>>> Testing:
>>> JPRT
>>>
>>> Thanks,
>>> Erik
>



From jesper.wilhelmsson at oracle.com  Tue Apr  9 21:09:36 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 09 Apr 2013 23:09:36 +0200
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
In-Reply-To: <5163114C.8070900@oracle.com>
References: <5163114C.8070900@oracle.com>
Message-ID: <51648390.2000606@oracle.com>

Looks good.
Ship it!
/Jesper

John Cuthbertson skrev 8/4/13 8:49 PM:
> Hi Everyone,
>
> Can I have a couple of reviews of these changes:
> http://cr.openjdk.java.net/~johnc/8011724/webrev.0 ?
>
> Summary:
> I've changed RSet scanning to stack allocate instances of the HeapRegionRemSet
> iterator and removed the pre-allocated instances (created during heap
> initialization).
>
> Testing:
> GC test suite with MaxTenuringThreshold=0, IHOP=1, and VerifyAfterGC to create a
> lot of old data.; jprt.
>
> Thanks,
>
> JohnC


From john.cuthbertson at oracle.com  Tue Apr  9 21:51:44 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 09 Apr 2013 14:51:44 -0700
Subject: RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
In-Reply-To: <1365523660.2665.36.camel@cirrus>
References: <50F5E6BE.9040901@oracle.com> <51630913.6070506@oracle.com>
	<1365523660.2665.36.camel@cirrus>
Message-ID: <51648D70.10404@oracle.com>

Hi Thomas,

Thanks for looking over the changes. Replies inline....

On 4/9/2013 9:07 AM, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2013-04-08 at 11:14 -0700, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> I've synched up this webrev up with the latest changes in hotspot-gc and
>> made one additional refactoring change that was suggested offline. The
>> new webrev is at:
>>
>> http://cr.openjdk.java.net/~johnc/7176479/webrev.2/
>>
>> I'd like to use this webrev as the basis of some other refactoring work
>> I'd like to do in RSet updating and this will make it easier.
> Could you make the two new globals unsigned (e.g. "uintx")? I do not see
> a reason to even indicate the user that they may have negative values. I
> saw the bounds check in the initialization code.

Sure. No problem.


> Minor: G1CardCounts::add_card_count() returns an int, while it cannot be
> < 0. The count table elements are of type jbyte too (but then again it's
> all private).

Again no problem. I've changed the element type to be jubyte, the return 
type of add_card_count() and parameter of is_hot() to uint.

>> The new approach effectively undoes the previous mechanism and
>> re-simplifies the card counts table.
>>
>> Summary of Changes:
>> The hot card cache and card counts table have been moved from the
>> concurrent refinement code into their own files.
> Good!
>
>>> The hot card cache can now exist independently of whether the counts
>>> table exists. In this case refining a card once adds it to the hot
>>> card cache, i.e. all cards are treated as 'hot'.
> G1CardCounts::add_card_count() seems to return zero in this case, i.e.
> not hot?

Fair point. I was thinking of the case when the user specifies 
G1ConcRSHotCardLimit to be zero and so the refined cards will be hot. In 
the case where we fail to allocate or expand the counts table, it will 
be considered cold. I think that's OK.

> In G1CardCounts::resize() the code checks whether _card_counts == 0
> (note that _card_counts is a pointer, so maybe the code should compare
> to NULL instead), and in this method the code uses
> _committed_max_card_num. Maybe extract this into a predicate
> has_count_table() and use it uniformly?

Not sure what you mean in your first sentence. I'm checking against NULL:

   97 void G1CardCounts::resize(size_t heap_capacity) {
   98   // Expand the card counts table to handle a heap with the given capacity.
   99
  100   if (_card_counts == NULL) {
  101     // Don't expand if we failed to reserve the card counts table.
  102     return;
  103   }

There's a slight issue with your suggestion. Most of the time we can use 
_committed_max_card_num > 0 to determine if we have a count table (i.e. 
we actually have committed the memory for the card table). The exception 
is the resize() routine and the destructor. The resize routine is called 
to initially commit the table (after committing the initial heap) and 
then to expand it (after the heap is expanded). In the first case 
_committed_max_card_num will be 0 and we can (and should) only check if 
the table has been reserved. The destructor doesn't need to care about 
whether the table was committed - only that it was reserved.

So uniformity won't be possible. The best I think we can do is have a 
couple of predicate routines:

// Returns true if the card counts table has been reserved.
bool has_reserved_count_table() { return _card_counts != NULL; }
// Returns true if the card counts table has been reserved and committed.
bool has_count_table() { return has_reserved_count_table() && 
_max_card_committed_num > 0; }

and use has_reserved_count_table() in the resize() routine and 
destructor. In the others we use has_count_table(). Make sense?

> Same in G1CardCounts::clear() and the destructor.

OK. See comment above about resize() and the destructor needing to be 
different.

> The asserts checking the consistency of _cards_counts,
> _committed_max_card_num, and G1ConcRSHotCardLimit can then be moved
> there instead of repeating them.

Since has_count_table() would explicitly check that _card_counts is non 
null there would be no need assert that. I'll remove those asserts.

> I don't consider checking G1ConcRSHotCardLimit important here because
> the vm would not even start up when this is set wrongly.

OK. Good point. The asserts pre-date the interval checks in 
arguments.cpp. I'll remove these checks on G1ConRSHotCardLimit.

>
> Any idea about performance differences or efficiency of the hot card
> cache? (Maybe you mentioned that already).

Unfortunately I don't have much. The systems team only functionally 
tested with heaps that were larger than 1T. They didn't do before and 
after tests with heaps less than 1T.

I ran OpenDS just to verify that no threads were late to the party. I 
didn't see any gain or loss but there's such a large variability with 
OpenDS that it was impossible to tell with just a couple of runs. When 
the performance team ran SPECjbb2013 with a small (16Gb) heap, the 
change seemed to be performance neutral for both high bound IR and 
critical IR. This would only make a difference for workloads that mutate 
promoted data frequently and I don't know how much of that goes on in 
JBB2013.

Thanks for the comments. Let me know if the proposal about the 
predicates is sufficient.

JohnC


From jesper.wilhelmsson at oracle.com  Tue Apr  9 23:39:58 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 10 Apr 2013 01:39:58 +0200
Subject: RFR: 8009032 - Implement evacuation info event
In-Reply-To: <515D8864.6070209@oracle.com>
References: <515D8864.6070209@oracle.com>
Message-ID: <5164A6CE.6080104@oracle.com>

Hi,

Got some internal feedback (thanks Bengt!) and here is a new version:

http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/

Thanks,
/Jesper



Jesper Wilhelmsson skrev 4/4/13 4:04 PM:
> Hi,
>
> I'm looking for a couple of reviews for this change.
>
> This is an tracing event with information about G1 evacuation/compaction. It
> contains the number of regions in from-space and to-space, how much data that
> was used before and after, the number of bytes copied during the
> evacuation/compaction, and how many regions that was completely freed during an
> evacuation.
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/
>
>
> The patch also contains a bunch of fixed typos in various comments nearby the
> relevant changes. These may add some noise to the webrev, if you prefer to look
> at the webrev without these changes a separate webrev is available here:
>
> Webrev without typo fixes:
>   http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/
>
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032
>
> Thanks,
> /Jesper


From john.cuthbertson at oracle.com  Wed Apr 10 00:46:43 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 09 Apr 2013 17:46:43 -0700
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
In-Reply-To: <51648390.2000606@oracle.com>
References: <5163114C.8070900@oracle.com> <51648390.2000606@oracle.com>
Message-ID: <5164B673.9010204@oracle.com>

Hi Jesper,

Thanks for looking at the changes.

JohnC

On 4/9/2013 2:09 PM, Jesper Wilhelmsson wrote:
> Looks good.
> Ship it!
> /Jesper
>
> John Cuthbertson skrev 8/4/13 8:49 PM:
>> Hi Everyone,
>>
>> Can I have a couple of reviews of these changes:
>> http://cr.openjdk.java.net/~johnc/8011724/webrev.0 ?
>>
>> Summary:
>> I've changed RSet scanning to stack allocate instances of the 
>> HeapRegionRemSet
>> iterator and removed the pre-allocated instances (created during heap
>> initialization).
>>
>> Testing:
>> GC test suite with MaxTenuringThreshold=0, IHOP=1, and VerifyAfterGC 
>> to create a
>> lot of old data.; jprt.
>>
>> Thanks,
>>
>> JohnC



From mikael.gerdin at oracle.com  Wed Apr 10 01:31:16 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Wed, 10 Apr 2013 01:31:16 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8009808: TEST-BUG : test case is using
	bash style tests. Default shell for jtreg is bourne. thus failure
Message-ID: <20130410013123.BD9154819D@hg.openjdk.java.net>

Changeset: 63f57a8c5283
Author:    mgerdin
Date:      2013-04-09 15:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/63f57a8c5283

8009808: TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure
Summary: Rewrite test to use Java only instead of shell script
Reviewed-by: mgerdin, brutisso
Contributed-by: leonid.mesnik at oracle.com

+ test/gc/6941923/Test6941923.java
- test/gc/6941923/test6941923.sh



From bengt.rutisson at oracle.com  Wed Apr 10 08:16:59 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 10 Apr 2013 10:16:59 +0200
Subject: RFR: 8009032 - Implement evacuation info event
In-Reply-To: <5164A6CE.6080104@oracle.com>
References: <515D8864.6070209@oracle.com> <5164A6CE.6080104@oracle.com>
Message-ID: <51651FFB.6040705@oracle.com>


Hi Jesper,

This is better but I'm a bit confused about the data that we report.

usedAllocRegionsBefore/used_alloc_regions_before
Does not seem to be the correct name. What you report here is the used 
bytes for the one alloc region that we retained from the last GC.

usedCSetAfter/used_collectionset_after
Does not seem to be the correct name. What you report is the used bytes 
for the survivor regions. The old alloc regions are not included.

usedAllocRegionsAfter/used_alloc_regions_after
Does not seem to be the correct name. What you report is the amount of 
bytes that survived the collection. Either because it was copied (to 
alloc regions) or because we got evacuation failure and it was left in 
place. This value also does not include the value that you reported in 
"used_alloc_regions_before". I don't think it should, but the current 
name kind of indicates that.

regionsFreed/regions_freed
Does not seem to be the correct name. What you report is the number of 
regions that had been freed just before the current region. I think the 
name may be correct if you move the call to 
_evacuation_info.register_regions_freed() to after the loop.


Code comments:

g1CollectedHeap.cpp/hpp

I would suggest to not have _evacuation_info as an instance variable in 
G1CollectedHeap and instead have it as a local variable in 
G1CollectedHeap::do_collection_pause_at_safepoint(). That would remove 
the need for EvacuationInfo::reset().


Maybe it's better to inline the call to 
_evacuation_info.register_collectionset_regions() inside to 
g1_policy()->finalize_cset()?

         g1_policy()->finalize_cset(target_pause_time_ms);
_evacuation_info.register_collectionset_regions(g1_policy()->cset_region_length());


gcTrace.hpp

Why did you move G1OldTracer to within "#ifndef SERIALGC" the other 
tracer are not guarded by this unless they have to (as G1NewTracer)?

I think it is better to forward declare the EvacuationInfo class than 
including gc_implementation/g1/evacuationInfo.hpp since you only use 
EvacuationInfo*. (If you decide to keep the include you need to move it 
in under #ifndef SERIALGC.)


evacuationInfo.hpp:
I don't think it needs this include:
#include "gc_implementation/g1/heapRegion.hpp"

Why do you use += for all the setters? For the cases where you do 
accumulate (like in G1CollectedHeap::free_collection_set()) I think it 
would be better to accumulate in a local variable and then just call 
register once with the total.

Bengt


On 4/10/13 1:39 AM, Jesper Wilhelmsson wrote:
> Hi,
>
> Got some internal feedback (thanks Bengt!) and here is a new version:
>
> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>
> Thanks,
> /Jesper
>
>
>
> Jesper Wilhelmsson skrev 4/4/13 4:04 PM:
>> Hi,
>>
>> I'm looking for a couple of reviews for this change.
>>
>> This is an tracing event with information about G1 
>> evacuation/compaction. It
>> contains the number of regions in from-space and to-space, how much 
>> data that
>> was used before and after, the number of bytes copied during the
>> evacuation/compaction, and how many regions that was completely freed 
>> during an
>> evacuation.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/
>>
>>
>> The patch also contains a bunch of fixed typos in various comments 
>> nearby the
>> relevant changes. These may add some noise to the webrev, if you 
>> prefer to look
>> at the webrev without these changes a separate webrev is available here:
>>
>> Webrev without typo fixes:
>> http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/
>>
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032
>>
>> Thanks,
>> /Jesper



From thomas.schatzl at oracle.com  Wed Apr 10 08:37:41 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 10 Apr 2013 10:37:41 +0200
Subject: RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
In-Reply-To: <51648D70.10404@oracle.com>
References: <50F5E6BE.9040901@oracle.com> <51630913.6070506@oracle.com>
	<1365523660.2665.36.camel@cirrus> <51648D70.10404@oracle.com>
Message-ID: <1365583061.3428.19.camel@cirrus>

Hi,

On Tue, 2013-04-09 at 14:51 -0700, John Cuthbertson wrote:
> Hi Thomas,
> 
> Thanks for looking over the changes. Replies inline....
> 
> On 4/9/2013 9:07 AM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Mon, 2013-04-08 at 11:14 -0700, John Cuthbertson wrote:
> >> Hi Everyone,
> >>
> >> I've synched up this webrev up with the latest changes in hotspot-gc and
> >> made one additional refactoring change that was suggested offline. The
> >> new webrev is at:
> >>
> >> http://cr.openjdk.java.net/~johnc/7176479/webrev.2/
> >>
> >> I'd like to use this webrev as the basis of some other refactoring work
> >> I'd like to do in RSet updating and this will make it easier.
> > Could you make the two new globals unsigned (e.g. "uintx")? I do not see
> > a reason to even indicate the user that they may have negative values. I
> > saw the bounds check in the initialization code.
> 
> Sure. No problem.
> 
> > Minor: G1CardCounts::add_card_count() returns an int, while it cannot be
> > < 0. The count table elements are of type jbyte too (but then again it's
> > all private).
> 
> Again no problem. I've changed the element type to be jubyte, the return 
> type of add_card_count() and parameter of is_hot() to uint.

Thanks.

> >>> The hot card cache can now exist independently of whether the counts
> >>> table exists. In this case refining a card once adds it to the hot
> >>> card cache, i.e. all cards are treated as 'hot'.
> > G1CardCounts::add_card_count() seems to return zero in this case, i.e.
> > not hot?
> 
> Fair point. I was thinking of the case when the user specifies 
> G1ConcRSHotCardLimit to be zero and so the refined cards will be hot. In 
> the case where we fail to allocate or expand the counts table, it will 
> be considered cold. I think that's OK.

It's okay, it's only that your description in the email to the mailing
list indicated otherwise to me.
The comment in the code reads "// If we failed to allocate the counts
table, return 0.". Maybe the comment could explicitly indicate that that
means the cards will always be cold in that case.

What does " 145   // If card_ptr is beyond the committed end of the
counts table, return 0." actually mean if card_ptr is beyond the end of
the count table? There was not enough memory?

In resize() the assert at line 132 indicates that this is actually a
failure, which seems somewhat inconsistent in the way this situation is
handled in debug/production mode.

> > In G1CardCounts::resize() the code checks whether _card_counts == 0
> > (note that _card_counts is a pointer, so maybe the code should compare
> > to NULL instead), and in this method the code uses
> > _committed_max_card_num. Maybe extract this into a predicate
> > has_count_table() and use it uniformly?
> 
> Not sure what you mean in your first sentence. I'm checking against NULL:

My oversight. It's fine. Sorry.

> There's a slight issue with your suggestion. Most of the time we can use 
> _committed_max_card_num > 0 to determine if we have a count table (i.e. 
> we actually have committed the memory for the card table). The exception 
> is the resize() routine and the destructor. The resize routine is called 
> to initially commit the table (after committing the initial heap) and 
> then to expand it (after the heap is expanded). In the first case 
> _committed_max_card_num will be 0 and we can (and should) only check if 
> the table has been reserved. The destructor doesn't need to care about 
> whether the table was committed - only that it was reserved.
> 
> So uniformity won't be possible. The best I think we can do is have a 
> couple of predicate routines:
> 
> // Returns true if the card counts table has been reserved.
> bool has_reserved_count_table() { return _card_counts != NULL; }
> // Returns true if the card counts table has been reserved and committed.
> bool has_count_table() { return has_reserved_count_table() && 
> _max_card_committed_num > 0; }
> 
> and use has_reserved_count_table() in the resize() routine and 
> destructor. In the others we use has_count_table(). Make sense?

Yes.

> > Any idea about performance differences or efficiency of the hot card
> > cache? (Maybe you mentioned that already).
> 
> Unfortunately I don't have much. The systems team only functionally 
> tested with heaps that were larger than 1T. They didn't do before and 
> after tests with heaps less than 1T.
> 
> I ran OpenDS just to verify that no threads were late to the party. I 
> didn't see any gain or loss but there's such a large variability with 
> OpenDS that it was impossible to tell with just a couple of runs. When 
> the performance team ran SPECjbb2013 with a small (16Gb) heap, the 
> change seemed to be performance neutral for both high bound IR and 
> critical IR. This would only make a difference for workloads that mutate 
> promoted data frequently and I don't know how much of that goes on in 
> JBB2013.
> 
> Thanks for the comments. Let me know if the proposal about the 
> predicates is sufficient.

They're fine. Thanks.

One further nitpick: the general documentation for the new classes is
within the class. It looks as if that documentation is part of the first
member of the class.

E.g.

class XX {
  // documentation for XX
}

instead of the seemingly more common

// documentation for XX
class XX {
}

Not sure what's the preference here.

Thomas



From bengt.rutisson at oracle.com  Wed Apr 10 08:42:26 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 10 Apr 2013 10:42:26 +0200
Subject: RFR(S): 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
In-Reply-To: <51644C32.6000409@oracle.com>
References: <5163114C.8070900@oracle.com> <5163AF92.5000802@oracle.com>
	<51644C32.6000409@oracle.com>
Message-ID: <516525F2.1080206@oracle.com>


John, looks good!

Bengt

On 4/9/13 7:13 PM, John Cuthbertson wrote:
> Hi Bengt,
>
> Thanks for looking over the changes. As said - I was adding the 
> instrumentation code to the iterator and this looked odd.
>
> On 4/8/2013 11:05 PM, Bengt Rutisson wrote:
>>
>> Hi John,
>>
>> Thanks for doing this cleanup! It really looks much better!
>
> I expect as I look at the root scanning and RSet updating code more 
> minor cleanups/refactoring will become apparent.
>
>>
>> Changes look good.
>>
>> One minor request if you feel like it:
>>
>> Since you anyway updated a comment in the class 
>> HeapRegionRemSetIterator. Could you also update (or just remove) this 
>> comment?
>>
>>   // If true we're iterating over the coarse table; if false the fine
>>   // table.
>>   enum IterState {
>>     Sparse,
>>     Fine,
>>     Coarse
>>   };
>
> Sure. No problem. How about:
>
> "Indicates the granularity of table that we're currently iterating over"?
>
>>
>> Also, have you measured any performance impact of this? I'm not 
>> suggesting that you should put any extra work into doing that. Just, 
>> in case you have some numbers, have you seen any improvements? I 
>> could imagine that there was a fair amount of false sharing going on 
>> with the old array of iterators, so I'm guess that we might see some 
>> perf improvements with this change. Just curious.
>
> I only did a cursory (i.e. untuned) measurement using SPECjvm98 (5x 
> before and after) and didn't see any meaningful difference. The 
> variance between the results was slightly smaller but I wouldn't draw 
> any conclusion from that. This was on a system with 4 GC threads.
>
> Thanks again,
>
> JohnC



From bengt.rutisson at oracle.com  Wed Apr 10 08:54:26 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 10 Apr 2013 10:54:26 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <51625424.4050209@oracle.com>
References: <51625424.4050209@oracle.com>
Message-ID: <516528C2.8080709@oracle.com>


Hi Tao,

This change looks good. Thanks for adding the JTReg test, it looks good!

One minor nit:

In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would suggest 
to store "(size_t) align_size_up(pgs->max_size(), 
HeapRegion::GrainBytes)" in a local variable rather than duplicating the 
calculation.

Thanks,
Bengt

On 4/8/13 7:22 AM, Tao Mao wrote:
> 6761744 Hotspot crashes if process size limit is exceeded
> https://jbs.oracle.com/bugs/browse/JDK-6761744
>
> webrev:
> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>
> changeset:
> The fix only needs to go to hsx24 since there's no perm gen in 
> hotspot-25. Thus, the webrev is based on hsx24 repo.
>
> It provides for 32-bit builds a preventive check of the size of "the 
> object heap + perm gen" before reserving VM memory. The total size 
> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the 
> total doesn't make sense and, what's worse, overflow occurs. It will 
> consequentially trigger anther error of memory access violation, which 
> was not protected.
>
> jtreg testing java code is also written, checking both 32-bit and 
> (trivially) 64-bit builds.
>
> testing:
> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and builds 
> of 32-bit and 64-bit. All passed.
>
> Needs JPRT test when pushing.

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

From stefan.karlsson at oracle.com  Wed Apr 10 11:14:31 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 10 Apr 2013 13:14:31 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <5162CAE3.1020708@oracle.com>
References: <5162CAE3.1020708@oracle.com>
Message-ID: <51654997.6060505@oracle.com>

On 04/08/2013 03:49 PM, Mikael Gerdin wrote:
> Hi
>
> The problem is that when running the G1 garbage collector a call to 
> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card 
> queue buffer to fill up and this will cause G1 to take 
> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>
> Adding dependencies to a ClassLoaderData is currently protected by the 
> per-metaspace "Metaspace allocation lock"/5 (which protects more than 
> just allocations).
>
> Because I want to avoid messing around with the lock ordering I 
> suggest that we use an ObjectLocker on the _dependencies oop in 
> ClassLoaderData.
> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc 
> linked list of ClassLoaders/Classes which must be kept alive by this CLD.
>
> Using an ObjectLocker on the head element of the linked list should be 
> at least as good as using the metaspace_lock(). There should not be 
> any new deadlock issues with VM mutexes since any application thread 
> could use a similar synchronized linked list construct.
>
> As a bonus I suggest that we factor out the dependency handling from 
> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and 
> let Dependencies manage the head of the linked list by itself. This 
> should make it more clear that the dependency list is not guarded by 
> the metaspace lock anymore.
>
> Buglinks:
> https://jbs.oracle.com/bugs/browse/JDK-8010196
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>
> Testing:
> default jprt run
> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the 
> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>
> Webrevs:
> Incremental:
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
> Everything:
> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev

Looks good.

StefanK

>
> Thanks
> /Mikael



From mikael.gerdin at oracle.com  Wed Apr 10 11:22:30 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 10 Apr 2013 13:22:30 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
	lock -- possible deadlock
In-Reply-To: <51654997.6060505@oracle.com>
References: <5162CAE3.1020708@oracle.com> <51654997.6060505@oracle.com>
Message-ID: <51654B76.70300@oracle.com>



On 2013-04-10 13:14, Stefan Karlsson wrote:
> On 04/08/2013 03:49 PM, Mikael Gerdin wrote:
>> Hi
>>
>> The problem is that when running the G1 garbage collector a call to
>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty card
>> queue buffer to fill up and this will cause G1 to take
>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>
>> Adding dependencies to a ClassLoaderData is currently protected by the
>> per-metaspace "Metaspace allocation lock"/5 (which protects more than
>> just allocations).
>>
>> Because I want to avoid messing around with the lock ordering I
>> suggest that we use an ObjectLocker on the _dependencies oop in
>> ClassLoaderData.
>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc
>> linked list of ClassLoaders/Classes which must be kept alive by this CLD.
>>
>> Using an ObjectLocker on the head element of the linked list should be
>> at least as good as using the metaspace_lock(). There should not be
>> any new deadlock issues with VM mutexes since any application thread
>> could use a similar synchronized linked list construct.
>>
>> As a bonus I suggest that we factor out the dependency handling from
>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies and
>> let Dependencies manage the head of the linked list by itself. This
>> should make it more clear that the dependency list is not guarded by
>> the metaspace lock anymore.
>>
>> Buglinks:
>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>
>> Testing:
>> default jprt run
>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce the
>> issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>
>> Webrevs:
>> Incremental:
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webrev
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>> Everything:
>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>
> Looks good.

Thanks Stefan and Coleen for reviewing and David for "not reviewing but 
still looking at the code" :)

Coleen has asked me to look more closely at the error handling in the 
CLD initialization code. I'll do that as a separate CR.

/Mikael

>
> StefanK
>
>>
>> Thanks
>> /Mikael
>


From erik.helin at oracle.com  Wed Apr 10 13:15:10 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 10 Apr 2013 15:15:10 +0200
Subject: RFR (S): 8011699: CMS: assert(_shared_gc_info.id() !=
	SharedGCInfo::UNSET_GCID) failed: GC not started?
Message-ID: <516565DE.6020503@oracle.com>

Hi all,

this change fixes an issue with the reporting of concurrent mode failure 
for the trace framework for CMS.

The problem was that a background collection in CMS (the function 
collect_in_background) updated _collectorState to InitialMark before the 
method report_gc_start was called on the CMS GC tracer. If the 
background GC was aborted before the call to report_gc_start, we would 
then report concurrent mode failure on a GC tracer that is not started 
(an invalid state for a GC tracer).

The fix is to move the call to report_gc_start to the same place in 
collect_in_background as where _collectorState is updated. However, this 
means that the heap_summary_before_gc event must be sent from 
checkpointRootsInitialPre due to lock ordering (Metaspace lock and CGC 
lock). Furthermore, collect_in_foreground must ensure that it does not 
call report_gc_start a second time (in the case when 
collect_in_foreground takes over a background GC).

Webrev:
http://cr.openjdk.java.net/~ehelin/8011699/webrev.00/

Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011699

Thanks,
Erik


From kevin.walls at oracle.com  Wed Apr 10 14:05:30 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 10 Apr 2013 15:05:30 +0100
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is set
	in command-line
Message-ID: <516571AA.60602@oracle.com>

Hi,

I'd like a review of this testcase change.  It fails as it has a GC 
option set in the jtreg tag which may conflict with what jtreg sends, 
and fail to run.

Although the test was created for a CMS problem, double-counting of full 
collections, here it is adapted to check all collectors:

http://cr.openjdk.java.net/~kevinw/7109087/webrev/

Thanks
Kevin


From stefan.karlsson at oracle.com  Wed Apr 10 14:34:10 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 10 Apr 2013 16:34:10 +0200
Subject: RFR (S): 8011699: CMS: assert(_shared_gc_info.id() !=
	SharedGCInfo::UNSET_GCID) failed: GC not started?
In-Reply-To: <516565DE.6020503@oracle.com>
References: <516565DE.6020503@oracle.com>
Message-ID: <51657862.7070003@oracle.com>

On 04/10/2013 03:15 PM, Erik Helin wrote:
> Hi all,
>
> this change fixes an issue with the reporting of concurrent mode 
> failure for the trace framework for CMS.
>
> The problem was that a background collection in CMS (the function 
> collect_in_background) updated _collectorState to InitialMark before 
> the method report_gc_start was called on the CMS GC tracer. If the 
> background GC was aborted before the call to report_gc_start, we would 
> then report concurrent mode failure on a GC tracer that is not started 
> (an invalid state for a GC tracer).
>
> The fix is to move the call to report_gc_start to the same place in 
> collect_in_background as where _collectorState is updated. However, 
> this means that the heap_summary_before_gc event must be sent from 
> checkpointRootsInitialPre due to lock ordering (Metaspace lock and CGC 
> lock). Furthermore, collect_in_foreground must ensure that it does not 
> call report_gc_start a second time (in the case when 
> collect_in_foreground takes over a background GC).
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8011699/webrev.00/

Looks good.

StefanK

>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011699
>
> Thanks,
> Erik



From mikael.gerdin at oracle.com  Wed Apr 10 14:41:12 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 10 Apr 2013 16:41:12 +0200
Subject: RFR (S): 8011699: CMS: assert(_shared_gc_info.id() !=
	SharedGCInfo::UNSET_GCID) failed: GC not started?
In-Reply-To: <516565DE.6020503@oracle.com>
References: <516565DE.6020503@oracle.com>
Message-ID: <51657A08.8040907@oracle.com>

Erik,

On 2013-04-10 15:15, Erik Helin wrote:
> Hi all,
>
> this change fixes an issue with the reporting of concurrent mode failure
> for the trace framework for CMS.
>
> The problem was that a background collection in CMS (the function
> collect_in_background) updated _collectorState to InitialMark before the
> method report_gc_start was called on the CMS GC tracer. If the
> background GC was aborted before the call to report_gc_start, we would
> then report concurrent mode failure on a GC tracer that is not started
> (an invalid state for a GC tracer).
>
> The fix is to move the call to report_gc_start to the same place in
> collect_in_background as where _collectorState is updated. However, this
> means that the heap_summary_before_gc event must be sent from
> checkpointRootsInitialPre due to lock ordering (Metaspace lock and CGC
> lock). Furthermore, collect_in_foreground must ensure that it does not
> call report_gc_start a second time (in the case when
> collect_in_foreground takes over a background GC).
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8011699/webrev.00/

I think this looks good.

/Mikael

>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011699
>
> Thanks,
> Erik


From stefan.karlsson at oracle.com  Wed Apr 10 14:58:44 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 10 Apr 2013 16:58:44 +0200
Subject: Review Request: 8011872: Include Bit Map addresses in the hs_err files
Message-ID: <51657E24.8060907@oracle.com>

http://cr.openjdk.java.net/~stefank/8011872/webrev.00/

I propose that we start logging the placement of the bitmaps hs_err 
crash files.

This will help identifies bugs where we have memory trashing in the 
bitmaps. Today, we have this kind of information for the card table but 
it's lacking for the bitmaps.

Example outputs:

-XX:+UseParallelOldGC:
Marking Bits: (ParMarkBitMap*) 0x00007ffff73a85e0
  Begin Bits: [0x00007fffe4200000, 0x00007fffe60b8000)
  End Bits:   [0x00007fffe60b8000, 0x00007fffe7f70000)

-XX:+UseG1GC:
Marking Bits (Prev, Next): (CMBitMap*) 0x00007ffff0059628, (CMBitMap*) 
0x00007ffff00596c0
  Prev Bits: [0x00007fffc5290000, 0x00007fffc7148000)
  Next Bits: [0x00007fffa2147000, 0x00007fffa3fff000)

-XX:+UseConcMarkSweepGC:
Marking Bits: (CMSBitMap*) 0x00007ffff00b0ee8
  Bits: [0x00007fffce7f1000, 0x00007fffcfc6e800)

Mod Union Table: (CMSBitMap*) 0x00007ffff00b0f88
  Bits: [0x00007ffff405c000, 0x00007ffff40adf60)

Note that for simplicity this logs the memory used by the low level 
datastructure BitMap, and not the memory allocated in the GC specific 
bitmap data structures (E.g. CMBitMap). What this means is that we 
actually allocate up to about os::vm_allocation_granularity() more memoy 
at the end of the bitmap. If this information is essential we can add it 
later.

thanks,
StefanK


From thomas.schatzl at oracle.com  Wed Apr 10 14:53:05 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 10 Apr 2013 16:53:05 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size
	limit is exceeded
In-Reply-To: <51625424.4050209@oracle.com>
References: <51625424.4050209@oracle.com>
Message-ID: <1365605585.3428.27.camel@cirrus>

Hi,

On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
> 6761744 Hotspot crashes if process size limit is exceeded
> https://jbs.oracle.com/bugs/browse/JDK-6761744
>
> webrev:
> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>
> changeset:
> The fix only needs to go to hsx24 since there's no perm gen in
> hotspot-25. Thus, the webrev is based on hsx24 repo.
>
> It provides for 32-bit builds a preventive check of the size of "the
> object heap + perm gen" before reserving VM memory. The total size
> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the
> total doesn't make sense and, what's worse, overflow occurs. It will
> consequentially trigger anther error of memory access violation, which
> was not protected.

I think this check should be done once in Universe::reserve_heap() where
the actual reservation occurs, just before that if possible instead of
special handling for every collector.

Additionally, Universe::reserve_heap() also does final alignment before
reserving the heap which might influence the actually reserved heap
size.

Thomas




From thomas.schatzl at oracle.com  Wed Apr 10 15:10:57 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 10 Apr 2013 17:10:57 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size
	limit is exceeded
In-Reply-To: <1365605585.3428.27.camel@cirrus>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
Message-ID: <1365606657.3428.35.camel@cirrus>

Hi,

On Wed, 2013-04-10 at 16:53 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
> > 6761744 Hotspot crashes if process size limit is exceeded
> > https://jbs.oracle.com/bugs/browse/JDK-6761744
> >
> > webrev:
> > http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
> >
> > changeset:
> > The fix only needs to go to hsx24 since there's no perm gen in
> > hotspot-25. Thus, the webrev is based on hsx24 repo.
> >
> > It provides for 32-bit builds a preventive check of the size of "the
> > object heap + perm gen" before reserving VM memory. The total size
> > should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the
> > total doesn't make sense and, what's worse, overflow occurs. It will
> > consequentially trigger anther error of memory access violation, which
> > was not protected.
> 
> I think this check should be done once in Universe::reserve_heap() where
> the actual reservation occurs, just before that if possible instead of
> special handling for every collector.
> 
> Additionally, Universe::reserve_heap() also does final alignment before
> reserving the heap which might influence the actually reserved heap
> size.

Okay, I just saw that I was looking at hsx25, sorry. In hsx24 there is
no Universe::reserve_heap() which all collectors call to actually
reserve the heap.

Not sure if it is part of this CR to unify this handling this for hsx24
into a single method similar to hsx25.

However, it may be interesting anyway to refactor the actual overflow
checking, i.e. some method that gets passed java heap size (I think
there is already the invariant that young + old gen size is always less
than max heap size, i.e. less than 4G on 32 bit), perm gen size and
alignment and is called by all three CollectedHeap implementations.

Hth,
Thomas




From bengt.rutisson at oracle.com  Wed Apr 10 15:11:59 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 10 Apr 2013 17:11:59 +0200
Subject: Review Request: 8011872: Include Bit Map addresses in the hs_err
	files
In-Reply-To: <51657E24.8060907@oracle.com>
References: <51657E24.8060907@oracle.com>
Message-ID: <5165813F.4090603@oracle.com>


Stefan,

Looks good!

Thanks for fixing this, I think it will be very useful!

Bengt

On 4/10/13 4:58 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8011872/webrev.00/
>
> I propose that we start logging the placement of the bitmaps hs_err 
> crash files.
>
> This will help identifies bugs where we have memory trashing in the 
> bitmaps. Today, we have this kind of information for the card table 
> but it's lacking for the bitmaps.
>
> Example outputs:
>
> -XX:+UseParallelOldGC:
> Marking Bits: (ParMarkBitMap*) 0x00007ffff73a85e0
>  Begin Bits: [0x00007fffe4200000, 0x00007fffe60b8000)
>  End Bits:   [0x00007fffe60b8000, 0x00007fffe7f70000)
>
> -XX:+UseG1GC:
> Marking Bits (Prev, Next): (CMBitMap*) 0x00007ffff0059628, (CMBitMap*) 
> 0x00007ffff00596c0
>  Prev Bits: [0x00007fffc5290000, 0x00007fffc7148000)
>  Next Bits: [0x00007fffa2147000, 0x00007fffa3fff000)
>
> -XX:+UseConcMarkSweepGC:
> Marking Bits: (CMSBitMap*) 0x00007ffff00b0ee8
>  Bits: [0x00007fffce7f1000, 0x00007fffcfc6e800)
>
> Mod Union Table: (CMSBitMap*) 0x00007ffff00b0f88
>  Bits: [0x00007ffff405c000, 0x00007ffff40adf60)
>
> Note that for simplicity this logs the memory used by the low level 
> datastructure BitMap, and not the memory allocated in the GC specific 
> bitmap data structures (E.g. CMBitMap). What this means is that we 
> actually allocate up to about os::vm_allocation_granularity() more 
> memoy at the end of the bitmap. If this information is essential we 
> can add it later.
>
> thanks,
> StefanK



From stefan.karlsson at oracle.com  Wed Apr 10 15:25:52 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 10 Apr 2013 17:25:52 +0200
Subject: Review Request: 8011872: Include Bit Map addresses in the hs_err
	files
In-Reply-To: <5165813F.4090603@oracle.com>
References: <51657E24.8060907@oracle.com> <5165813F.4090603@oracle.com>
Message-ID: <51658480.9080306@oracle.com>

On 04/10/2013 05:11 PM, Bengt Rutisson wrote:
>
> Stefan,
>
> Looks good!
>
> Thanks for fixing this, I think it will be very useful!

Thanks, Bengt!

StefanK

>
> Bengt
>
> On 4/10/13 4:58 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8011872/webrev.00/
>>
>> I propose that we start logging the placement of the bitmaps hs_err 
>> crash files.
>>
>> This will help identifies bugs where we have memory trashing in the 
>> bitmaps. Today, we have this kind of information for the card table 
>> but it's lacking for the bitmaps.
>>
>> Example outputs:
>>
>> -XX:+UseParallelOldGC:
>> Marking Bits: (ParMarkBitMap*) 0x00007ffff73a85e0
>>  Begin Bits: [0x00007fffe4200000, 0x00007fffe60b8000)
>>  End Bits:   [0x00007fffe60b8000, 0x00007fffe7f70000)
>>
>> -XX:+UseG1GC:
>> Marking Bits (Prev, Next): (CMBitMap*) 0x00007ffff0059628, 
>> (CMBitMap*) 0x00007ffff00596c0
>>  Prev Bits: [0x00007fffc5290000, 0x00007fffc7148000)
>>  Next Bits: [0x00007fffa2147000, 0x00007fffa3fff000)
>>
>> -XX:+UseConcMarkSweepGC:
>> Marking Bits: (CMSBitMap*) 0x00007ffff00b0ee8
>>  Bits: [0x00007fffce7f1000, 0x00007fffcfc6e800)
>>
>> Mod Union Table: (CMSBitMap*) 0x00007ffff00b0f88
>>  Bits: [0x00007ffff405c000, 0x00007ffff40adf60)
>>
>> Note that for simplicity this logs the memory used by the low level 
>> datastructure BitMap, and not the memory allocated in the GC specific 
>> bitmap data structures (E.g. CMBitMap). What this means is that we 
>> actually allocate up to about os::vm_allocation_granularity() more 
>> memoy at the end of the bitmap. If this information is essential we 
>> can add it later.
>>
>> thanks,
>> StefanK
>



From thomas.schatzl at oracle.com  Wed Apr 10 15:28:00 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 10 Apr 2013 17:28:00 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size
	limit is exceeded
In-Reply-To: <1365606657.3428.35.camel@cirrus>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
	<1365606657.3428.35.camel@cirrus>
Message-ID: <1365607680.3428.42.camel@cirrus>

Hi again,

On Wed, 2013-04-10 at 17:10 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2013-04-10 at 16:53 +0200, Thomas Schatzl wrote:
> > Hi,
> > 
> > On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
> > > 6761744 Hotspot crashes if process size limit is exceeded
> > > https://jbs.oracle.com/bugs/browse/JDK-6761744
> > >
> > > webrev:
> > > http://cr.openjdk.java.net/~tamao/6761744/webrev.00/

That change to the tests/TEST.ROOT file does not seem to belong to this
change as it seems unrelated to fixing this issue.

I do not know if it is worth to introduce this into the jdk7 branch, so
if you want it in (and others agree) please do a separate change for
that.

Thanks,
Thomas



From coleen.phillimore at oracle.com  Wed Apr 10 15:52:16 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 10 Apr 2013 11:52:16 -0400
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <1365606657.3428.35.camel@cirrus>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
	<1365606657.3428.35.camel@cirrus>
Message-ID: <51658AB0.5030900@oracle.com>

On 4/10/2013 11:10 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2013-04-10 at 16:53 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
>>> 6761744 Hotspot crashes if process size limit is exceeded
>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>
>>> changeset:
>>> The fix only needs to go to hsx24 since there's no perm gen in
>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>
>>> It provides for 32-bit builds a preventive check of the size of "the
>>> object heap + perm gen" before reserving VM memory. The total size
>>> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the
>>> total doesn't make sense and, what's worse, overflow occurs. It will
>>> consequentially trigger anther error of memory access violation, which
>>> was not protected.
>> I think this check should be done once in Universe::reserve_heap() where
>> the actual reservation occurs, just before that if possible instead of
>> special handling for every collector.
>>
>> Additionally, Universe::reserve_heap() also does final alignment before
>> reserving the heap which might influence the actually reserved heap
>> size.
> Okay, I just saw that I was looking at hsx25, sorry. In hsx24 there is
> no Universe::reserve_heap() which all collectors call to actually
> reserve the heap.
>
> Not sure if it is part of this CR to unify this handling this for hsx24
> into a single method similar to hsx25.

I don't think you can do this because one of the version does extra junk 
for class data sharing.

Coleen
(lurking on hotspot-gc)
>
> However, it may be interesting anyway to refactor the actual overflow
> checking, i.e. some method that gets passed java heap size (I think
> there is already the invariant that young + old gen size is always less
> than max heap size, i.e. less than 4G on 32 bit), perm gen size and
> alignment and is called by all three CollectedHeap implementations.
>
> Hth,
> Thomas
>
>



From tao.mao at oracle.com  Wed Apr 10 16:08:11 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 10 Apr 2013 09:08:11 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <1365606657.3428.35.camel@cirrus>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
	<1365606657.3428.35.camel@cirrus>
Message-ID: <51658E6B.20207@oracle.com>

Hi Thomas,

Thank you for reviewing.

The unification into Universe::reserve_heap() followed the perm gen 
removal. If needed, I would like to do the refactoring in hsx25, but the 
CR doesn't apply to it b/c it has sufficient invariant checks as you said.

Thanks.
Tao

On 4/10/13 8:10 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2013-04-10 at 16:53 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
>>> 6761744 Hotspot crashes if process size limit is exceeded
>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>
>>> changeset:
>>> The fix only needs to go to hsx24 since there's no perm gen in
>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>
>>> It provides for 32-bit builds a preventive check of the size of "the
>>> object heap + perm gen" before reserving VM memory. The total size
>>> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the
>>> total doesn't make sense and, what's worse, overflow occurs. It will
>>> consequentially trigger anther error of memory access violation, which
>>> was not protected.
>> I think this check should be done once in Universe::reserve_heap() where
>> the actual reservation occurs, just before that if possible instead of
>> special handling for every collector.
>>
>> Additionally, Universe::reserve_heap() also does final alignment before
>> reserving the heap which might influence the actually reserved heap
>> size.
> Okay, I just saw that I was looking at hsx25, sorry. In hsx24 there is
> no Universe::reserve_heap() which all collectors call to actually
> reserve the heap.
>
> Not sure if it is part of this CR to unify this handling this for hsx24
> into a single method similar to hsx25.
>
> However, it may be interesting anyway to refactor the actual overflow
> checking, i.e. some method that gets passed java heap size (I think
> there is already the invariant that young + old gen size is always less
> than max heap size, i.e. less than 4G on 32 bit), perm gen size and
> alignment and is called by all three CollectedHeap implementations.
>
> Hth,
> Thomas
>
>


From tao.mao at oracle.com  Wed Apr 10 16:11:29 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 10 Apr 2013 09:11:29 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <1365607680.3428.42.camel@cirrus>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
	<1365606657.3428.35.camel@cirrus> <1365607680.3428.42.camel@cirrus>
Message-ID: <51658F31.3000706@oracle.com>

Hi Thomas,

The modification of TEST.ROOT is needed for passing jtreg test. I could 
separate the testing code as a new CR but not sure if it's trivial.

Thanks.
Tao

On 4/10/13 8:28 AM, Thomas Schatzl wrote:
> Hi again,
>
> On Wed, 2013-04-10 at 17:10 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Wed, 2013-04-10 at 16:53 +0200, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
> That change to the tests/TEST.ROOT file does not seem to belong to this
> change as it seems unrelated to fixing this issue.
>
> I do not know if it is worth to introduce this into the jdk7 branch, so
> if you want it in (and others agree) please do a separate change for
> that.
>
> Thanks,
> Thomas
>


From tao.mao at oracle.com  Wed Apr 10 16:52:35 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 10 Apr 2013 09:52:35 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <516528C2.8080709@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
Message-ID: <516598D3.1020809@oracle.com>

Hi Bengt,

Thank you for reviewing. A new webrev is updated.
http://cr.openjdk.java.net/~tamao/6761744/webrev.01/

Cheers,
Tao

On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>
> Hi Tao,
>
> This change looks good. Thanks for adding the JTReg test, it looks good!
>
> One minor nit:
>
> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
> suggest to store "(size_t) align_size_up(pgs->max_size(), 
> HeapRegion::GrainBytes)" in a local variable rather than duplicating 
> the calculation.
>
> Thanks,
> Bengt
>
> On 4/8/13 7:22 AM, Tao Mao wrote:
>> 6761744 Hotspot crashes if process size limit is exceeded
>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>
>> webrev:
>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>
>> changeset:
>> The fix only needs to go to hsx24 since there's no perm gen in 
>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>
>> It provides for 32-bit builds a preventive check of the size of "the 
>> object heap + perm gen" before reserving VM memory. The total size 
>> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the 
>> total doesn't make sense and, what's worse, overflow occurs. It will 
>> consequentially trigger anther error of memory access violation, 
>> which was not protected.
>>
>> jtreg testing java code is also written, checking both 32-bit and 
>> (trivially) 64-bit builds.
>>
>> testing:
>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>> builds of 32-bit and 64-bit. All passed.
>>
>> Needs JPRT test when pushing.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130410/5b3d11ce/attachment.htm>

From mikael.gerdin at oracle.com  Wed Apr 10 18:10:20 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Wed, 10 Apr 2013 18:10:20 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8010196: NPG: Internal Error: Metaspace
	allocation lock -- possible deadlock
Message-ID: <20130410181025.8FCF6481BF@hg.openjdk.java.net>

Changeset: ba42fd5e00e6
Author:    mgerdin
Date:      2013-04-10 13:27 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ba42fd5e00e6

8010196: NPG: Internal Error: Metaspace allocation lock -- possible deadlock
Summary: Refactor the CLD dependency list into a separate class. Use an ObjectLocker to synchronize additions to the CLD dependency list.
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
+ test/gc/metaspace/G1AddMetaspaceDependency.java



From thomas.schatzl at oracle.com  Wed Apr 10 19:49:55 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 10 Apr 2013 21:49:55 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size
	limit is exceeded
In-Reply-To: <51658AB0.5030900@oracle.com>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
	<1365606657.3428.35.camel@cirrus> <51658AB0.5030900@oracle.com>
Message-ID: <1365623395.2791.9.camel@cirrus>

Hi,

On Wed, 2013-04-10 at 11:52 -0400, Coleen Phillimore wrote:
> On 4/10/2013 11:10 AM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Wed, 2013-04-10 at 16:53 +0200, Thomas Schatzl wrote:
> >> Hi,
> >>
> >> On Sun, 2013-04-07 at 22:22 -0700, Tao Mao wrote:
> >>> 6761744 Hotspot crashes if process size limit is exceeded
> >>> https://jbs.oracle.com/bugs/browse/JDK-6761744
> >>>
> >>> webrev:
> >>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
> >>>
> >>> changeset:
> >>> The fix only needs to go to hsx24 since there's no perm gen in
> >>> hotspot-25. Thus, the webrev is based on hsx24 repo.
> >>>
> >>> It provides for 32-bit builds a preventive check of the size of "the
> >>> object heap + perm gen" before reserving VM memory. The total size
> >>> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the
> >>> total doesn't make sense and, what's worse, overflow occurs. It will
> >>> consequentially trigger anther error of memory access violation, which
> >>> was not protected.
> >> I think this check should be done once in Universe::reserve_heap() where
> >> the actual reservation occurs, just before that if possible instead of
> >> special handling for every collector.
> >>
> >> Additionally, Universe::reserve_heap() also does final alignment before
> >> reserving the heap which might influence the actually reserved heap
> >> size.
> > Okay, I just saw that I was looking at hsx25, sorry. In hsx24 there is
> > no Universe::reserve_heap() which all collectors call to actually
> > reserve the heap.
> >
> > Not sure if it is part of this CR to unify this handling this for hsx24
> > into a single method similar to hsx25.
> 
> I don't think you can do this because one of the version does extra junk 
> for class data sharing.

I wasn't exactly thinking of backporting the fix verbatim but doing
something similar - but probably it is beyond the scope of this CR.

I am leaving this up to Tao and the others to decide.

@Coleen: I was asking myselves when comparing with the code for
calculating the maximum heap for ergonomically enabling compressed oops:
isn't the limit for heap+perm actually 2^bitsize - 1 OS page (the null
page excluded), do you know?

> 
> Coleen
> (lurking on hotspot-gc)
> >
> > However, it may be interesting anyway to refactor the actual overflow
> > checking, i.e. some method that gets passed java heap size (I think
> > there is already the invariant that young + old gen size is always less
> > than max heap size, i.e. less than 4G on 32 bit), perm gen size and
> > alignment and is called by all three CollectedHeap implementations.
> >

As mentioned I still believe it would be nice to have the checking code
extracted into a single method that is shared and used by all of the
heap implementations.

Replicating the same (string) constant and basically the same checking
three times in the code seems undesirable.

Thomas



From jesper.wilhelmsson at oracle.com  Wed Apr 10 20:15:47 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 10 Apr 2013 22:15:47 +0200
Subject: RFR: 8009032 - Implement evacuation info event
In-Reply-To: <51651FFB.6040705@oracle.com>
References: <515D8864.6070209@oracle.com> <5164A6CE.6080104@oracle.com>
	<51651FFB.6040705@oracle.com>
Message-ID: <5165C873.3010608@oracle.com>

Hi,

New webrev available here:
http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/

All names are changed to reduce confusion.
/Jesper


Bengt Rutisson skrev 10/4/13 10:16 AM:
>
> Hi Jesper,
>
> This is better but I'm a bit confused about the data that we report.
>
> usedAllocRegionsBefore/used_alloc_regions_before
> Does not seem to be the correct name. What you report here is the used bytes for
> the one alloc region that we retained from the last GC.
>
> usedCSetAfter/used_collectionset_after
> Does not seem to be the correct name. What you report is the used bytes for the
> survivor regions. The old alloc regions are not included.
>
> usedAllocRegionsAfter/used_alloc_regions_after
> Does not seem to be the correct name. What you report is the amount of bytes
> that survived the collection. Either because it was copied (to alloc regions) or
> because we got evacuation failure and it was left in place. This value also does
> not include the value that you reported in "used_alloc_regions_before". I don't
> think it should, but the current name kind of indicates that.
>
> regionsFreed/regions_freed
> Does not seem to be the correct name. What you report is the number of regions
> that had been freed just before the current region. I think the name may be
> correct if you move the call to _evacuation_info.register_regions_freed() to
> after the loop.
>
>
> Code comments:
>
> g1CollectedHeap.cpp/hpp
>
> I would suggest to not have _evacuation_info as an instance variable in
> G1CollectedHeap and instead have it as a local variable in
> G1CollectedHeap::do_collection_pause_at_safepoint(). That would remove the need
> for EvacuationInfo::reset().
>
>
> Maybe it's better to inline the call to
> _evacuation_info.register_collectionset_regions() inside to
> g1_policy()->finalize_cset()?
>
>          g1_policy()->finalize_cset(target_pause_time_ms);
> _evacuation_info.register_collectionset_regions(g1_policy()->cset_region_length());
>
>
> gcTrace.hpp
>
> Why did you move G1OldTracer to within "#ifndef SERIALGC" the other tracer are
> not guarded by this unless they have to (as G1NewTracer)?
>
> I think it is better to forward declare the EvacuationInfo class than including
> gc_implementation/g1/evacuationInfo.hpp since you only use EvacuationInfo*. (If
> you decide to keep the include you need to move it in under #ifndef SERIALGC.)
>
>
> evacuationInfo.hpp:
> I don't think it needs this include:
> #include "gc_implementation/g1/heapRegion.hpp"
>
> Why do you use += for all the setters? For the cases where you do accumulate
> (like in G1CollectedHeap::free_collection_set()) I think it would be better to
> accumulate in a local variable and then just call register once with the total.
>
> Bengt
>
>
> On 4/10/13 1:39 AM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> Got some internal feedback (thanks Bengt!) and here is a new version:
>>
>> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>>
>> Thanks,
>> /Jesper
>>
>>
>>
>> Jesper Wilhelmsson skrev 4/4/13 4:04 PM:
>>> Hi,
>>>
>>> I'm looking for a couple of reviews for this change.
>>>
>>> This is an tracing event with information about G1 evacuation/compaction. It
>>> contains the number of regions in from-space and to-space, how much data that
>>> was used before and after, the number of bytes copied during the
>>> evacuation/compaction, and how many regions that was completely freed during an
>>> evacuation.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/
>>>
>>>
>>> The patch also contains a bunch of fixed typos in various comments nearby the
>>> relevant changes. These may add some noise to the webrev, if you prefer to look
>>> at the webrev without these changes a separate webrev is available here:
>>>
>>> Webrev without typo fixes:
>>> http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/
>>>
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032
>>>
>>> Thanks,
>>> /Jesper
>


From jesper.wilhelmsson at oracle.com  Wed Apr 10 20:37:29 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 10 Apr 2013 22:37:29 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <516365F2.2000204@oracle.com>
References: <51549110.2010208@oracle.com> <5154B427.2060503@oracle.com>
	<51611811.2010403@oracle.com> <516365F2.2000204@oracle.com>
Message-ID: <5165CD89.90304@oracle.com>

Hi,

An updated webrev based on the feedback from John an Bengt is available here:
http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/

Thanks for reviewing!
/Jesper


John Cuthbertson skrev 9/4/13 2:50 AM:
> Hi Jesper,
>
> A quick question before going on with the actual review....
>
> Do you need the native thread ID in the event or just the worker IDs?
>
> As you have seen tying something to specific worker native IDs across multiple
> gang tasks is not easy. If you actually need the native thread IDs then I'm not
> sure what the best approach is. The most obvious is to have some sequential
> number in each worker that is fixed for the life of that worker (i.e. the life
> the JVM) and use that value to index into the evacuation_failed_info_array.
> Fortunately, I think we have that - it's the WorkerThread::_id field:
>
>>   for (uint worker = 0; worker < total_workers(); worker += 1) {
>>     GangWorker* new_worker = allocate_worker(worker);
>
> and:
>
>> GangWorker* WorkGang::allocate_worker(uint which) {
>>   GangWorker* new_worker = new GangWorker(this, which);
>>   return new_worker;
>> }
>> GangWorker::GangWorker(AbstractWorkGang* gang, uint id) {
>>   _gang = gang;
>>   set_id(id);
>>   set_name("Gang worker#%d (%s)", id, gang->name());
>> }
>
> So instead of associating the entries in the evacuation_failed_info_array with
> worker_id/queue_num, they are associated with
> Thread::current()->as_Worker_thread()->id(). Note if ParallelGCThreads=0 then
> the worker threads are not created but you are using ParallelGCThreads as the
> index for the VM thread - that's OK (but is a break with convention). You
> comment it (and why).
>
> Now on to the actual review:
>
> g1CollectedHeap.hpp:
>
> Line 888:
> I think you can make this an array of EvacFailureInfo instances rather than
> pointers. I think it's safer to do this. Once you establish the mapping between
> worker thread and EvacFailureInfo instance - you don't want it to change.
>
> Line 930:
> The change is unnecessary - but it's OK to leave it.
>
> Line 1817:
> Again since the mapping between worker thread and evac failed info instance is
> fixed, there's no need to embed a pointer to the object into the PSS but it's OK
> to leave it but I would initialize in the constructor, i.e. have something like
> the following in the PSS constructor:
>
> // The value of native_id is used to index into the evacuation_failed_info array
> Thread* me = Thread::current();
> uint native_id = 0;
> if (me->is_Worker_thread()) {
>    native_id = me->as_Worker_thread()->id();
> } else {
>    assert(me->is_VMThread(), "who else?");
>    native_id = ParallelGCThreads;
> }
> _evac_failed_info = _g1h->evacuation_failed_instance_for(native_id);
>
> Alternatively store the native worker ID as well as queue_num in the PSS - you
> can use that to access the instance.
>
> Line 1863:
> This line is unnecessary. You no longer need the routine.
>
> Line 1951:
> This line may be unnecessary. You could return the _native_id stored in the PSS
> and fetch the evac_failed_info object for that _native_id from the array. I'll
> leave it up to you.
>
> g1CollectedHeap.cpp
>
> Line 1970 - 1976
> I really don't like that you  allocate ParallelGCThreads+1 entries - I would
> prefer to use n_queues but I can see why you need to - if parallel reference
> processing is not enabled. The convention is that if ParallelGCThreads==0,
> n_queues will be 1 and we use queue[0] and worker_id 0. I want lots of comments
> here since you're breaking with convention.
>
> Fold the initialization of the evac_failed_info array into one of the other
> loops or fold all three loops into one:
>
>> 1954   for (int i = 0; i < n_queues; i++) {
>> 1955     iter_arr[i] = new HeapRegionRemSetIterator();
>> 1956   }
>
>> 1962   for (int i = 0; i < n_queues; i++) {
>> 1963     RefToScanQueue* q = new RefToScanQueue();
>> 1964     q->initialize();
>> 1965     _task_queues->register_queue(i, q);
>> 1966   }
>> 1971   for (uint n = 0; n < ParallelGCThreads; n++) {
>> 1972     _evacuation_failed_info_array[n] = NULL;
>> 1973   }
>
> I think you also want to allocate/reset/initialize the evac_failure_info
> objects. You could also bind to the worker thread:
>
> if (G1CollectedHeap::use_parallel_gc_threads()) {
>    assert(workers()->total_workers == n_queues(), "check this code otherwise");
>    for (uint k = 0; k < workers()->total_workers()l k += 1) {
>      GangWorker *worker = workers()->gang_worker(k);
>      uint id = worker->id();
>      _evac_failed_info[id].bind_to_thread(worker);
>    }
> }
>
> // The following is unconditional.
>   _evac_failed_info[ParallelGCThreads].bind_to_thread(VMThread::vm_thread());
>
> But binding as the first thing in G1ParTask::work() would be OK too.
>
> Line 3813:
> You don't need  to do this here. It can be done in G1ParTask::work() or during
> initialization. Again lot's of comments about why the evac_failure_info instance
> for the VMThread is not encoded at index 0.
>
> 4051-4056:
> Use the use_parallel_gc_threads idiom:
>
> if (G1CollectedHeap::use_parallel_gc_threads()) {
>    // Since there are multiple parallel tasks where an evacuation failure could
> occur
>    // and (in the future) each task may have been executed by a different number
> of workers,
>    // we need to check them all.
>    for (uint i = 0; i < workers()->total_workers(); i += 1) {
>      ....
>    }
> }
> // Now check the VM thread as it could have seen an evacuation failure during
> serial
> // reference processing
> ...
>
> Line 4480:
> This line may not be necessary.
>
> Lines 4507-4533:
> Routine may not be necessary. The loop in particular:
>
>> 4521     while (_evacuation_failed_info == NULL) {
>> 4522       EvacuationFailedInfo* current =
>> _g1h->_evacuation_failed_info_array[n];
>> 4523       assert(current != NULL, "All info objects should have been
>> allocated already");
>> 4524       if (current->thread() == Thread::current()->osthread()) {
>> 4525         _evacuation_failed_info = current;
>> 4526       } else {
>> 4527         n++;
>> 4528         assert(n <= ParallelGCThreads, "There shouldn't be more threads
>> than ParallelGThreads + the main GC thread");
>> 4529       }
>> 4530     }
>
> is a big concern.This is an O(n) lookup for each of n threads, for each of the
> distinct parallel tasks (3).
>
> The other files look OK.
>
> JohnC
>
> On 4/6/2013 11:54 PM, Jesper Wilhelmsson wrote:
>> Bengt, all,
>>
>> A new webrev is now available:
>>
>> http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/
>>
>> The main difference is that now we have an array in G1CollectedHeap that keeps
>> track the EvacuationFailedInfo-objects between the different parallel parts of
>> G1 so that each thread only sends a single EvacuationFailed event in the end.
>>
>> To achieve this some logic was added to find the correct info object in the
>> array since the threads does not have the same queue number each time.
>>
>> Thanks,
>> /Jesper
>>
>>
>> Bengt Rutisson skrev 28/3/13 10:20 PM:
>>>
>>> Jesper,
>>>
>>> This looks much better!
>>>
>>> Have you tested it to see that you get a maximum of one event per GC thread and
>>> GC? It looks to me like you risk getting multiple events sent for each GC thread
>>> every GC.
>>>
>>> You send the events in the G1ParScanThreadState destructor. I am not that
>>> familiar with G1ParScanThreadState but it looks to me like we create new
>>> G1ParScanThreadState instances for the different phases of a GC. Here are the
>>> places where we create new instances of G1ParScanThreadState:
>>>
>>> G1CollectedHeap::process_discovered_references()
>>> G1ParPreserveCMReferentsTask::work()
>>> G1ParTask::work()
>>> G1STWRefProcTaskProxy::work()
>>>
>>> So, it looks to me like we risk getting 4 events sent per thread and GC.
>>>
>>>
>>> Some minor comments:
>>>
>>> In G1CollectedHeap::handle_evacuation_failure_par() you pass the ef_info on to
>>> G1CollectedHeap::handle_evacuation_failure_common(). But the ef_info is now
>>> thread local so you don't have to take the lock to use it. One way to simplify
>>> this would be to do "ef_info->register_copy_failure(old->size());" in
>>> G1CollectedHeap::handle_evacuation_failure_par() just before "if
>>> (_evac_failure_closure != cl)" instead. Then you don't have to pass it on to
>>> handle_evacuation_failure_common().
>>>
>>> (As a side note, I don't think setting _evacuation_failed to true has to be
>>> protected by the lock either. It is a shared variable but all writes to it from
>>> different threads will be to set it to true, so I think racing on it is benign.
>>> But you have it in the same place as before, which might be good.)
>>>
>>> In G1ParCopyClosure::copy_to_survivor_space() you are now picking out two thing
>>> from the _par_scan_state and passing them on to
>>> G1CollectedHeap::handle_evacuation_failure_par(). Have you considered passing a
>>> reference to _par_scan_state instead and let handle_evacuation_failure_par()
>>> extract the data it needs?
>>>
>>> If you move the implementation of the destructor of G1ParScanThreadState in to
>>> the cpp file you don't have to add the include for gcTrace.hpp to
>>> g1CollectedHeap.hpp.
>>>
>>> Why did you decide to remove set_evactuation_failed()?
>>>
>>> Finally, you have several quite unrelated spelling corrections in this change.
>>> This makes it a bit hard to review. I'm not sure I think it is worth the extra
>>> review time to get those fixed.
>>>
>>> Bengt
>>>
>>>
>>> On 3/28/13 7:50 PM, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> A new version of the evacuation failed event for G1. Now, each thread sends an
>>>> event with the info it has collected during the collection in the same way as
>>>> the other collectors do with promotion failed events.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>>>
>>>> Thanks,
>>>> /Jesper
>>>
>


From john.cuthbertson at oracle.com  Thu Apr 11 00:12:20 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 10 Apr 2013 17:12:20 -0700
Subject: RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
In-Reply-To: <1365583061.3428.19.camel@cirrus>
References: <50F5E6BE.9040901@oracle.com> <51630913.6070506@oracle.com>
	<1365523660.2665.36.camel@cirrus> <51648D70.10404@oracle.com>
	<1365583061.3428.19.camel@cirrus>
Message-ID: <5165FFE4.3050206@oracle.com>

Hi Thomas,

On 4/10/2013 1:37 AM, Thomas Schatzl wrote:
> It's okay, it's only that your description in the email to the mailing
> list indicated otherwise to me.
> The comment in the code reads "// If we failed to allocate the counts
> table, return 0.". Maybe the comment could explicitly indicate that that
> means the cards will always be cold in that case.
>
> What does " 145   // If card_ptr is beyond the committed end of the
> counts table, return 0." actually mean if card_ptr is beyond the end of
> the count table? There was not enough memory?

That's it exactly. Basically we expand the counts table when we expand 
the heap. So there is a chance we could successfully commit additional 
space for the heap but fail to commit additional space for the counts 
table. Since this is not a critical table - we can live with it being 
smaller than it should be at the expense of losing the optimization for 
some cards.

>
> In resize() the assert at line 132 indicates that this is actually a
> failure, which seems somewhat inconsistent in the way this situation is
> handled in debug/production mode.

You mean this one:

     assert(_card_counts_storage.committed_size() == new_committed_size,
            "expansion commit failure");

I allow for a failed expansion. But if the expansion is successful I 
want to ensure that I got all that I asked for. That should be the case. 
If it turns out not to be the case then the assert is an indication that 
we have to revisit the code. In most places where we commit space, we 
assert that the entire commit was successful.

> One further nitpick: the general documentation for the new classes is
> within the class. It looks as if that documentation is part of the first
> member of the class.
>
> E.g.
>
> class XX {
>    // documentation for XX
> }
>
> instead of the seemingly more common
>
> // documentation for XX
> class XX {
> }
>
> Not sure what's the preference here.

Me neither but it looks like you are right. I'll move those comments.

Thanks again for looking over the code changes.

JohnC


From john.cuthbertson at oracle.com  Thu Apr 11 00:20:34 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 10 Apr 2013 17:20:34 -0700
Subject: RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
In-Reply-To: <5165FFE4.3050206@oracle.com>
References: <50F5E6BE.9040901@oracle.com> <51630913.6070506@oracle.com>
	<1365523660.2665.36.camel@cirrus> <51648D70.10404@oracle.com>
	<1365583061.3428.19.camel@cirrus> <5165FFE4.3050206@oracle.com>
Message-ID: <516601D2.4050205@oracle.com>

Hi Thomas,

One more thing....

On 4/10/2013 5:12 PM, John Cuthbertson wrote:
> Hi Thomas,
>
> On 4/10/2013 1:37 AM, Thomas Schatzl wrote:
>> It's okay, it's only that your description in the email to the mailing
>> list indicated otherwise to me.
>> The comment in the code reads "// If we failed to allocate the counts
>> table, return 0.". Maybe the comment could explicitly indicate that that
>> means the cards will always be cold in that case.

I added the following to the comment:

>   // Unless G1ConcRSHotCardLimit has been set appropriately,
>   // returning 0 will result in the card being considered
>   // cold and will be refined immediately.

JohnC


From stefan.karlsson at oracle.com  Thu Apr 11 07:33:43 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 11 Apr 2013 09:33:43 +0200
Subject: Review Request: 8011872: Include Bit Map addresses in the hs_err
	files
In-Reply-To: <5165B747.1010501@oracle.com>
References: <51657E24.8060907@oracle.com> <5165B747.1010501@oracle.com>
Message-ID: <51666757.6010507@oracle.com>

(readding hotspot-gc-dev)

On 04/10/2013 09:02 PM, Jon Masamitsu wrote:
> Changes look good.

Thanks.

>
> Did you see a case where _collector was NULL?  Or is this
> clean coding?
>
>> *+ CMSCollector::print_on_error(outputStream* st) {*
>> *+   CMSCollector* collector = ConcurrentMarkSweepGeneration::_collector;*
>> *+   if (collector != NULL) {*
>

This is just defensive programming.

The _collector will always be setup when we try to print the heap in the 
hs_err files. The logging is guarded by this:
      if (_verbose && Universe::is_fully_initialized()) {
        Universe::heap()->print_on_error(st);

The Universe is fully initialized in universe_post_init() and _collector 
is setup before that, deep down in universe_init().

thanks,
StefanK

> Jon
>
> On 4/10/2013 7:58 AM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8011872/webrev.00/
>>
>> I propose that we start logging the placement of the bitmaps hs_err 
>> crash files.
>>
>> This will help identifies bugs where we have memory trashing in the 
>> bitmaps. Today, we have this kind of information for the card table 
>> but it's lacking for the bitmaps.
>>
>> Example outputs:
>>
>> -XX:+UseParallelOldGC:
>> Marking Bits: (ParMarkBitMap*) 0x00007ffff73a85e0
>>  Begin Bits: [0x00007fffe4200000, 0x00007fffe60b8000)
>>  End Bits:   [0x00007fffe60b8000, 0x00007fffe7f70000)
>>
>> -XX:+UseG1GC:
>> Marking Bits (Prev, Next): (CMBitMap*) 0x00007ffff0059628, 
>> (CMBitMap*) 0x00007ffff00596c0
>>  Prev Bits: [0x00007fffc5290000, 0x00007fffc7148000)
>>  Next Bits: [0x00007fffa2147000, 0x00007fffa3fff000)
>>
>> -XX:+UseConcMarkSweepGC:
>> Marking Bits: (CMSBitMap*) 0x00007ffff00b0ee8
>>  Bits: [0x00007fffce7f1000, 0x00007fffcfc6e800)
>>
>> Mod Union Table: (CMSBitMap*) 0x00007ffff00b0f88
>>  Bits: [0x00007ffff405c000, 0x00007ffff40adf60)
>>
>> Note that for simplicity this logs the memory used by the low level 
>> datastructure BitMap, and not the memory allocated in the GC specific 
>> bitmap data structures (E.g. CMBitMap). What this means is that we 
>> actually allocate up to about os::vm_allocation_granularity() more 
>> memoy at the end of the bitmap. If this information is essential we 
>> can add it later.
>>
>> thanks,
>> StefanK
>

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

From bengt.rutisson at oracle.com  Thu Apr 11 08:22:10 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 11 Apr 2013 10:22:10 +0200
Subject: RFR: 8009032 - Implement evacuation info event
In-Reply-To: <5165C873.3010608@oracle.com>
References: <515D8864.6070209@oracle.com> <5164A6CE.6080104@oracle.com>
	<51651FFB.6040705@oracle.com> <5165C873.3010608@oracle.com>
Message-ID: <516672B2.4010408@oracle.com>


Hi Jesper,

Thanks for cleaning the naming up.

This looks good except that in gcTraceSend.cpp you need to move #include 
"gc_implementation/g1/evacuationInfo.hpp" into the #ifndef SERIALGC 
section. I don't think it will build for embedded in hsx24 otherwise and 
in hsx25 it may break if a dependency to any excluded file is ever added 
to evacuationInfo.hpp. In gcTrace.cpp you already have the include 
guarded by the #ifndef.

A couple of minor things in trace.xml:

I think the field name collectionSetRegions could be cSetRegions to be 
consistent with cSetUsedBefore and cSetUsedAfter.

As we discussed yesterday I am not convinced that the information in 
allocRegionsUsedAfter is worth having since it is just derived from 
allocRegionsUsedBefore and bytesCopied. But I'm ok with having it.

bytesCopied and regionsFreed are missing descriptions. Is this intended 
or do you want to add some explanation for these values as well.

Thanks,
Bengt

On 4/10/13 10:15 PM, Jesper Wilhelmsson wrote:
> Hi,
>
> New webrev available here:
> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>
> All names are changed to reduce confusion.
> /Jesper
>
>
> Bengt Rutisson skrev 10/4/13 10:16 AM:
>>
>> Hi Jesper,
>>
>> This is better but I'm a bit confused about the data that we report.
>>
>> usedAllocRegionsBefore/used_alloc_regions_before
>> Does not seem to be the correct name. What you report here is the 
>> used bytes for
>> the one alloc region that we retained from the last GC.
>>
>> usedCSetAfter/used_collectionset_after
>> Does not seem to be the correct name. What you report is the used 
>> bytes for the
>> survivor regions. The old alloc regions are not included.
>>
>> usedAllocRegionsAfter/used_alloc_regions_after
>> Does not seem to be the correct name. What you report is the amount 
>> of bytes
>> that survived the collection. Either because it was copied (to alloc 
>> regions) or
>> because we got evacuation failure and it was left in place. This 
>> value also does
>> not include the value that you reported in 
>> "used_alloc_regions_before". I don't
>> think it should, but the current name kind of indicates that.
>>
>> regionsFreed/regions_freed
>> Does not seem to be the correct name. What you report is the number 
>> of regions
>> that had been freed just before the current region. I think the name 
>> may be
>> correct if you move the call to 
>> _evacuation_info.register_regions_freed() to
>> after the loop.
>>
>>
>> Code comments:
>>
>> g1CollectedHeap.cpp/hpp
>>
>> I would suggest to not have _evacuation_info as an instance variable in
>> G1CollectedHeap and instead have it as a local variable in
>> G1CollectedHeap::do_collection_pause_at_safepoint(). That would 
>> remove the need
>> for EvacuationInfo::reset().
>>
>>
>> Maybe it's better to inline the call to
>> _evacuation_info.register_collectionset_regions() inside to
>> g1_policy()->finalize_cset()?
>>
>>          g1_policy()->finalize_cset(target_pause_time_ms);
>> _evacuation_info.register_collectionset_regions(g1_policy()->cset_region_length()); 
>>
>>
>>
>> gcTrace.hpp
>>
>> Why did you move G1OldTracer to within "#ifndef SERIALGC" the other 
>> tracer are
>> not guarded by this unless they have to (as G1NewTracer)?
>>
>> I think it is better to forward declare the EvacuationInfo class than 
>> including
>> gc_implementation/g1/evacuationInfo.hpp since you only use 
>> EvacuationInfo*. (If
>> you decide to keep the include you need to move it in under #ifndef 
>> SERIALGC.)
>>
>>
>> evacuationInfo.hpp:
>> I don't think it needs this include:
>> #include "gc_implementation/g1/heapRegion.hpp"
>>
>> Why do you use += for all the setters? For the cases where you do 
>> accumulate
>> (like in G1CollectedHeap::free_collection_set()) I think it would be 
>> better to
>> accumulate in a local variable and then just call register once with 
>> the total.
>>
>> Bengt
>>
>>
>> On 4/10/13 1:39 AM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> Got some internal feedback (thanks Bengt!) and here is a new version:
>>>
>>> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>>>
>>> Thanks,
>>> /Jesper
>>>
>>>
>>>
>>> Jesper Wilhelmsson skrev 4/4/13 4:04 PM:
>>>> Hi,
>>>>
>>>> I'm looking for a couple of reviews for this change.
>>>>
>>>> This is an tracing event with information about G1 
>>>> evacuation/compaction. It
>>>> contains the number of regions in from-space and to-space, how much 
>>>> data that
>>>> was used before and after, the number of bytes copied during the
>>>> evacuation/compaction, and how many regions that was completely 
>>>> freed during an
>>>> evacuation.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/
>>>>
>>>>
>>>> The patch also contains a bunch of fixed typos in various comments 
>>>> nearby the
>>>> relevant changes. These may add some noise to the webrev, if you 
>>>> prefer to look
>>>> at the webrev without these changes a separate webrev is available 
>>>> here:
>>>>
>>>> Webrev without typo fixes:
>>>> http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/
>>>>
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032
>>>>
>>>> Thanks,
>>>> /Jesper
>>



From jesper.wilhelmsson at oracle.com  Thu Apr 11 08:57:13 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 11 Apr 2013 10:57:13 +0200
Subject: RFR: 8009032 - Implement evacuation info event
In-Reply-To: <516672B2.4010408@oracle.com>
References: <515D8864.6070209@oracle.com> <5164A6CE.6080104@oracle.com>
	<51651FFB.6040705@oracle.com> <5165C873.3010608@oracle.com>
	<516672B2.4010408@oracle.com>
Message-ID: <51667AE9.8090607@oracle.com>

Bengt,

Thanks for reviewing!

Bengt Rutisson skrev 11/4/13 10:22 AM:
>
> Hi Jesper,
>
> Thanks for cleaning the naming up.
>
> This looks good except that in gcTraceSend.cpp you need to move #include
> "gc_implementation/g1/evacuationInfo.hpp" into the #ifndef SERIALGC section. I
> don't think it will build for embedded in hsx24 otherwise and in hsx25 it may
> break if a dependency to any excluded file is ever added to evacuationInfo.hpp.
> In gcTrace.cpp you already have the include guarded by the #ifndef.

Fixed.

>
> A couple of minor things in trace.xml:
>
> I think the field name collectionSetRegions could be cSetRegions to be
> consistent with cSetUsedBefore and cSetUsedAfter.

Fixed.

>
> As we discussed yesterday I am not convinced that the information in
> allocRegionsUsedAfter is worth having since it is just derived from
> allocRegionsUsedBefore and bytesCopied. But I'm ok with having it.
>
> bytesCopied and regionsFreed are missing descriptions. Is this intended or do
> you want to add some explanation for these values as well.

This was intentional. Most of our events don't have any description, but I added 
it to the cSet and allocRegions fields since they caused confusion and needed to 
be explained.

Thanks,
/Jesper

>
> Thanks,
> Bengt
>
> On 4/10/13 10:15 PM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> New webrev available here:
>> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>>
>> All names are changed to reduce confusion.
>> /Jesper
>>
>>
>> Bengt Rutisson skrev 10/4/13 10:16 AM:
>>>
>>> Hi Jesper,
>>>
>>> This is better but I'm a bit confused about the data that we report.
>>>
>>> usedAllocRegionsBefore/used_alloc_regions_before
>>> Does not seem to be the correct name. What you report here is the used bytes for
>>> the one alloc region that we retained from the last GC.
>>>
>>> usedCSetAfter/used_collectionset_after
>>> Does not seem to be the correct name. What you report is the used bytes for the
>>> survivor regions. The old alloc regions are not included.
>>>
>>> usedAllocRegionsAfter/used_alloc_regions_after
>>> Does not seem to be the correct name. What you report is the amount of bytes
>>> that survived the collection. Either because it was copied (to alloc regions) or
>>> because we got evacuation failure and it was left in place. This value also does
>>> not include the value that you reported in "used_alloc_regions_before". I don't
>>> think it should, but the current name kind of indicates that.
>>>
>>> regionsFreed/regions_freed
>>> Does not seem to be the correct name. What you report is the number of regions
>>> that had been freed just before the current region. I think the name may be
>>> correct if you move the call to _evacuation_info.register_regions_freed() to
>>> after the loop.
>>>
>>>
>>> Code comments:
>>>
>>> g1CollectedHeap.cpp/hpp
>>>
>>> I would suggest to not have _evacuation_info as an instance variable in
>>> G1CollectedHeap and instead have it as a local variable in
>>> G1CollectedHeap::do_collection_pause_at_safepoint(). That would remove the need
>>> for EvacuationInfo::reset().
>>>
>>>
>>> Maybe it's better to inline the call to
>>> _evacuation_info.register_collectionset_regions() inside to
>>> g1_policy()->finalize_cset()?
>>>
>>>          g1_policy()->finalize_cset(target_pause_time_ms);
>>> _evacuation_info.register_collectionset_regions(g1_policy()->cset_region_length());
>>>
>>>
>>>
>>> gcTrace.hpp
>>>
>>> Why did you move G1OldTracer to within "#ifndef SERIALGC" the other tracer are
>>> not guarded by this unless they have to (as G1NewTracer)?
>>>
>>> I think it is better to forward declare the EvacuationInfo class than including
>>> gc_implementation/g1/evacuationInfo.hpp since you only use EvacuationInfo*. (If
>>> you decide to keep the include you need to move it in under #ifndef SERIALGC.)
>>>
>>>
>>> evacuationInfo.hpp:
>>> I don't think it needs this include:
>>> #include "gc_implementation/g1/heapRegion.hpp"
>>>
>>> Why do you use += for all the setters? For the cases where you do accumulate
>>> (like in G1CollectedHeap::free_collection_set()) I think it would be better to
>>> accumulate in a local variable and then just call register once with the total.
>>>
>>> Bengt
>>>
>>>
>>> On 4/10/13 1:39 AM, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> Got some internal feedback (thanks Bengt!) and here is a new version:
>>>>
>>>> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>>>>
>>>> Thanks,
>>>> /Jesper
>>>>
>>>>
>>>>
>>>> Jesper Wilhelmsson skrev 4/4/13 4:04 PM:
>>>>> Hi,
>>>>>
>>>>> I'm looking for a couple of reviews for this change.
>>>>>
>>>>> This is an tracing event with information about G1 evacuation/compaction. It
>>>>> contains the number of regions in from-space and to-space, how much data that
>>>>> was used before and after, the number of bytes copied during the
>>>>> evacuation/compaction, and how many regions that was completely freed
>>>>> during an
>>>>> evacuation.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/
>>>>>
>>>>>
>>>>> The patch also contains a bunch of fixed typos in various comments nearby the
>>>>> relevant changes. These may add some noise to the webrev, if you prefer to
>>>>> look
>>>>> at the webrev without these changes a separate webrev is available here:
>>>>>
>>>>> Webrev without typo fixes:
>>>>> http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/
>>>>>
>>>>>
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032
>>>>>
>>>>> Thanks,
>>>>> /Jesper
>>>
>


From stefan.karlsson at oracle.com  Thu Apr 11 10:45:48 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Thu, 11 Apr 2013 10:45:48 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011872: Include Bit Map addresses in the
	hs_err files
Message-ID: <20130411104554.70378481FC@hg.openjdk.java.net>

Changeset: 7b835924c31c
Author:    stefank
Date:      2013-04-10 14:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7b835924c31c

8011872: Include Bit Map addresses in the hs_err files
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/vmError.cpp



From thomas.schatzl at oracle.com  Thu Apr 11 13:33:02 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 11 Apr 2013 15:33:02 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1364306183.2847.52.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
Message-ID: <1365687182.2594.19.camel@cirrus>

Hi all,

  there is a new webrev for this issue at
http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/

Since it has been a while since the last update, here is a short
introduction to the problem again:

The current argument processing for minimum, initial and maximum heap
sizing is somewhat unintiutive.

This CR tries to fix and improve it.

The following problems have been identified and fixed with earlier
webrevs (as of http://cr.openjdk.java.net/~tschatzl/8006088/webrev.3):

- VM gives an error when InitialHeapSize > MaxHeapSize
- shrink NewSize and OldSize so that if MaxHeapSize is given, their sum
is below MaxHeapSize.
- automatically adapt minimum heap size if only InitialHeapSize is
given. This avoids getting "Incompatible minimum and initial heap sizes
specified" if only -XX:InitialHeapSize is specified with low values.
- also allow specification of -Xms0 (i.e. size >= 0, not size > 0); this
is a valid heap size specification, and means minimum/initial heap size
= OldSize + NewSize.
- test cases

The new additions for this webrev are as follows:

- implement the behavior shown in the table at
http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/XmsInitialHeapSizeErgo.html . This table also shows old behavior for comparison with the new behavior. Summarizing, this changeset fixes unexpected errors in the old behavior in the case when:   
  * -Xms0 is given,
  * only -XX:InitialHeapSize=0 is given (previously the resulting
initial heap size was OldSize + NewSize while now it applies normal
ergonomics), and
  * when setting -Xms to a "large" value and -XX:InitialHeapSize to
zero. (Only this issue had to be actually fixed in comparison to the
earlier webrev).
- add new jtreg tests for previously unverified behavior of that entire
table.
- improved testing for maximum heap sizing which now does not rely on a
hardcoded constant for aligning the expected value as the test case
retrieves the alignment value from the VM.

Bugs.sun.com:
http://bugs.sun.com/view_bug.do?bug_id=8006088

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-8006088

Testing:
jprt, manual invocation of all test cases

Hth,
Thomas





From thomas.schatzl at oracle.com  Thu Apr 11 16:38:22 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 11 Apr 2013 18:38:22 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size
	limit is exceeded
In-Reply-To: <51658F31.3000706@oracle.com>
References: <51625424.4050209@oracle.com> <1365605585.3428.27.camel@cirrus>
	<1365606657.3428.35.camel@cirrus> <1365607680.3428.42.camel@cirrus>
	<51658F31.3000706@oracle.com>
Message-ID: <1365698302.2573.5.camel@cirrus>

Hi,

On Wed, 2013-04-10 at 09:11 -0700, Tao Mao wrote:
> Hi Thomas,
> 
> The modification of TEST.ROOT is needed for passing jtreg test. I could 
> separate the testing code as a new CR but not sure if it's trivial.

Okay, thanks for the clarification.

I meant separating the TEST.ROOT change as it seems to have a more
global effect than the CR. However if others agree to add the change to
TEST.ROOT in this patch, fine with me. Additionally you already did the
jtreg test with the changed TEST.ROOT anyway.

I was only worried that it might trigger e.g. a failing test case.

Thanks,
Thomas




From john.cuthbertson at oracle.com  Thu Apr 11 18:36:09 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 11 Apr 2013 11:36:09 -0700
Subject: RFR: 8009032 - Implement evacuation info event
In-Reply-To: <5165C873.3010608@oracle.com>
References: <515D8864.6070209@oracle.com> <5164A6CE.6080104@oracle.com>
	<51651FFB.6040705@oracle.com> <5165C873.3010608@oracle.com>
Message-ID: <51670299.8090307@oracle.com>

Hi Jesper,

This looks good.

I was mistaken about G1CollectorPolicy::_bytes_copied_during_gc *not* 
including the occupancy of the retained old GC allocation region. It does.

Near the end of the pause we call release_gc_alloc_regions(). In that 
routine we release the current _old_gc_alloc_region:

> 4278   // If we have an old GC alloc region to release, we'll save it in
> 4279   // _retained_old_gc_alloc_region. If we don't
> 4280   // _retained_old_gc_alloc_region will become NULL. This is what we
> 4281   // want either way so no reason to check explicitly for either
> 4282   // condition.
> 4283   _retained_old_gc_alloc_region = _old_gc_alloc_region.release();

When we release this region:

> HeapRegion* G1AllocRegion::release() {
>   trace("releasing");
>   HeapRegion* alloc_region = _alloc_region;
>   retire(false /* fill_up */);
>   assert(_alloc_region == _dummy_region,
>          ar_ext_msg(this, "post-condition of retire()"));
>   _alloc_region = NULL;
>   trace("released");
>   return (alloc_region == _dummy_region) ? NULL : alloc_region;
> }

we retire the region via:

G1AllocRegion::release() -> G1AllocRegion::retire() -> 
OldGCAllocRegion::reire_region() -> 
G1CollectedHeap::retire_gc_alloc_region() -> 
G1CollectorPolicy::record_bytes_copied_during_gc()

which updates G1CollectorPolicy::_bytes_copied_during_gc.

Therefore, I don't think you need you need to have the 
_alloc_regions_used_before field in the EvacuationInfo struct or the 
related material. That should simplify a couple of things. Many apologies.

On a stylistic note, my preference would have been to have some kind of 
units in the field names, e.g. num_cset_regions (or cset_region_num), 
used_bytes_before, etc. But I can live with the current names.

JohnC

On 4/10/2013 1:15 PM, Jesper Wilhelmsson wrote:
> Hi,
>
> New webrev available here:
> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>
> All names are changed to reduce confusion.
> /Jesper
>
>
> Bengt Rutisson skrev 10/4/13 10:16 AM:
>>
>> Hi Jesper,
>>
>> This is better but I'm a bit confused about the data that we report.
>>
>> usedAllocRegionsBefore/used_alloc_regions_before
>> Does not seem to be the correct name. What you report here is the 
>> used bytes for
>> the one alloc region that we retained from the last GC.
>>
>> usedCSetAfter/used_collectionset_after
>> Does not seem to be the correct name. What you report is the used 
>> bytes for the
>> survivor regions. The old alloc regions are not included.
>>
>> usedAllocRegionsAfter/used_alloc_regions_after
>> Does not seem to be the correct name. What you report is the amount 
>> of bytes
>> that survived the collection. Either because it was copied (to alloc 
>> regions) or
>> because we got evacuation failure and it was left in place. This 
>> value also does
>> not include the value that you reported in 
>> "used_alloc_regions_before". I don't
>> think it should, but the current name kind of indicates that.
>>
>> regionsFreed/regions_freed
>> Does not seem to be the correct name. What you report is the number 
>> of regions
>> that had been freed just before the current region. I think the name 
>> may be
>> correct if you move the call to 
>> _evacuation_info.register_regions_freed() to
>> after the loop.
>>
>>
>> Code comments:
>>
>> g1CollectedHeap.cpp/hpp
>>
>> I would suggest to not have _evacuation_info as an instance variable in
>> G1CollectedHeap and instead have it as a local variable in
>> G1CollectedHeap::do_collection_pause_at_safepoint(). That would 
>> remove the need
>> for EvacuationInfo::reset().
>>
>>
>> Maybe it's better to inline the call to
>> _evacuation_info.register_collectionset_regions() inside to
>> g1_policy()->finalize_cset()?
>>
>>          g1_policy()->finalize_cset(target_pause_time_ms);
>> _evacuation_info.register_collectionset_regions(g1_policy()->cset_region_length()); 
>>
>>
>>
>> gcTrace.hpp
>>
>> Why did you move G1OldTracer to within "#ifndef SERIALGC" the other 
>> tracer are
>> not guarded by this unless they have to (as G1NewTracer)?
>>
>> I think it is better to forward declare the EvacuationInfo class than 
>> including
>> gc_implementation/g1/evacuationInfo.hpp since you only use 
>> EvacuationInfo*. (If
>> you decide to keep the include you need to move it in under #ifndef 
>> SERIALGC.)
>>
>>
>> evacuationInfo.hpp:
>> I don't think it needs this include:
>> #include "gc_implementation/g1/heapRegion.hpp"
>>
>> Why do you use += for all the setters? For the cases where you do 
>> accumulate
>> (like in G1CollectedHeap::free_collection_set()) I think it would be 
>> better to
>> accumulate in a local variable and then just call register once with 
>> the total.
>>
>> Bengt
>>
>>
>> On 4/10/13 1:39 AM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> Got some internal feedback (thanks Bengt!) and here is a new version:
>>>
>>> http://cr.openjdk.java.net/~jwilhelm/8009032/hotspot-webrev/
>>>
>>> Thanks,
>>> /Jesper
>>>
>>>
>>>
>>> Jesper Wilhelmsson skrev 4/4/13 4:04 PM:
>>>> Hi,
>>>>
>>>> I'm looking for a couple of reviews for this change.
>>>>
>>>> This is an tracing event with information about G1 
>>>> evacuation/compaction. It
>>>> contains the number of regions in from-space and to-space, how much 
>>>> data that
>>>> was used before and after, the number of bytes copied during the
>>>> evacuation/compaction, and how many regions that was completely 
>>>> freed during an
>>>> evacuation.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8009032/webrev/
>>>>
>>>>
>>>> The patch also contains a bunch of fixed typos in various comments 
>>>> nearby the
>>>> relevant changes. These may add some noise to the webrev, if you 
>>>> prefer to look
>>>> at the webrev without these changes a separate webrev is available 
>>>> here:
>>>>
>>>> Webrev without typo fixes:
>>>> http://cr.openjdk.java.net/~jwilhelm/8009032/webrev-no_typo_fix/
>>>>
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009032
>>>>
>>>> Thanks,
>>>> /Jesper
>>



From john.cuthbertson at oracle.com  Thu Apr 11 21:12:38 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Thu, 11 Apr 2013 21:12:38 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets
Message-ID: <20130411211252.316DC48221@hg.openjdk.java.net>

Changeset: 71013d764f6e
Author:    johnc
Date:      2013-04-10 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/71013d764f6e

8010780: G1: Eden occupancy/capacity output wrong after a full GC
Summary: Move the calculation and recording of eden capacity to the start of a GC and print a detailed heap transition for full GCs.
Reviewed-by: tschatzl, jmasa

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

Changeset: c0000f77bc6d
Author:    johnc
Date:      2013-04-11 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c0000f77bc6d

Merge

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



From christian.tornqvist at oracle.com  Tue Apr  9 11:00:20 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 9 Apr 2013 13:00:20 +0200
Subject: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace
	allocation	lock -- possible deadlock
In-Reply-To: <5163E2EC.8050409@oracle.com>
References: <5162CAE3.1020708@oracle.com>
	<5162D204.20904@oracle.com>	<5162F18C.6060602@oracle.com>
	<5163E2EC.8050409@oracle.com>
Message-ID: <042601ce3511$6ec42eb0$4c4c8c10$@tornqvist@oracle.com>

Hi Mikael,

Test looks good apart from two minor issues:

Spelling error:
43         throw new RuntimeException("Unalbe to load class file");

Don't use System.exit() in jtreg
(http://openjdk.java.net/jtreg/faq.html#question2.6):
120       System.exit(1);

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev-bounces at openjdk.java.net
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Mikael
Gerdin
Sent: den 9 april 2013 11:44
To: Leonid Mesnik
Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR (S/M) JDK-8010196 NPG: Internal Error: Metaspace allocation
lock -- possible deadlock

Good news!
I managed to write a regression test by adding a bit more dependencies every
iteration:

http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-regtest/webrev/

/Mikael


On 04/08/2013 06:34 PM, Mikael Gerdin wrote:
> Leonid,
>
> On 04/08/2013 04:19 PM, Leonid Mesnik wrote:
>> Mikael
>>
>> Is it possible to include regression test which reproduce problem?
>> (based on BigArityTest.java)
>
> I can't say I understand what BigArityTest does that makes it 
> introduce cross-CLD dependencies.
> I did write a test which does cause dependencies but I failed to make 
> it reproduce the problem, even though some of the dependencies were 
> added during a G1 concurrent mark cycle.
>
> /Mikael
>
>>
>> Leonid
>>
>> On 04/08/2013 05:49 PM, Mikael Gerdin wrote:
>>> Hi
>>>
>>> The problem is that when running the G1 garbage collector a call to 
>>> objArrayOopDesc::obj_at_put can in rare cases cause the G1 dirty 
>>> card queue buffer to fill up and this will cause G1 to take
>>> DirtyCardQ_CBL_mon/16 to return the full buffer and get a new one.
>>>
>>> Adding dependencies to a ClassLoaderData is currently protected by 
>>> the per-metaspace "Metaspace allocation lock"/5 (which protects more 
>>> than just allocations).
>>>
>>> Because I want to avoid messing around with the lock ordering I 
>>> suggest that we use an ObjectLocker on the _dependencies oop in 
>>> ClassLoaderData.
>>> _dependencies is a 2-element objArrayOop, in effect it's an ad-hoc 
>>> linked list of ClassLoaders/Classes which must be kept alive by this 
>>> CLD.
>>>
>>> Using an ObjectLocker on the head element of the linked list should 
>>> be at least as good as using the metaspace_lock(). There should not 
>>> be any new deadlock issues with VM mutexes since any application 
>>> thread could use a similar synchronized linked list construct.
>>>
>>> As a bonus I suggest that we factor out the dependency handling from 
>>> ClassLoaderData into a inner class: ClassLoaderData::Dependencies 
>>> and let Dependencies manage the head of the linked list by itself. 
>>> This should make it more clear that the dependency list is not 
>>> guarded by the metaspace lock anymore.
>>>
>>> Buglinks:
>>> https://jbs.oracle.com/bugs/browse/JDK-8010196
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010196
>>>
>>> Testing:
>>> default jprt run
>>> jdk/test/java/lang/invoke/BigArityTest.java (which could reproduce 
>>> the issue with -XX:+UseG1GC -XX:G1UpdateBufferSize=1)
>>>
>>> Webrevs:
>>> Incremental:
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-fix/webrev
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-factor-out/webr
>>> ev 
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0-rename/webrev
>>> Everything:
>>> http://cr.openjdk.java.net/~mgerdin/8010196/webrev.0/webrev
>>>
>>> Thanks
>>> /Mikael
>>
>>
>




From john.coomes at oracle.com  Fri Apr 12 04:03:25 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:03:25 +0000
Subject: hg: hsx/hotspot-gc: 9 new changesets
Message-ID: <20130412040326.A16C648250@hg.openjdk.java.net>

Changeset: 52d1b385a4ed
Author:    erikj
Date:      2013-04-04 09:24 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/52d1b385a4ed

8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure
Reviewed-by: tbell, alanb

! common/autoconf/bootcycle-spec.gmk.in
! common/autoconf/spec.gmk.in
! common/makefiles/Jprt.gmk
! common/makefiles/Main.gmk

Changeset: 2d4156e077fa
Author:    erikj
Date:      2013-04-04 09:25 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2d4156e077fa

8011372: Remove -p from cp in IdleCompilation.gmk
Reviewed-by: pliden, tbell

! common/makefiles/IdlCompilation.gmk

Changeset: 3b8ffb80db0f
Author:    erikj
Date:      2013-04-05 09:38 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/3b8ffb80db0f

8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar'
Reviewed-by: tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/MakeBase.gmk

Changeset: 653ff6bcf0b1
Author:    omajid
Date:      2013-04-08 14:07 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/653ff6bcf0b1

8011388: Support building zero and zeroshark with the new build
Reviewed-by: andrew, dholmes, erikj
Contributed-by: Omair Majid <omajid at redhat.com>, Roman Kennke <rkennke at redhat.com>

! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/jdk-options.m4
! common/autoconf/libraries.m4
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: 2f43964043c2
Author:    erikj
Date:      2013-04-09 09:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2f43964043c2

8006288: build-infra: Use solaris nm and not gnm on solaris
Reviewed-by: tbell

! common/autoconf/compare.sh.in
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: 2ef28c12d649
Author:    erikj
Date:      2013-04-09 09:45 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2ef28c12d649

8010465: Can't enable sjavac when building in jprt.
Reviewed-by: ohair, tbell

! common/makefiles/JavaCompilation.gmk
! common/makefiles/Jprt.gmk
! common/makefiles/MakeBase.gmk
! common/makefiles/MakeHelpers.gmk

Changeset: a09e9c9ca963
Author:    tbell
Date:      2013-04-09 13:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a09e9c9ca963

8011348: use of which in common/autoconf/autogen.sh is not portable
Reviewed-by: erikj, katleman, mduigou

! common/autoconf/autogen.sh

Changeset: 7fc358f59436
Author:    katleman
Date:      2013-04-09 15:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/7fc358f59436

Merge


Changeset: 44bc9bc4da4d
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/44bc9bc4da4d

Added tag jdk8-b85 for changeset 7fc358f59436

! .hgtags



From john.coomes at oracle.com  Fri Apr 12 04:03:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:03:30 +0000
Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b85 for changeset
	9583a6431596
Message-ID: <20130412040334.3182048251@hg.openjdk.java.net>

Changeset: 44a8ce4a759f
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/44a8ce4a759f

Added tag jdk8-b85 for changeset 9583a6431596

! .hgtags



From john.coomes at oracle.com  Fri Apr 12 04:03:39 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:03:39 +0000
Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b85 for changeset 41b50e2c5ea3
Message-ID: <20130412040356.D355F48252@hg.openjdk.java.net>

Changeset: ca71ec37b2ef
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/ca71ec37b2ef

Added tag jdk8-b85 for changeset 41b50e2c5ea3

! .hgtags



From john.coomes at oracle.com  Fri Apr 12 04:04:01 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:04:01 +0000
Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b85 for changeset
	8c0b6bccfe47
Message-ID: <20130412040409.741E848253@hg.openjdk.java.net>

Changeset: 26c840af7720
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/26c840af7720

Added tag jdk8-b85 for changeset 8c0b6bccfe47

! .hgtags



From john.coomes at oracle.com  Fri Apr 12 04:04:22 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:04:22 +0000
Subject: hg: hsx/hotspot-gc/jdk: 4 new changesets
Message-ID: <20130412040654.2C56F48254@hg.openjdk.java.net>

Changeset: e22961ea91bd
Author:    erikj
Date:      2013-04-05 09:39 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e22961ea91bd

8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar'
Reviewed-by: tbell

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CopySamples.gmk
! makefiles/GendataFontConfig.gmk
! makefiles/GensrcCharacterData.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcSwing.gmk
! makefiles/SignJars.gmk
! makefiles/Tools.gmk

Changeset: fddd158b872a
Author:    omajid
Date:      2013-04-08 14:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fddd158b872a

8011388: Support building zero and zeroshark with the new build
Reviewed-by: andrew, dholmes, erikj
Contributed-by: Omair Majid <omajid at redhat.com>, Roman Kennke <rkennke at redhat.com>

! makefiles/Profiles.gmk

Changeset: 296676d534c5
Author:    katleman
Date:      2013-04-09 15:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/296676d534c5

Merge


Changeset: 081327aac5be
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/081327aac5be

Added tag jdk8-b85 for changeset 296676d534c5

! .hgtags



From john.coomes at oracle.com  Fri Apr 12 04:09:09 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:09:09 +0000
Subject: hg: hsx/hotspot-gc/nashorn: Added tag jdk8-b85 for changeset
	e0378f0a50da
Message-ID: <20130412040912.DF2CB48256@hg.openjdk.java.net>

Changeset: aed0529f5f5d
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/aed0529f5f5d

Added tag jdk8-b85 for changeset e0378f0a50da

! .hgtags



From john.coomes at oracle.com  Fri Apr 12 04:08:50 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 04:08:50 +0000
Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b85 for changeset
	4a48f3173534
Message-ID: <20130412040904.E85A048255@hg.openjdk.java.net>

Changeset: 2c9acb17f41a
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2c9acb17f41a

Added tag jdk8-b85 for changeset 4a48f3173534

! .hgtags



From yumin.qi at oracle.com  Fri Apr 12 06:12:04 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 11 Apr 2013 23:12:04 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
Message-ID: <5167A5B4.4060100@oracle.com>

Hi,

   Can I have your inputs for the fix?
   webrev:

  http://cr.openjdk.java.net/~minqi/8010992/webrev/  <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>

   Bug:  8010992: Remove calls to global ::operator new[] and new
https://jbs.oracle.com/bugs/browse/JDK-8010992

Problem description:  Remove the usage of global operator ::new[] and 
::new. In hotspot debug build, disable the usage of global new[] and 
new.  Hotspot does not throw c++ exceptions, but it cannot prevent third 
party code to catch such exceptions.  By disabling use of global 
operator new[] and new, we constrain the exception disposal within 
hotspot. C++ classes (as same for structs) in hotspot have to either 
extends from CHeapObj or ResourceObj unless they are stack objects or 
values which have to be from StackObj or _ValueObj respectively.  Or 
they have to implement their own operator new[] or new.

Thanks
Yumin




From david.holmes at oracle.com  Fri Apr 12 08:46:52 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Apr 2013 18:46:52 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5167A5B4.4060100@oracle.com>
References: <5167A5B4.4060100@oracle.com>
Message-ID: <5167C9FC.5000902@oracle.com>

Hi Yumin,

This looks pretty good.

On 12/04/2013 4:12 PM, Yumin Qi wrote:
>    Can I have your inputs for the fix?
>    webrev:
>
>   http://cr.openjdk.java.net/~minqi/8010992/webrev/
> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>

src/share/vm/classfile/altHashing.cpp

Can these be directly stack-allocated arrays instead of C-Heap ?

---

allocation.cpp

672 // %% note this is causing a problem on solaris debug build. the global
673 // new is being called from jdk source and causing data corruption.
674 // 
src/share/native/sun/awt/font/fontmanager/textcache/hsMemory.cpp::hsSoftNew

Is this still an issue?

As a general comment do we need all the operator new[] additions?

---

allocation.inline.hpp

Can we reduce code duplication by changing, eg:

#ifdef ASSERT
     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
: CALLER_PC));
     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
     return p;
#else
     return (void *) AllocateHeap(size, F, (caller_pc != 0 ? caller_pc : 
CALLER_PC));
#endif

to

     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
: CALLER_PC));
#ifdef ASSERT
     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
#endif
     return p;

---

src/share/vm/memory/cardTableModRefBS.cpp

86   for (i = 0; i < max_covered_regions; i++) {
87     _covered[i].set_start(NULL)  ; _covered[i].set_word_size(0)  ;
88     _committed[i].set_start(NULL); _committed[i].set_word_size(0);
89   }

this appears to be a semantic change, which leads me to ask:

Given "new MemRegion[1]" vs NEW_C_HEAP_ARRAY(...,1,...) what are the 
array contents initialized to in each case?

---

src/share/vm/memory/cardTableRS.cpp

   68 CardTableRS::~CardTableRS() {
   69   if (_last_cur_val_in_gen) {
   70     // FREE_C_HEAP_ARRAY(jbyte, _last_cur_val_in_gen, mtInternal);
   71   }
   72 }

Was this an existing memory leak? I'm noticing that most uses of "new 
X[n]" don't have a corresponding delete!

But why is this commented out?

---

src/share/vm/runtime/handles.hpp

initialize_thread shouldn't need to be public. What is calling it?

---

src/share/vm/runtime/thread.cpp

These changes don't look right - why doesn't HandleMark extend one of 
the allocation base classes ?


Thanks,
David
-----

>    Bug:  8010992: Remove calls to global ::operator new[] and new
> https://jbs.oracle.com/bugs/browse/JDK-8010992
>
> Problem description:  Remove the usage of global operator ::new[] and
> ::new. In hotspot debug build, disable the usage of global new[] and
> new.  Hotspot does not throw c++ exceptions, but it cannot prevent third
> party code to catch such exceptions.  By disabling use of global
> operator new[] and new, we constrain the exception disposal within
> hotspot. C++ classes (as same for structs) in hotspot have to either
> extends from CHeapObj or ResourceObj unless they are stack objects or
> values which have to be from StackObj or _ValueObj respectively.  Or
> they have to implement their own operator new[] or new.
>
> Thanks
> Yumin
>
>


From kevin.walls at oracle.com  Fri Apr 12 10:46:20 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 12 Apr 2013 11:46:20 +0100
Subject: RFR: 8010514: G1: Concurrent mode failure tracing event
Message-ID: <5167E5FC.2090608@oracle.com>

Hi,

I'd like to get a review on this G1 event for hs24.  It offers a similar 
warning to the concurrent mode failure in CMS when the concurrent part 
of the collection (concurrent mark here in G1) aborts (and is an event 
fairly equivalent to seeing "concurrent-mark-abort" on the text log).

http://cr.openjdk.java.net/~kevinw/8010514/webrev/

Thanks
Kevin


From jesper.wilhelmsson at oracle.com  Fri Apr 12 14:08:25 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 12 Apr 2013 16:08:25 +0200
Subject: RFR: 8010514: G1: Concurrent mode failure tracing event
In-Reply-To: <5167E5FC.2090608@oracle.com>
References: <5167E5FC.2090608@oracle.com>
Message-ID: <51681559.2070606@oracle.com>

Looks good.
Ship it!
/Jesper

Kevin Walls skrev 12/4/13 12:46 PM:
> Hi,
>
> I'd like to get a review on this G1 event for hs24.  It offers a similar warning
> to the concurrent mode failure in CMS when the concurrent part of the collection
> (concurrent mark here in G1) aborts (and is an event fairly equivalent to seeing
> "concurrent-mark-abort" on the text log).
>
> http://cr.openjdk.java.net/~kevinw/8010514/webrev/
>
> Thanks
> Kevin


From pavel.punegov at oracle.com  Fri Apr 12 10:14:44 2013
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Fri, 12 Apr 2013 14:14:44 +0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5167A5B4.4060100@oracle.com>
References: <5167A5B4.4060100@oracle.com>
Message-ID: <2008251.VQ1tnDndxf@trisuli>

Yumin,

Should the bug [*] be closed as a duplicate of this as you changed the failing 
part?

Also, do you have a JPRT build with your changes? Was there any testing done?

[*] JDK-7045180 unexpected C++ exception in ObjectSynchronizer::inflate
( https://jbs.oracle.com/bugs/browse/JDK-7045180 )


On Thursday 11 April 2013 23:12:04 Yumin Qi wrote:
> Hi,
> 
>    Can I have your inputs for the fix?
>    webrev:
> 
>   http://cr.openjdk.java.net/~minqi/8010992/webrev/ 
> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
> 
>    Bug:  8010992: Remove calls to global ::operator new[] and new
> https://jbs.oracle.com/bugs/browse/JDK-8010992
> 
> Problem description:  Remove the usage of global operator ::new[] and
> 
> ::new. In hotspot debug build, disable the usage of global new[] and
> 
> new.  Hotspot does not throw c++ exceptions, but it cannot prevent third
> party code to catch such exceptions.  By disabling use of global
> operator new[] and new, we constrain the exception disposal within
> hotspot. C++ classes (as same for structs) in hotspot have to either
> extends from CHeapObj or ResourceObj unless they are stack objects or
> values which have to be from StackObj or _ValueObj respectively.  Or
> they have to implement their own operator new[] or new.
> 
> Thanks
> Yumin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130412/12b5b59e/attachment.htm>

From yumin.qi at oracle.com  Fri Apr 12 17:30:32 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 10:30:32 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5167C9FC.5000902@oracle.com>
References: <5167A5B4.4060100@oracle.com> <5167C9FC.5000902@oracle.com>
Message-ID: <516844B8.1030805@oracle.com>

Thanks, David

On 4/12/2013 1:46 AM, David Holmes wrote:
> Hi Yumin,
>
> This looks pretty good.
>
> On 12/04/2013 4:12 PM, Yumin Qi wrote:
>>    Can I have your inputs for the fix?
>>    webrev:
>>
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev/
>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>
> src/share/vm/classfile/altHashing.cpp
>
> Can these be directly stack-allocated arrays instead of C-Heap ?
>
Yes
> ---
>
> allocation.cpp
>
> 672 // %% note this is causing a problem on solaris debug build. the 
> global
> 673 // new is being called from jdk source and causing data corruption.
> 674 // 
> src/share/native/sun/awt/font/fontmanager/textcache/hsMemory.cpp::hsSoftNew
>
> Is this still an issue?
>
> As a general comment do we need all the operator new[] additions?
>
No longer an issue, the code mentioned in jdk has been removed.
> ---
>
> allocation.inline.hpp
>
> Can we reduce code duplication by changing, eg:
>
> #ifdef ASSERT
>     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
> : CALLER_PC));
>     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
>     return p;
> #else
>     return (void *) AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
> : CALLER_PC));
> #endif
>
> to
>
>     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
> : CALLER_PC));
> #ifdef ASSERT
>     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
> #endif
>     return p;
>
Yes, that is better.
> ---
>
> src/share/vm/memory/cardTableModRefBS.cpp
>
> 86   for (i = 0; i < max_covered_regions; i++) {
> 87     _covered[i].set_start(NULL)  ; _covered[i].set_word_size(0)  ;
> 88     _committed[i].set_start(NULL); _committed[i].set_word_size(0);
> 89   }
>
> this appears to be a semantic change, which leads me to ask:
>
> Given "new MemRegion[1]" vs NEW_C_HEAP_ARRAY(...,1,...) what are the 
> array contents initialized to in each case?
>
Ii should be changed to use NEW_C_HEAP_OBJECT, but MemRegion is a 
_ValueObj which should not be new'ed.   The loop here is just doing that 
what the default ctor do.
> ---
>
> src/share/vm/memory/cardTableRS.cpp
>
>   68 CardTableRS::~CardTableRS() {
>   69   if (_last_cur_val_in_gen) {
>   70     // FREE_C_HEAP_ARRAY(jbyte, _last_cur_val_in_gen, mtInternal);
>   71   }
>   72 }
>
> Was this an existing memory leak? I'm noticing that most uses of "new 
> X[n]" don't have a corresponding delete!
>
> But why is this commented out?
That is a mistake, I will uncomment it back.
>
> ---
>
> src/share/vm/runtime/handles.hpp
>
> initialize_thread shouldn't need to be public. What is calling it?
>
> ---
>
> src/share/vm/runtime/thread.cpp
>
> These changes don't look right - why doesn't HandleMark extend one of 
> the allocation base classes ?
>
The HandleMark should be an StackObj, but we need to create it in heap 
in thread creation. This part is confusing me too.  This is the only 
place to create it in heap, all the usage is a StackObj.

Thanks
Yumin
>
> Thanks,
> David
> -----
>
>>    Bug:  8010992: Remove calls to global ::operator new[] and new
>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>
>> Problem description:  Remove the usage of global operator ::new[] and
>> ::new. In hotspot debug build, disable the usage of global new[] and
>> new.  Hotspot does not throw c++ exceptions, but it cannot prevent third
>> party code to catch such exceptions.  By disabling use of global
>> operator new[] and new, we constrain the exception disposal within
>> hotspot. C++ classes (as same for structs) in hotspot have to either
>> extends from CHeapObj or ResourceObj unless they are stack objects or
>> values which have to be from StackObj or _ValueObj respectively.  Or
>> they have to implement their own operator new[] or new.
>>
>> Thanks
>> Yumin
>>
>>



From yumin.qi at oracle.com  Fri Apr 12 18:51:43 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 11:51:43 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <2008251.VQ1tnDndxf@trisuli>
References: <5167A5B4.4060100@oracle.com> <2008251.VQ1tnDndxf@trisuli>
Message-ID: <516857BF.4000802@oracle.com>

Pavel,

On 4/12/2013 3:14 AM, Pavel Punegov wrote:
>
> Yumin,
>
> Should the bug [*] be closed as a duplicate of this as you changed the 
> failing part?
>
Yes.
>
> Also, do you have a JPRT build with your changes? Was there any 
> testing done?
>
Not final, will send you a link when done.

Thanks
Yumin
>
> [*] JDK-7045180 unexpected C++ exception in ObjectSynchronizer::inflate
>
> ( https://jbs.oracle.com/bugs/browse/JDK-7045180 )
>
> On Thursday 11 April 2013 23:12:04 Yumin Qi wrote:
>
> > Hi,
>
> >
>
> > Can I have your inputs for the fix?
>
> > webrev:
>
> >
>
> > http://cr.openjdk.java.net/~minqi/8010992/webrev/
>
> > <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>
> >
>
> > Bug: 8010992: Remove calls to global ::operator new[] and new
>
> > https://jbs.oracle.com/bugs/browse/JDK-8010992
>
> >
>
> > Problem description: Remove the usage of global operator ::new[] and
>
> >
>
> > ::new. In hotspot debug build, disable the usage of global new[] and
>
> >
>
> > new. Hotspot does not throw c++ exceptions, but it cannot prevent third
>
> > party code to catch such exceptions. By disabling use of global
>
> > operator new[] and new, we constrain the exception disposal within
>
> > hotspot. C++ classes (as same for structs) in hotspot have to either
>
> > extends from CHeapObj or ResourceObj unless they are stack objects or
>
> > values which have to be from StackObj or _ValueObj respectively. Or
>
> > they have to implement their own operator new[] or new.
>
> >
>
> > Thanks
>
> > Yumin
>

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

From john.cuthbertson at oracle.com  Fri Apr 12 19:05:21 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 12 Apr 2013 12:05:21 -0700
Subject: RFR: 8010514: G1: Concurrent mode failure tracing event
In-Reply-To: <5167E5FC.2090608@oracle.com>
References: <5167E5FC.2090608@oracle.com>
Message-ID: <51685AF1.9010601@oracle.com>

Hi Kevin,

Looks fine.

JohnC

On 4/12/2013 3:46 AM, Kevin Walls wrote:
> Hi,
>
> I'd like to get a review on this G1 event for hs24.  It offers a 
> similar warning to the concurrent mode failure in CMS when the 
> concurrent part of the collection (concurrent mark here in G1) aborts 
> (and is an event fairly equivalent to seeing "concurrent-mark-abort" 
> on the text log).
>
> http://cr.openjdk.java.net/~kevinw/8010514/webrev/
>
> Thanks
> Kevin



From yumin.qi at oracle.com  Fri Apr 12 21:07:03 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 14:07:03 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5168482F.6040607@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
Message-ID: <51687777.1070500@oracle.com>

After take feedback and modify, new webrev

http://cr.openjdk.java.net/~minqi/8010992/webrev1 
<http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>



Thanks
Yumin

On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
> .
>>> cardTableModRefBS.cpp
>>>   #87 and #88, why set_start(NULL) are needed?
>>>
>> This is default constructor does, here just copy that code. Since we 
>> did not call constructor by using this MACRO. It is a _ValueObj, 
>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which 
>> will call ctors.
> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what 
> allocation.hpp #618 does.
>
> Thanks,
>
> -Zhengyu
>
>
>>> carTableRS.cpp
>>>   #70, why it is commented out? If so, you don't need the dstor
>>>
>>>
>> See reply to David H.
>>
>>
>> Thanks
>> Yumin
>>> -Zhengyu
>>>
>>>
>>>
>>>
>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>> Hi,
>>>>
>>>>   Can I have your inputs for the fix?
>>>>   webrev:
>>>>
>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/ 
>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>
>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>
>>>> Problem description:  Remove the usage of global operator ::new[] 
>>>> and ::new. In hotspot debug build, disable the usage of global 
>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it 
>>>> cannot prevent third party code to catch such exceptions.  By 
>>>> disabling use of global operator new[] and new, we constrain the 
>>>> exception disposal within hotspot. C++ classes (as same for 
>>>> structs) in hotspot have to either extends from CHeapObj or 
>>>> ResourceObj unless they are stack objects or values which have to 
>>>> be from StackObj or _ValueObj respectively.  Or they have to 
>>>> implement their own operator new[] or new.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>
>>
>



From coleen.phillimore at oracle.com  Fri Apr 12 21:48:52 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 12 Apr 2013 17:48:52 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <51687777.1070500@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com>
Message-ID: <51688144.20204@oracle.com>


Yumin,  I think this looks really good.   One comment:

thread.cpp

You allocate the HandleMark with mtThread and free it with mtInternal.

There are some other mtInternal's that you added that maybe Zhengyu has 
a better idea about.

Thanks,
Coleen


On 4/12/2013 5:07 PM, Yumin Qi wrote:
> After take feedback and modify, new webrev
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev1 
> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>
>
>
> Thanks
> Yumin
>
> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>> .
>>>> cardTableModRefBS.cpp
>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>
>>> This is default constructor does, here just copy that code. Since we 
>>> did not call constructor by using this MACRO. It is a _ValueObj, 
>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which 
>>> will call ctors.
>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what 
>> allocation.hpp #618 does.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>>> carTableRS.cpp
>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>
>>>>
>>> See reply to David H.
>>>
>>>
>>> Thanks
>>> Yumin
>>>> -Zhengyu
>>>>
>>>>
>>>>
>>>>
>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>> Hi,
>>>>>
>>>>>   Can I have your inputs for the fix?
>>>>>   webrev:
>>>>>
>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/ 
>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>
>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>
>>>>> Problem description:  Remove the usage of global operator ::new[] 
>>>>> and ::new. In hotspot debug build, disable the usage of global 
>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it 
>>>>> cannot prevent third party code to catch such exceptions.  By 
>>>>> disabling use of global operator new[] and new, we constrain the 
>>>>> exception disposal within hotspot. C++ classes (as same for 
>>>>> structs) in hotspot have to either extends from CHeapObj or 
>>>>> ResourceObj unless they are stack objects or values which have to 
>>>>> be from StackObj or _ValueObj respectively.  Or they have to 
>>>>> implement their own operator new[] or new.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>
>>>
>>
>



From yumin.qi at oracle.com  Fri Apr 12 22:47:42 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 15:47:42 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <51688144.20204@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <51688144.20204@oracle.com>
Message-ID: <51688F0E.2030703@oracle.com>

Coleen, Thanks  for review, will change that.

Yumin

On 4/12/2013 2:48 PM, Coleen Phillimore wrote:
>
> Yumin,  I think this looks really good.   One comment:
>
> thread.cpp
>
> You allocate the HandleMark with mtThread and free it with mtInternal.
>
> There are some other mtInternal's that you added that maybe Zhengyu 
> has a better idea about.
>
> Thanks,
> Coleen
>
>
> On 4/12/2013 5:07 PM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1 
>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since 
>>>> we did not call constructor by using this MACRO. It is a _ValueObj, 
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which 
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what 
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/ 
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[] 
>>>>>> and ::new. In hotspot debug build, disable the usage of global 
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it 
>>>>>> cannot prevent third party code to catch such exceptions.  By 
>>>>>> disabling use of global operator new[] and new, we constrain the 
>>>>>> exception disposal within hotspot. C++ classes (as same for 
>>>>>> structs) in hotspot have to either extends from CHeapObj or 
>>>>>> ResourceObj unless they are stack objects or values which have to 
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to 
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Fri Apr 12 23:04:05 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 12 Apr 2013 16:04:05 -0700
Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter
	functions cause large young GC regressions
In-Reply-To: <51562FB7.9010609@oracle.com>
References: <515271FB.9090203@oracle.com> <51562FB7.9010609@oracle.com>
Message-ID: <516892E5.9030105@oracle.com>

This is the promised semantic changes for the code review.  Whereas
the original set of changes only maintained a running sum for the
capacity of all the space for metadata, this added a running sum
for the used space allocated and holding metadata.

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

This is an incremental webrev based on the name change webrev
(webrev.00_1) below.  A complete webrev with all changes will
be published after comments for this have been digested.

Thanks.

Jon

On 3/29/2013 5:20 PM, Jon Masamitsu wrote:
> Ths webrev has mostly name changes suggested by the code
> review comments.  There are additional changes coming that
> relate to semantic changes suggested by the code review.
>
> This was created by deleting some of the suggested semantic
> changes so will not compile.  The next webrev will be relative
> to this one so you won't have to look at the name changes when
> looking and the semantic changes.
>
> Ignore the block comment about chunk accounting at the
> beginning of metaspace.cpp.  That will be updated or deleted
> in the next webrev.
>
> The deletion of some dead code is included in this webrev
> (limited number of lines).
>
> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00_1/
>
> Thanks.
>
> Jon
>
> On 3/26/2013 9:13 PM, Jon Masamitsu wrote:
>>
>> Replace the use of a method that calculated the total capacity of
>> the Metaspaces by iterating over all the Metaspaces by maintaining
>> the sum of Metaspace capacities as the Metachunks are
>> allocated to each Metaspace.  Also maintain a sum for each
>> Metaspace as the Metachunks are allocated to that Metaspace.
>>
>> Change should_expand() and compute_new_space() to
>> calculate quantities in bytes.
>>
>> Remove calls to methods that calculated totals for
>> "used" and "free" by iterating over the Metaspaces
>> in product mode.  In some cases substitute the use
>> of capacity for used.
>>
>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/
>>
>> Thanks.
>>
>> Jon
>



From john.cuthbertson at oracle.com  Sat Apr 13 01:15:25 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Fri, 12 Apr 2013 18:15:25 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <516598D3.1020809@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com>
Message-ID: <5168B1AD.7060302@oracle.com>

Hi Tao,

This looks OK to me.

I can see what Thomas is saying though. All of the checks involve 
something like:

total += some_value;
if (total < some_value) {
   // We must have overflowed
   vm_exit(...);
}

So a function in CollectedHeap (the base class of SharedHeap and 
ParallelScavengeHeap) might make sense. For example:

total_reserved = 0;
total_reserved = add_and_verify_no_overflow(total_reserved, max_heap_size);
total_reserved = add_and_verify_no_overflow(total_reserved, max_perm_size);

Where the function is:

size_t add_and_verify_no_overflow(size_t x, size_t y) {
   const char* msg = "...";
   x += y;
   if (x < y) {
     vm_exit(msg);
   }
   return x;
}

But I can live with your current changes.

JohnC

On 4/10/2013 9:52 AM, Tao Mao wrote:
> Hi Bengt,
>
> Thank you for reviewing. A new webrev is updated.
> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>
> Cheers,
> Tao
>
> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>
>> Hi Tao,
>>
>> This change looks good. Thanks for adding the JTReg test, it looks good!
>>
>> One minor nit:
>>
>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>> HeapRegion::GrainBytes)" in a local variable rather than duplicating 
>> the calculation.
>>
>> Thanks,
>> Bengt
>>
>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>> 6761744 Hotspot crashes if process size limit is exceeded
>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>
>>> changeset:
>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>
>>> It provides for 32-bit builds a preventive check of the size of "the 
>>> object heap + perm gen" before reserving VM memory. The total size 
>>> should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, 
>>> the total doesn't make sense and, what's worse, overflow occurs. It 
>>> will consequentially trigger anther error of memory access 
>>> violation, which was not protected.
>>>
>>> jtreg testing java code is also written, checking both 32-bit and 
>>> (trivially) 64-bit builds.
>>>
>>> testing:
>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>> builds of 32-bit and 64-bit. All passed.
>>>
>>> Needs JPRT test when pushing.
>>

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

From david.holmes at oracle.com  Mon Apr 15 06:07:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Apr 2013 16:07:30 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <51687777.1070500@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com>
Message-ID: <516B9922.4050306@oracle.com>

Hi Yumin,

On 13/04/2013 7:07 AM, Yumin Qi wrote:
> After take feedback and modify, new webrev
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev1
> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>

I still find the HandleMark changes unsatisfactory. The CHeap allocated 
HandleMark in the Thread() constructor is a bit of a hack. HandleMarks 
should be stack-allocated. Plus we seem to leak that CHeap allocated 
HandleMark as we don't keep any pointer to it! I think this needs to be 
re-visited, but as a separate CR.

---

allocation.hpp:

If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's before 
deallocating ?

---

src/share/vm/utilities/quickSort.cpp

Why does only Solaris need the allocation headers included ?? I would 
expect all platforms to need to the same headers here.

Thanks,
David

>
>
> Thanks
> Yumin
>
> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>> .
>>>> cardTableModRefBS.cpp
>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>
>>> This is default constructor does, here just copy that code. Since we
>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>> will call ctors.
>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>> allocation.hpp #618 does.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>>> carTableRS.cpp
>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>
>>>>
>>> See reply to David H.
>>>
>>>
>>> Thanks
>>> Yumin
>>>> -Zhengyu
>>>>
>>>>
>>>>
>>>>
>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>> Hi,
>>>>>
>>>>>   Can I have your inputs for the fix?
>>>>>   webrev:
>>>>>
>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>
>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>
>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>> disabling use of global operator new[] and new, we constrain the
>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>> ResourceObj unless they are stack objects or values which have to
>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>> implement their own operator new[] or new.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>
>>>
>>
>


From erik.helin at oracle.com  Mon Apr 15 07:01:02 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 15 Apr 2013 09:01:02 +0200
Subject: RFR (S): 8012102: CollectedHeap::ensure_parsability is not always
	called during heap inspection
Message-ID: <516BA5AE.2090201@oracle.com>

Hi all,

this change fixes a bad refactoring. The method 
CollectedHeap::ensure_parsability must always be called prior to doing 
performing a heap inspection (to be able to traverse TLABs).

A previous change refactored the code so that the method was only called 
if a full GC was requested before the heap inspection.

Webrev:
http://cr.openjdk.java.net/~ehelin/8012102/webrev.00/

Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012102

Thanks,
Erik



From mikael.gerdin at oracle.com  Mon Apr 15 08:30:32 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 15 Apr 2013 10:30:32 +0200
Subject: RFR (S): 8012102: CollectedHeap::ensure_parsability is not always
	called during heap inspection
In-Reply-To: <516BA5AE.2090201@oracle.com>
References: <516BA5AE.2090201@oracle.com>
Message-ID: <516BBAA8.9040906@oracle.com>

Erik,

On 2013-04-15 09:01, Erik Helin wrote:
> Hi all,
>
> this change fixes a bad refactoring. The method
> CollectedHeap::ensure_parsability must always be called prior to doing
> performing a heap inspection (to be able to traverse TLABs).
>
> A previous change refactored the code so that the method was only called
> if a full GC was requested before the heap inspection.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8012102/webrev.00/

This looks good,
can you please update the comment about calling ensure_parsability to 
mention that the call is also needed even if _full_gc is not set.
That will make the entire change self-explanatory.

I'm fine with you changing the comment and pushing without sending out a 
new webrev.

/Mikael

>
> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012102
>
> Thanks,
> Erik
>


From bengt.rutisson at oracle.com  Mon Apr 15 08:37:56 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 15 Apr 2013 10:37:56 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <5168B1AD.7060302@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
Message-ID: <516BBC64.6060509@oracle.com>


Hi Tao,

I agree with John. The changes look fine and I'm ok with them. But it 
would look nicer to add the CollectedHeap::add_and_verify_no_overflow() 
method.

Also, regarding the test, a couple of minor things.

First, with the new naming convention I think the test should be called 
something like:

test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java

Then I think you can reduce the code duplication a bit. You create the 
same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit cases. So 
maybe it could look like this instead:

public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
   public static void main(String args[]) throws Exception {
     ProcessBuilder pb =
ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
"-Xmx3072m",
"-XX:MaxPermSize=1024m",
"-version");
     OutputAnalyzer output = new OutputAnalyzer(pb.start());

     String dataModel = System.getProperty("sun.arch.data.model");
     if (dataModel.equals("32")) {
       output.shouldContain("The size of the object heap + perm gen 
exceeds the maximum representable size");
       if (output.getExitValue() == 0) {
         throw new RuntimeException("Not expected to get exit value 0");
       }
     } else if (dataModel.equals("64")) {
       output.shouldHaveExitValue(0);
     }
   }
}

There is also a small bug in the test. If you run JTreg without passing 
any vmoptions the test will fail. The reason is that 
System.getProperty("test.vm.opts") will evaluate to the empty string. 
This will be passed as the first argument to the Java process, which 
will assume that this is the class name. So, it fails to start because 
it can't load the class <empty string>.

To reproduce the problem use this command line:

java  -jar <path_to_jtreg>/lib/jtreg.jar 
test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java

I guess the fix is to check that System.getProperty("test.vm.opts") is 
not empty before passing it on to createJavaProcessBuilder().

Thanks,
Bengt

On 4/13/13 3:15 AM, John Cuthbertson wrote:
> Hi Tao,
>
> This looks OK to me.
>
> I can see what Thomas is saying though. All of the checks involve 
> something like:
>
> total += some_value;
> if (total < some_value) {
>   // We must have overflowed
>   vm_exit(...);
> }
>
> So a function in CollectedHeap (the base class of SharedHeap and 
> ParallelScavengeHeap) might make sense. For example:
>
> total_reserved = 0;
> total_reserved = add_and_verify_no_overflow(total_reserved, 
> max_heap_size);
> total_reserved = add_and_verify_no_overflow(total_reserved, 
> max_perm_size);
>
> Where the function is:
>
> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>   const char* msg = "...";
>   x += y;
>   if (x < y) {
>     vm_exit(msg);
>   }
>   return x;
> }
>
> But I can live with your current changes.
>
> JohnC
>
> On 4/10/2013 9:52 AM, Tao Mao wrote:
>> Hi Bengt,
>>
>> Thank you for reviewing. A new webrev is updated.
>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>
>> Cheers,
>> Tao
>>
>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>
>>> Hi Tao,
>>>
>>> This change looks good. Thanks for adding the JTReg test, it looks good!
>>>
>>> One minor nit:
>>>
>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>> HeapRegion::GrainBytes)" in a local variable rather than duplicating 
>>> the calculation.
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>
>>>> changeset:
>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>
>>>> It provides for 32-bit builds a preventive check of the size of 
>>>> "the object heap + perm gen" before reserving VM memory. The total 
>>>> size should not exceed 4096MB (i.e. 4GB) for 32-bit builds; 
>>>> otherwise, the total doesn't make sense and, what's worse, overflow 
>>>> occurs. It will consequentially trigger anther error of memory 
>>>> access violation, which was not protected.
>>>>
>>>> jtreg testing java code is also written, checking both 32-bit and 
>>>> (trivially) 64-bit builds.
>>>>
>>>> testing:
>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>> builds of 32-bit and 64-bit. All passed.
>>>>
>>>> Needs JPRT test when pushing.
>>>
>

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

From stefan.karlsson at oracle.com  Mon Apr 15 10:47:45 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 15 Apr 2013 12:47:45 +0200
Subject: RFR (S): 8012102: CollectedHeap::ensure_parsability is not always
	called during heap inspection
In-Reply-To: <516BA5AE.2090201@oracle.com>
References: <516BA5AE.2090201@oracle.com>
Message-ID: <516BDAD1.9030506@oracle.com>

On 04/15/2013 09:01 AM, Erik Helin wrote:
> Hi all,
>
> this change fixes a bad refactoring. The method 
> CollectedHeap::ensure_parsability must always be called prior to doing 
> performing a heap inspection (to be able to traverse TLABs).
>
> A previous change refactored the code so that the method was only 
> called if a full GC was requested before the heap inspection.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8012102/webrev.00/

The revert looks good.

I find it odd that we call ensure_parsability() before the full gc 
instead of directly before the heap_inspection. But that's what the code 
looked before your previous changes.

thanks,
StefanK

> Bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012102
>
> Thanks,
> Erik
>



From sirinath at sakrio.com  Sun Apr 14 10:58:09 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Sun, 14 Apr 2013 16:28:09 +0530
Subject: Annotation / API to mark finalise and / or GC
Message-ID: <CAAfFNYHTf5RA4Ye8EFvtt9xVv+j37Rj4PmQOhg67uTOFCFYPgA@mail.gmail.com>

Hi,

In moving towards a more predictable GC I like to suggest that:

   1. make available an interface to finalise and delete and delete without
   finalise object pausing on the thread that calls the API / specific thread
   pool or an attached thread / executor / scheduled executor / java GC thread
   2. add an annotation to mark for immediate delete after null assignment
   or exiting block or last use pausing the last referencing thread or java GC
   thread

Suminda
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130414/3c817cc1/attachment.htm>

From sirinath at sakrio.com  Sun Apr 14 11:06:19 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Sun, 14 Apr 2013 16:36:19 +0530
Subject: Annotation / API to mark finalise and / or GC
In-Reply-To: <CAAfFNYHTf5RA4Ye8EFvtt9xVv+j37Rj4PmQOhg67uTOFCFYPgA@mail.gmail.com>
References: <CAAfFNYHTf5RA4Ye8EFvtt9xVv+j37Rj4PmQOhg67uTOFCFYPgA@mail.gmail.com>
Message-ID: <CAAfFNYFRWqeEQYftn+stRxwybQWWGtM7Wb3s06btsJo3my9LGA@mail.gmail.com>

Also ability to specify additional GC threads / threadpool / executors
which has access to GC API for program to manage the GC process
and fallback to default GC if this is not going as intended
(memory pressure / large number of uncollected objects / etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130414/0161a17f/attachment.htm>

From sirinath at sakrio.com  Sun Apr 14 11:09:58 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Sun, 14 Apr 2013 16:39:58 +0530
Subject: API Control of GC Sub System
Message-ID: <CAAfFNYHDNNo6AXWXJx6OL4isXHGzZM5Kuq_pneOT_FGouGtA1w@mail.gmail.com>

Hi,

Command line GC options is not the best way to handle the GC options. The
program should have control on what GC system to also register
and unregister GC subsystems.

Suminda
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130414/7859ec0d/attachment.htm>

From erik.helin at oracle.com  Mon Apr 15 14:47:59 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 15 Apr 2013 16:47:59 +0200
Subject: RFR (S): 8012102: CollectedHeap::ensure_parsability is not always
	called during heap inspection
In-Reply-To: <516BDAD1.9030506@oracle.com>
References: <516BA5AE.2090201@oracle.com> <516BDAD1.9030506@oracle.com>
Message-ID: <516C131F.10201@oracle.com>

On 04/15/2013 12:47 PM, Stefan Karlsson wrote:
> On 04/15/2013 09:01 AM, Erik Helin wrote:
>> Hi all,
>>
>> this change fixes a bad refactoring. The method
>> CollectedHeap::ensure_parsability must always be called prior to doing
>> performing a heap inspection (to be able to traverse TLABs).
>>
>> A previous change refactored the code so that the method was only
>> called if a full GC was requested before the heap inspection.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8012102/webrev.00/
>
> The revert looks good.

Thanks!

On 04/15/2013 12:47 PM, Stefan Karlsson wrote:
> I find it odd that we call ensure_parsability() before the full gc
> instead of directly before the heap_inspection. But that's what the code
> looked before your previous changes.

Agree, it would be good look into as part of a future change.

Thanks,
Erik

> thanks,
> StefanK
>
>> Bug:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012102
>>
>> Thanks,
>> Erik
>>
>



From erik.helin at oracle.com  Mon Apr 15 14:48:24 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 15 Apr 2013 16:48:24 +0200
Subject: RFR (S): 8012102: CollectedHeap::ensure_parsability is not always
	called during heap inspection
In-Reply-To: <516BBAA8.9040906@oracle.com>
References: <516BA5AE.2090201@oracle.com> <516BBAA8.9040906@oracle.com>
Message-ID: <516C1338.60802@oracle.com>

On 04/15/2013 10:30 AM, Mikael Gerdin wrote:
> Erik,
>
> On 2013-04-15 09:01, Erik Helin wrote:
>> Hi all,
>>
>> this change fixes a bad refactoring. The method
>> CollectedHeap::ensure_parsability must always be called prior to doing
>> performing a heap inspection (to be able to traverse TLABs).
>>
>> A previous change refactored the code so that the method was only called
>> if a full GC was requested before the heap inspection.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8012102/webrev.00/
>
> This looks good,
> can you please update the comment about calling ensure_parsability to
> mention that the call is also needed even if _full_gc is not set.
> That will make the entire change self-explanatory.

Sure, will do.

On 04/15/2013 10:30 AM, Mikael Gerdin wrote:
> I'm fine with you changing the comment and pushing without sending out a
> new webrev.

Thanks!
Erik

> /Mikael
>
>>
>> Bug:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012102
>>
>> Thanks,
>> Erik
>>



From yumin.qi at oracle.com  Mon Apr 15 17:01:39 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 15 Apr 2013 10:01:39 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516C3273.1040003@oracle.com>

David,

On 4/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>
I agree, will file a separate CR for this problem to be fixed.
> ---
>
> allocation.hpp:
>
> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
> before deallocating ?
>
In fact, CardTableRS and CardTableModRefBS are only created once when GC 
flavor specified. It will be cleaned at JVM exit, this is why there is 
no memory leak. To keep a better coding practice, I will add 
FREE_C_HEAP_OBJECT_ARRAY to call dtos, also to free other allocated 
arrays during ctos called.

> ---
>
> src/share/vm/utilities/quickSort.cpp
>
> Why does only Solaris need the allocation headers included ?? I would 
> expect all platforms to need to the same headers here.
>
This is due to SunStudio compilation setting. It will issue error on 
solaris like:

src/share/vm/utilities/quickSort.cpp", line 192: Error: The function 
"AllocateHeap" must have a prototype.

in precompiled.hpp:

// Precompiled headers are turned off for Sun Studion,
// or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles.

#ifndef DONT_USE_PRECOMPILED_HEADER

I could add the including for all platforms, since it will be excluded 
by other platforms except for solaris --- precompiled.hpp already 
includes those two files. Adding #ifdef SOLARIS here to indicate they 
are only needed for Solaris.

I will send new webrev out.

Thanks
Yumin


> Thanks,
> David
>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since we
>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>



From yumin.qi at oracle.com  Mon Apr 15 17:41:28 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 15 Apr 2013 10:41:28 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516C3BC8.2040001@oracle.com>

new webrev at:

http://cr.openjdk.java.net/~minqi/8010992/webrev2

Can I have a review from GC team for this change?

Thanks
Yumin

On 4/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>
> ---
>
> allocation.hpp:
>
> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
> before deallocating ?
>
> ---
>
> src/share/vm/utilities/quickSort.cpp
>
> Why does only Solaris need the allocation headers included ?? I would 
> expect all platforms to need to the same headers here.
>
> Thanks,
> David
>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since we
>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>



From david.holmes at oracle.com  Mon Apr 15 23:03:32 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 09:03:32 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C3273.1040003@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3273.1040003@oracle.com>
Message-ID: <516C8744.3030601@oracle.com>

On 16/04/2013 3:01 AM, Yumin Qi wrote:
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>> before deallocating ?
>>
> In fact, CardTableRS and CardTableModRefBS are only created once when GC
> flavor specified. It will be cleaned at JVM exit, this is why there is
> no memory leak. To keep a better coding practice, I will add
> FREE_C_HEAP_OBJECT_ARRAY to call dtos, also to free other allocated
> arrays during ctos called.

Thanks. Just because those uses are not freed it doesn't mean this won't 
get used for something else.

>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would
>> expect all platforms to need to the same headers here.
>>
> This is due to SunStudio compilation setting. It will issue error on
> solaris like:
>
> src/share/vm/utilities/quickSort.cpp", line 192: Error: The function
> "AllocateHeap" must have a prototype.
>
> in precompiled.hpp:
>
> // Precompiled headers are turned off for Sun Studion,
> // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles.
>
> #ifndef DONT_USE_PRECOMPILED_HEADER
>
> I could add the including for all platforms, since it will be excluded
> by other platforms except for solaris --- precompiled.hpp already
> includes those two files. Adding #ifdef SOLARIS here to indicate they
> are only needed for Solaris.

The solaris case is showing you that this only works if precompiled 
headers are enabled. If you disable them you should find this fails to 
compile on the other platforms too. There is a missing #include needed 
for the allocation header.

David
-----


> I will send new webrev out.
>
> Thanks
> Yumin
>
>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From david.holmes at oracle.com  Mon Apr 15 23:15:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 09:15:01 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C4AF4.7090808@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C4AF4.7090808@oracle.com>
Message-ID: <516C89F5.2090600@oracle.com>

On 16/04/2013 4:46 AM, Ioi Lam wrote:
> On 04/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap
>> allocated HandleMark in the Thread() constructor is a bit of a hack.
>> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap
>> allocated HandleMark as we don't keep any pointer to it! I think this
>> needs to be re-visited, but as a separate CR.
>>
> David,
>
> The HandleMark is not leaked. It is freed in the Thread destructor:
>
> before:
>
>     355   delete last_handle_mark();

Ah! I see - thanks Ioi.

> after:
>
>     355   FREE_C_HEAP_ARRAY(HandleMark, last_handle_mark(), mtInternal);

Hmmmm - but it isn't an array - makes this part even uglier.

And this doesn't trigger the HandleMark destructor!

David
-----



> - Ioi


From david.holmes at oracle.com  Mon Apr 15 23:20:26 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 09:20:26 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C75B7.6010700@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
Message-ID: <516C8B3A.9060606@oracle.com>

Adding back compiler and gc teams

On 16/04/2013 7:48 AM, Yumin Qi wrote:
> Zhenyu,
>
> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>> Maybe you need a replacement delete operator, please check
>> http://www.cplusplus.com/reference/new/operator%20delete/
>>
> i can just do
>
> delete ((type *)&array_name[index]);
>
> so the destructor will be called, is this right?

No, it will also deallocate the memory unless you use a variant of 
delete (which is what I think Zhengyu was referring to) that doesn't 
actually deallocate the memory.

I think this is getting out of hand - if we go this path then we should 
simply have a custom operator new[] and operator delete[] and not need 
NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple enough to 
actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that allocates and 
constructs then we need a FREE_C_HEAP_OBJ_ARRAY that destructs and then 
de-allocates.

I have no issue with calling destructors explicitly.

David
-----

> Thanks
> Yumin
>> Thanks,
>>
>> -Zhengyu
>>
>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, memflags)                  \
>>>   624   {                                                                                 \
>>>   625     if (array_name != NULL) {                                                       \
>>>   626       for (int index = 0; index < size; index ++) {                                 \
>>>   627         /* placement to call dtor on type */                                        \
>>>   628         ((type*)&array_name[index])->~type();                                       \
>>>   629       }                                                                             \
>>>   630       FREE_C_HEAP_ARRAY(type, array_name, memflags);                                \
>>>   631     }                                                                               \
>>>   632   }
>>>
>>>
>>> I really don't like this, calling dtor  ...
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>> new webrev at:
>>>>
>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>
>>>> Can I have a review from GC team for this change?
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>> After take feedback and modify, new webrev
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>
>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>> that CHeap allocated HandleMark as we don't keep any pointer to it!
>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>
>>>>> ---
>>>>>
>>>>> allocation.hpp:
>>>>>
>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>> before deallocating ?
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>
>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>> would expect all platforms to need to the same headers here.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>> .
>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>
>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>> Since we
>>>>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>>>>> will call ctors.
>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>> allocation.hpp #618 does.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>>>> carTableRS.cpp
>>>>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>>>>
>>>>>>>>>
>>>>>>>> See reply to David H.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>   webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>
>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>
>>>>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From john.cuthbertson at oracle.com  Mon Apr 15 23:29:06 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 15 Apr 2013 16:29:06 -0700
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1365687182.2594.19.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus>
	<1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com>
	<1364203467.2703.41.camel@cirrus> <51509569.1020604@oracle.com>
	<1364306183.2847.52.camel@cirrus> <1365687182.2594.19.camel@cirrus>
Message-ID: <516C8D42.1030207@oracle.com>

Hi Thomas,

Why do we treat:

java -Xms8M  -XX:InitialHeapSize=4M...

as an error while accepting:

java -XX:InitialHeapSize=4M -Xms8M...

It looks inconsistent. In both cases the user has asked for an initial 
heap size less than his requested minimum.

In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be 
coalesced into a single line for each? This would make the setting of 
Initial and Min consistent with the code that sets Max on line 87.

Other than these nits - it looks good to me. Very exhaustive test case.

JohnC


On 4/11/2013 6:33 AM, Thomas Schatzl wrote:
> Hi all,
>
>    there is a new webrev for this issue at
> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/
>
> Since it has been a while since the last update, here is a short
> introduction to the problem again:
>
> The current argument processing for minimum, initial and maximum heap
> sizing is somewhat unintiutive.
>
> This CR tries to fix and improve it.
>
> The following problems have been identified and fixed with earlier
> webrevs (as of http://cr.openjdk.java.net/~tschatzl/8006088/webrev.3):
>
> - VM gives an error when InitialHeapSize > MaxHeapSize
> - shrink NewSize and OldSize so that if MaxHeapSize is given, their sum
> is below MaxHeapSize.
> - automatically adapt minimum heap size if only InitialHeapSize is
> given. This avoids getting "Incompatible minimum and initial heap sizes
> specified" if only -XX:InitialHeapSize is specified with low values.
> - also allow specification of -Xms0 (i.e. size >= 0, not size > 0); this
> is a valid heap size specification, and means minimum/initial heap size
> = OldSize + NewSize.
> - test cases
>
> The new additions for this webrev are as follows:
>
> - implement the behavior shown in the table at
> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/XmsInitialHeapSizeErgo.html . This table also shows old behavior for comparison with the new behavior. Summarizing, this changeset fixes unexpected errors in the old behavior in the case when:
>    * -Xms0 is given,
>    * only -XX:InitialHeapSize=0 is given (previously the resulting
> initial heap size was OldSize + NewSize while now it applies normal
> ergonomics), and
>    * when setting -Xms to a "large" value and -XX:InitialHeapSize to
> zero. (Only this issue had to be actually fixed in comparison to the
> earlier webrev).
> - add new jtreg tests for previously unverified behavior of that entire
> table.
> - improved testing for maximum heap sizing which now does not rely on a
> hardcoded constant for aligning the expected value as the test case
> retrieves the alignment value from the VM.
>
> Bugs.sun.com:
> http://bugs.sun.com/view_bug.do?bug_id=8006088
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8006088
>
> Testing:
> jprt, manual invocation of all test cases
>
> Hth,
> Thomas
>
>
>



From jon.masamitsu at oracle.com  Tue Apr 16 04:46:25 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 15 Apr 2013 21:46:25 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <515CFAE6.8010903@oracle.com>
References: <515CFAE6.8010903@oracle.com>
Message-ID: <516CD7A1.5010408@oracle.com>

This version incorporates the code review comments and fixes
some bugs uncovered by the changes.

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

This version does not free the current VirtualSpaceNode.
I tried it but backed it out to simply the code while debugging.  I
will try it again later (but not with this set of changes).

This is a webrev based on the changes for 8011173.

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

Jon

On 4/3/2013 9:00 PM, Jon Masamitsu wrote:
> After class unloading deallocate any VirtualSpaceNodes not being used.
>
> When the classes for a dead class loader are unloaded, all the Metachunks
> that had been used by that class loader are put on the Metachunk
> free list for later reuse.   If all the Metachunks allocated out of a
> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>  from the free list and deallocate the VirtualSpaceNode.
>
> The constructor for VirtualSpaceNode was moved to be below the 
> definition of
> SpaceManager.
>
> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>
> Thanks.
>
> Jon



From yumin.qi at oracle.com  Tue Apr 16 05:44:38 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 15 Apr 2013 22:44:38 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516CE546.7060309@oracle.com>

For HandleMark,


On 4/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>

The default constructor for HandleMark:
inline HandleMark::HandleMark() {
   initialize(Thread::current());
}

In thread.cpp, Thread::Thread(), the last HandleMark is created in heap,
-  new HandleMark(this);
-
+  HandleMark *hm = NEW_C_HEAP_OBJ(HandleMark, mtThread);
+  hm->initialize(this);
The original code, is calling the constructor with 'this'.  Unless we 
code a macro to pass 'this' as argument, which looks specific not 
generic, to call the constructor.  When call default constructor here, 
will assert current thread is NULL --- the real native thread has not 
created yet , the thread id is not cached so we get back a NULL for 
Thread::current(). That is, we could not call the default constructor at 
this time, this change seems strange but works --- first created the 
object without calling constructor in heap, then initialize with 'this'.

The problem is ~HandleMark is not called this way. Need to have a 
version to call dtor which seems ugly.

The handle mark here for what? I could  not spot any handle allocated 
from this point in Thread creation.

Thanks
Yumin


> ---
>
> allocation.hpp:
>
> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
> before deallocating ?
>
> ---
>
> src/share/vm/utilities/quickSort.cpp
>
> Why does only Solaris need the allocation headers included ?? I would 
> expect all platforms to need to the same headers here.
>
> Thanks,
> David
>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since we
>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>



From david.holmes at oracle.com  Tue Apr 16 06:02:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 16:02:38 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516CE546.7060309@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516CE546.7060309@oracle.com>
Message-ID: <516CE97E.7090500@oracle.com>

On 16/04/2013 3:44 PM, Yumin Qi wrote:
> For HandleMark,
>
>
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap
>> allocated HandleMark in the Thread() constructor is a bit of a hack.
>> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap
>> allocated HandleMark as we don't keep any pointer to it! I think this
>> needs to be re-visited, but as a separate CR.
>>
>
> The default constructor for HandleMark:
> inline HandleMark::HandleMark() {
>    initialize(Thread::current());
> }
>
> In thread.cpp, Thread::Thread(), the last HandleMark is created in heap,
> -  new HandleMark(this);
> -
> +  HandleMark *hm = NEW_C_HEAP_OBJ(HandleMark, mtThread);
> +  hm->initialize(this);
> The original code, is calling the constructor with 'this'.  Unless we
> code a macro to pass 'this' as argument, which looks specific not
> generic, to call the constructor.  When call default constructor here,
> will assert current thread is NULL --- the real native thread has not
> created yet , the thread id is not cached so we get back a NULL for
> Thread::current(). That is, we could not call the default constructor at
> this time, this change seems strange but works --- first created the
> object without calling constructor in heap, then initialize with 'this'.

I understand why you had to make the change to make the code work, but 
it is still a horrible change to have to make. :)

> The problem is ~HandleMark is not called this way. Need to have a
> version to call dtor which seems ugly.
>
> The handle mark here for what? I could  not spot any handle allocated
> from this point in Thread creation.

As I commented in the new CR I also can not see why we need this initial 
HandleMark. It's presence greatly complicates things.

David

> Thanks
> Yumin
>
>
>> ---
>>
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>> before deallocating ?
>>
>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would
>> expect all platforms to need to the same headers here.
>>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From martin.doerr at sap.com  Tue Apr 16 08:38:17 2013
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 16 Apr 2013 08:38:17 +0000
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>

Hi all,

we found a G1 bug in the template interpreter on x86_64 and sparc with compressed Oops.
"do_oop_store" performs a "store_heap_oop" which compresses the input register.
This compressed Oop is passed to the succeeding g1_write_barrier_post, which is wrong.
Correctly, g1_write_barrier_post needs the uncompressed Oop for the heap region crossing check.

This fix preserves the uncompressed Oop in a register which gets passed to the g1_write_barrier_post:
http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/

Please supply a bug id and review this change.

Kind regards,
Martin

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

From mikael.gerdin at oracle.com  Tue Apr 16 09:40:40 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 16 Apr 2013 11:40:40 +0200
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
Message-ID: <516D1C98.8000606@oracle.com>

Martin,

(CC:ed runtime)

On 2013-04-16 10:38, Doerr, Martin wrote:
> Hi all,
>
> we found a G1 bug in the template interpreter on x86_64 and sparc with
> compressed Oops.
>
> ?do_oop_store? performs a ?store_heap_oop? which compresses the input
> register.
>
> This compressed Oop is passed to the succeeding g1_write_barrier_post,
> which is wrong.
>
> Correctly, g1_write_barrier_post needs the uncompressed Oop for the heap
> region crossing check.
>
> This fix preserves the uncompressed Oop in a register which gets passed
> to the g1_write_barrier_post:
>
> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>
> Please supply a bug id and review this change.

I filed JDK-8012335 for this. I filed it on hotspot/runtime since I 
think that most of the GC team are not that familiar with the 
interpreter code.

Unfortunately I know too little about the interpreter to review this but 
your argument sounds reasonable to me.

/Mikael

>
> Kind regards,
>
> Martin
>


From jesper.wilhelmsson at oracle.com  Tue Apr 16 10:01:45 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 16 Apr 2013 12:01:45 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <51549110.2010208@oracle.com>
References: <51549110.2010208@oracle.com>
Message-ID: <516D2189.4030404@oracle.com>

Hi,

After several different versions and realizations about the worker threads in 
G1, here is now a new version of the evacuation failed event.

To include the correct thread with each event has turned out to require more 
work and footprint overhead than what can be motivated at this point, and since 
any other solution would be confusing rather than informative, we have decided 
not to include the thread information in the evacuation failed event for now.

The thread information was never a requirement in the first place, we just threw 
it in there in the promotion failed event because it was easily available in the 
parallel collectors and someone might be able to use it for debugging at some point.

An RFE [1] has been created to remind us to look at this again for G1.

The updated webrev is here:
http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008916

[1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012217

Thanks!
/Jesper

Jesper Wilhelmsson skrev 28/3/13 7:50 PM:
> Hi,
>
> A new version of the evacuation failed event for G1. Now, each thread sends an
> event with the info it has collected during the collection in the same way as
> the other collectors do with promotion failed events.
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>
> Thanks,
> /Jesper


From bengt.rutisson at oracle.com  Tue Apr 16 12:12:07 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 16 Apr 2013 14:12:07 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <516D2189.4030404@oracle.com>
References: <51549110.2010208@oracle.com> <516D2189.4030404@oracle.com>
Message-ID: <516D4017.2090202@oracle.com>


Hi Jesper,

A couple of comments:

As I said before I don't like the lazy allocation of the 
EvacutaionFailedInfo objects. I would prefer to allocate all the objects 
the G1CollectedHeap constructor. This would make the code much simpler. 
I know you are worried about false sharing, but I don't think the 
current approach reduces the risk of false sharing. If it really is a 
problem in the evacuation failed case (which I am not convinced of) you 
should pad the EvacuationFailedInfo objects instead.

I would prefer that we always look the EvacutaionFailedInfo objects up 
in the G1CollectedHeap::_evacuation_failed_info_array rather than to 
include them in the G1ParScanThreadState.

So, do "_g1h->_evacuation_failed_info_array[_queue_num]" instead of 
"_par_scan_state->evacuation_failed_info()" in 
G1CollectedHeap::handle_evacuation_failure_par(). That means that you 
don't have to change G1ParScanThreadState much at all. No extra fields 
and no changes to the method declarations.

I think this is more future proof also, since the next step is probably 
to add a separate data structure to allow us to look up 
EvacuationFailedInfo objects based on the thread id.

I would also prefer that EvacuationFailedInfo inherits from CHeapObj 
instead of VALUE_OBJ_CLASS_SPEC. That way you can use the normal new 
operator instead of placement new.

Bengt


On 4/16/13 12:01 PM, Jesper Wilhelmsson wrote:
> Hi,
>
> After several different versions and realizations about the worker 
> threads in G1, here is now a new version of the evacuation failed event.
>
> To include the correct thread with each event has turned out to 
> require more work and footprint overhead than what can be motivated at 
> this point, and since any other solution would be confusing rather 
> than informative, we have decided not to include the thread 
> information in the evacuation failed event for now.
>
> The thread information was never a requirement in the first place, we 
> just threw it in there in the promotion failed event because it was 
> easily available in the parallel collectors and someone might be able 
> to use it for debugging at some point.
>
> An RFE [1] has been created to remind us to look at this again for G1.
>
> The updated webrev is here:
> http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008916
>
> [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012217
>
> Thanks!
> /Jesper
>
> Jesper Wilhelmsson skrev 28/3/13 7:50 PM:
>> Hi,
>>
>> A new version of the evacuation failed event for G1. Now, each thread 
>> sends an
>> event with the info it has collected during the collection in the 
>> same way as
>> the other collectors do with promotion failed events.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>
>> Thanks,
>> /Jesper



From david.holmes at oracle.com  Tue Apr 16 12:56:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 22:56:38 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516D4675.8060308@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
Message-ID: <516D4A86.90405@oracle.com>

On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
> On 4/15/2013 7:20 PM, David Holmes wrote:
>> Adding back compiler and gc teams
>>
>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>> Zhenyu,
>>>
>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>> Maybe you need a replacement delete operator, please check
>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>
>>> i can just do
>>>
>>> delete ((type *)&array_name[index]);
>>>
>>> so the destructor will be called, is this right?
>>
>> No, it will also deallocate the memory unless you use a variant of
>> delete (which is what I think Zhengyu was referring to) that doesn't
>> actually deallocate the memory.
>>
> Yes, I meant placement delete operator, which takes two pointers.

But you can only call that explicitly as a function. The delete 
expression will never use it, so I don't see how it applies. We need to 
call the destructor without de-allocating and the only way I can see to 
do that is to call the destructor explicitly.

David
-----


> -Zhengyu
>
>
>> I think this is getting out of hand - if we go this path then we
>> should simply have a custom operator new[] and operator delete[] and
>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>> destructs and then de-allocates.
>>
>> I have no issue with calling destructors explicitly.
>>
>> David
>> -----
>>
>>> Thanks
>>> Yumin
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>> memflags)                  \
>>>>>   624 { \
>>>>>   625     if (array_name != NULL)
>>>>> {                                                       \
>>>>>   626       for (int index = 0; index < size; index ++)
>>>>> {                                 \
>>>>>   627         /* placement to call dtor on type
>>>>> */                                        \
>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>   629 } \
>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>> memflags);                                \
>>>>>   631 } \
>>>>>   632   }
>>>>>
>>>>>
>>>>> I really don't like this, calling dtor  ...
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>> new webrev at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>
>>>>>> Can I have a review from GC team for this change?
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>> Hi Yumin,
>>>>>>>
>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>
>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer to it!
>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> allocation.hpp:
>>>>>>>
>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>> before deallocating ?
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>
>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>> .
>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>
>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>> Since we
>>>>>>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>> which
>>>>>>>>>> will call ctors.
>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> See reply to David H.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>
>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>> new
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>
>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>> ::new[]
>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>> the
>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>> have to
>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>


From jesper.wilhelmsson at oracle.com  Tue Apr 16 12:58:39 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 16 Apr 2013 14:58:39 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <516D4017.2090202@oracle.com>
References: <51549110.2010208@oracle.com> <516D2189.4030404@oracle.com>
	<516D4017.2090202@oracle.com>
Message-ID: <516D4AFF.6080900@oracle.com>

Hi Bengt,

Thanks for the review!


Bengt Rutisson skrev 16/4/13 2:12 PM:
>
> Hi Jesper,
>
> A couple of comments:
>
> As I said before I don't like the lazy allocation of the EvacutaionFailedInfo
> objects. I would prefer to allocate all the objects the G1CollectedHeap
> constructor. This would make the code much simpler. I know you are worried about
> false sharing, but I don't think the current approach reduces the risk of false
> sharing. If it really is a problem in the evacuation failed case (which I am not
> convinced of) you should pad the EvacuationFailedInfo objects instead.

False sharing is an issue even if it only happens when evacuation fails. As we 
have seen in several tests and benchmarks, once one thread fails to evacuate it 
is quite likely that other threads will follow, and the way G1 works today the 
GC is not aborted in the case of a failed evacuation, but continues to try to 
evacuate the rest of the live objects. This often results in thousands of failed 
object evacuations in a single GC.

And, sure, we hope that a production system won't experience that many 
evacuation failures, but do we really want that to be a show stopper for pause 
sensitive applications?

The current approach will reduce the risk of false sharing on normal hardware 
since each thread allocates its own data structure, and it will lower the risk 
of false sharing even more on NUMA architectures when the data structures are 
allocated on different nodes.

Padding is not an option since we are actively working on reducing footprint, 
and it will not solve the problem on NUMA.

> I would prefer that we always look the EvacutaionFailedInfo objects up in the
> G1CollectedHeap::_evacuation_failed_info_array rather than to include them in
> the G1ParScanThreadState.
>
> So, do "_g1h->_evacuation_failed_info_array[_queue_num]" instead of
> "_par_scan_state->evacuation_failed_info()" in
> G1CollectedHeap::handle_evacuation_failure_par(). That means that you don't have
> to change G1ParScanThreadState much at all. No extra fields and no changes to
> the method declarations.
>
> I think this is more future proof also, since the next step is probably to add a
> separate data structure to allow us to look up EvacuationFailedInfo objects
> based on the thread id.

I think it is unlikely that we will add a new global data structure to solve the 
thread problem. It is more likely that we will have the EvacuationFailedInfo 
object as a local part of the G1ParScanThreadState and make sure that the same 
thread gets the same G1ParScanThreadState object each time. This would be the 
most efficient solution. Again, think NUMA.

> I would also prefer that EvacuationFailedInfo inherits from CHeapObj instead of
> VALUE_OBJ_CLASS_SPEC. That way you can use the normal new operator instead of
> placement new.

Is CHeapObj really an option? EvacuationFailedInfo inherits from CopyFailedInfo 
which is also the superclass of PromotionFailedInfo. PromotionFailedInfo is 
stack allocated in the other collectors.

Placement new is used in several places already in the HotSpot code. I don't 
think it is less normal than the "normal" new operator. But I don't have a 
strong opinion here. If CHeapObj can be stack allocated (which would be a bit 
weird I think) then I can use that approach instead.

Thanks,
/Jesper


>
> Bengt
>
>
> On 4/16/13 12:01 PM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> After several different versions and realizations about the worker threads in
>> G1, here is now a new version of the evacuation failed event.
>>
>> To include the correct thread with each event has turned out to require more
>> work and footprint overhead than what can be motivated at this point, and
>> since any other solution would be confusing rather than informative, we have
>> decided not to include the thread information in the evacuation failed event
>> for now.
>>
>> The thread information was never a requirement in the first place, we just
>> threw it in there in the promotion failed event because it was easily
>> available in the parallel collectors and someone might be able to use it for
>> debugging at some point.
>>
>> An RFE [1] has been created to remind us to look at this again for G1.
>>
>> The updated webrev is here:
>> http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008916
>>
>> [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012217
>>
>> Thanks!
>> /Jesper
>>
>> Jesper Wilhelmsson skrev 28/3/13 7:50 PM:
>>> Hi,
>>>
>>> A new version of the evacuation failed event for G1. Now, each thread sends an
>>> event with the info it has collected during the collection in the same way as
>>> the other collectors do with promotion failed events.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>>
>>> Thanks,
>>> /Jesper
>


From bengt.rutisson at oracle.com  Tue Apr 16 13:30:02 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 16 Apr 2013 15:30:02 +0200
Subject: RFR: 8008916 G1: Evacuation failed tracing event
In-Reply-To: <516D4AFF.6080900@oracle.com>
References: <51549110.2010208@oracle.com> <516D2189.4030404@oracle.com>
	<516D4017.2090202@oracle.com> <516D4AFF.6080900@oracle.com>
Message-ID: <516D525A.3000200@oracle.com>


Hi Jesper,

On 4/16/13 2:58 PM, Jesper Wilhelmsson wrote:
> Hi Bengt,
>
> Thanks for the review!
>
>
> Bengt Rutisson skrev 16/4/13 2:12 PM:
>>
>> Hi Jesper,
>>
>> A couple of comments:
>>
>> As I said before I don't like the lazy allocation of the 
>> EvacutaionFailedInfo
>> objects. I would prefer to allocate all the objects the G1CollectedHeap
>> constructor. This would make the code much simpler. I know you are 
>> worried about
>> false sharing, but I don't think the current approach reduces the 
>> risk of false
>> sharing. If it really is a problem in the evacuation failed case 
>> (which I am not
>> convinced of) you should pad the EvacuationFailedInfo objects instead.
>
> False sharing is an issue even if it only happens when evacuation 
> fails. As we have seen in several tests and benchmarks, once one 
> thread fails to evacuate it is quite likely that other threads will 
> follow, and the way G1 works today the GC is not aborted in the case 
> of a failed evacuation, but continues to try to evacuate the rest of 
> the live objects. This often results in thousands of failed object 
> evacuations in a single GC.
>
> And, sure, we hope that a production system won't experience that many 
> evacuation failures, but do we really want that to be a show stopper 
> for pause sensitive applications?
>
> The current approach will reduce the risk of false sharing on normal 
> hardware since each thread allocates its own data structure, and it 
> will lower the risk of false sharing even more on NUMA architectures 
> when the data structures are allocated on different nodes.

The current approach does not reduce the risk of false sharing. You 
allocate the EvacuationFailedInfo objects as part of the 
G1ParScanThreadStates which means that you might get false sharing 
between the EvacuationFailedInfo for one thread and the 
G1ParScanThreadStates for the next thread. All you have achieved is make 
the code more complex.

You are also not solving the NUMA issue by allocating these thread local 
since, as you know, the EvacuationFailedInfo objects are not thread 
local. That is the whole reason why you weren't able to get the thread 
field right. And we also don't have any NUMA support so I don't really 
know what the issue is.

>
> Padding is not an option since we are actively working on reducing 
> footprint, and it will not solve the problem on NUMA.

I think padding is the only stable option and I disagree that it is too 
much of a footprint issue. We already do that a lot in the exact code 
you are changing. See PADDING_ELEM_NUM.

>
>> I would prefer that we always look the EvacutaionFailedInfo objects 
>> up in the
>> G1CollectedHeap::_evacuation_failed_info_array rather than to include 
>> them in
>> the G1ParScanThreadState.
>>
>> So, do "_g1h->_evacuation_failed_info_array[_queue_num]" instead of
>> "_par_scan_state->evacuation_failed_info()" in
>> G1CollectedHeap::handle_evacuation_failure_par(). That means that you 
>> don't have
>> to change G1ParScanThreadState much at all. No extra fields and no 
>> changes to
>> the method declarations.
>>
>> I think this is more future proof also, since the next step is 
>> probably to add a
>> separate data structure to allow us to look up EvacuationFailedInfo 
>> objects
>> based on the thread id.
>
> I think it is unlikely that we will add a new global data structure to 
> solve the thread problem. It is more likely that we will have the 
> EvacuationFailedInfo object as a local part of the 
> G1ParScanThreadState and make sure that the same thread gets the same 
> G1ParScanThreadState object each time. This would be the most 
> efficient solution. Again, think NUMA.

Again, I disagree. I definitely think we should add the thread field to 
the EvacuationFailedInfo and short term I think the way to do that is to 
look it up based on the thread id. The footprint and performance 
overheads are minimal.

>> I would also prefer that EvacuationFailedInfo inherits from CHeapObj 
>> instead of
>> VALUE_OBJ_CLASS_SPEC. That way you can use the normal new operator 
>> instead of
>> placement new.
>
> Is CHeapObj really an option? EvacuationFailedInfo inherits from 
> CopyFailedInfo which is also the superclass of PromotionFailedInfo. 
> PromotionFailedInfo is stack allocated in the other collectors.

What is the problem with making CopyFailedInfo inherit from CHeapObj? A 
CHeapObj can still be stack allocated.

>
> Placement new is used in several places already in the HotSpot code. I 
> don't think it is less normal than the "normal" new operator. 

I just think it is strange that you use placement new to work around the 
fact that you have specified the allocation class to disallow new. Why 
not just admit that the object is intended to be dynamically allocated 
and make it a CHeapObj?

> But I don't have a strong opinion here. If CHeapObj can be stack 
> allocated (which would be a bit weird I think) then I can use that 
> approach instead.

Yes, I you can.

Bengt

>
> Thanks,
> /Jesper
>
>
>>
>> Bengt
>>
>>
>> On 4/16/13 12:01 PM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> After several different versions and realizations about the worker 
>>> threads in
>>> G1, here is now a new version of the evacuation failed event.
>>>
>>> To include the correct thread with each event has turned out to 
>>> require more
>>> work and footprint overhead than what can be motivated at this 
>>> point, and
>>> since any other solution would be confusing rather than informative, 
>>> we have
>>> decided not to include the thread information in the evacuation 
>>> failed event
>>> for now.
>>>
>>> The thread information was never a requirement in the first place, 
>>> we just
>>> threw it in there in the promotion failed event because it was easily
>>> available in the parallel collectors and someone might be able to 
>>> use it for
>>> debugging at some point.
>>>
>>> An RFE [1] has been created to remind us to look at this again for G1.
>>>
>>> The updated webrev is here:
>>> http://cr.openjdk.java.net/~jwilhelm/8008916/webrev/
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008916
>>>
>>> [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012217
>>>
>>> Thanks!
>>> /Jesper
>>>
>>> Jesper Wilhelmsson skrev 28/3/13 7:50 PM:
>>>> Hi,
>>>>
>>>> A new version of the evacuation failed event for G1. Now, each 
>>>> thread sends an
>>>> event with the info it has collected during the collection in the 
>>>> same way as
>>>> the other collectors do with promotion failed events.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008916/webrev.2/
>>>>
>>>> Thanks,
>>>> /Jesper
>>



From jesper.wilhelmsson at oracle.com  Tue Apr 16 14:16:55 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 16 Apr 2013 16:16:55 +0200
Subject: RFR (S): 8010090 - GC ID has the wrong type
Message-ID: <516D5D57.2060804@oracle.com>

Hi,

Could I have a couple of reviews for this really small change.

The type of the GC ID and the Compile ID in the different tracing events should 
be UINT as the values put into these fields are uint.

Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090

Thanks,
/Jesper


From mikael.gerdin at oracle.com  Tue Apr 16 14:46:37 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 16 Apr 2013 16:46:37 +0200
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <516CD7A1.5010408@oracle.com>
References: <515CFAE6.8010903@oracle.com> <516CD7A1.5010408@oracle.com>
Message-ID: <516D644D.6000601@oracle.com>

Jon,

On 2013-04-16 06:46, Jon Masamitsu wrote:
> This version incorporates the code review comments and fixes
> some bugs uncovered by the changes.
>
> http://cr.openjdk.java.net/~jmasa/8011268/webrev.01/

I like the usage of placement new, but I don't think you need to add it 
to _ValueObj and Metachunk, you could just have used the global 
placement new instead:
   Metachunk* result = ::new (chunk_limit) Metachunk(chunk_word_size, this);
though you might need to "#include <new>" for that.


VirtualSpaceList::purge has some tabs in it.

The comment in purge:
1000       // Will this work if the entire Virtualspace is used?
Are you going to remove that when you've convinced yourself if it will 
work or not? :)


Besides these small comments I think this is good.

>
> This version does not free the current VirtualSpaceNode.
> I tried it but backed it out to simply the code while debugging.  I
> will try it again later (but not with this set of changes).
>
> This is a webrev based on the changes for 8011173.
>
> http://cr.openjdk.java.net/~jmasa/8011173/webrev.00/

Are you going to push this change? It looks like you've got enough 
reviews to push it.

/Mikael

>
> Jon
>
> On 4/3/2013 9:00 PM, Jon Masamitsu wrote:
>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>
>> When the classes for a dead class loader are unloaded, all the Metachunks
>> that had been used by that class loader are put on the Metachunk
>> free list for later reuse.   If all the Metachunks allocated out of a
>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>  from the free list and deallocate the VirtualSpaceNode.
>>
>> The constructor for VirtualSpaceNode was moved to be below the
>> definition of
>> SpaceManager.
>>
>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>
>> Thanks.
>>
>> Jon
>


From ioi.lam at oracle.com  Mon Apr 15 18:46:12 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 15 Apr 2013 11:46:12 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516C4AF4.7090808@oracle.com>

On 04/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>
David,

The HandleMark is not leaked. It is freed in the Thread destructor:

before:

    355   delete last_handle_mark();

after:

    355   FREE_C_HEAP_ARRAY(HandleMark, last_handle_mark(), mtInternal);

- Ioi


From zhengyu.gu at oracle.com  Mon Apr 15 18:42:53 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 15 Apr 2013 14:42:53 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C3BC8.2040001@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com>
Message-ID: <516C4A2D.8060902@oracle.com>

  623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, memflags)                  \
  624   {                                                                                 \
  625     if (array_name != NULL) {                                                       \
  626       for (int index = 0; index < size; index ++) {                                 \
  627         /* placement to call dtor on type */                                        \
  628         ((type*)&array_name[index])->~type();                                       \
  629       }                                                                             \
  630       FREE_C_HEAP_ARRAY(type, array_name, memflags);                                \
  631     }                                                                               \
  632   }


I really don't like this, calling dtor ...

Thanks,

-Zhengyu


On 4/15/2013 1:41 PM, Yumin Qi wrote:
> new webrev at:
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>
> Can I have a review from GC team for this change?
>
> Thanks
> Yumin
>
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap 
>> allocated HandleMark in the Thread() constructor is a bit of a hack. 
>> HandleMarks should be stack-allocated. Plus we seem to leak that 
>> CHeap allocated HandleMark as we don't keep any pointer to it! I 
>> think this needs to be re-visited, but as a separate CR.
>>
>> ---
>>
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
>> before deallocating ?
>>
>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would 
>> expect all platforms to need to the same headers here.
>>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

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

From zhengyu.gu at oracle.com  Tue Apr 16 12:39:17 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 16 Apr 2013 08:39:17 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C8B3A.9060606@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com>
Message-ID: <516D4675.8060308@oracle.com>


On 4/15/2013 7:20 PM, David Holmes wrote:
> Adding back compiler and gc teams
>
> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>> Zhenyu,
>>
>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>> Maybe you need a replacement delete operator, please check
>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>
>> i can just do
>>
>> delete ((type *)&array_name[index]);
>>
>> so the destructor will be called, is this right?
>
> No, it will also deallocate the memory unless you use a variant of 
> delete (which is what I think Zhengyu was referring to) that doesn't 
> actually deallocate the memory.
>
Yes, I meant placement delete operator, which takes two pointers.

-Zhengyu


> I think this is getting out of hand - if we go this path then we 
> should simply have a custom operator new[] and operator delete[] and 
> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple 
> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that 
> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that 
> destructs and then de-allocates.
>
> I have no issue with calling destructors explicitly.
>
> David
> -----
>
>> Thanks
>> Yumin
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, 
>>>> memflags)                  \
>>>>   624 { \
>>>>   625     if (array_name != NULL) 
>>>> {                                                       \
>>>>   626       for (int index = 0; index < size; index ++) 
>>>> {                                 \
>>>>   627         /* placement to call dtor on type 
>>>> */                                        \
>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>   629 } \
>>>>   630       FREE_C_HEAP_ARRAY(type, array_name, 
>>>> memflags);                                \
>>>>   631 } \
>>>>   632   }
>>>>
>>>>
>>>> I really don't like this, calling dtor  ...
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>> new webrev at:
>>>>>
>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>
>>>>> Can I have a review from GC team for this change?
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>> Hi Yumin,
>>>>>>
>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>> After take feedback and modify, new webrev
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>
>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>> that CHeap allocated HandleMark as we don't keep any pointer to it!
>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> allocation.hpp:
>>>>>>
>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>> before deallocating ?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>
>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>> would expect all platforms to need to the same headers here.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>> .
>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>
>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>> Since we
>>>>>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, 
>>>>>>>>> which
>>>>>>>>> will call ctors.
>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>> allocation.hpp #618 does.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> See reply to David H.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>   webrev:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>
>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and 
>>>>>>>>>>> new
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>
>>>>>>>>>>> Problem description:  Remove the usage of global operator 
>>>>>>>>>>> ::new[]
>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>>> disabling use of global operator new[] and new, we constrain 
>>>>>>>>>>> the
>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>> ResourceObj unless they are stack objects or values which 
>>>>>>>>>>> have to
>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>



From mikael.gerdin at oracle.com  Tue Apr 16 16:40:34 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Tue, 16 Apr 2013 16:40:34 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 28 new changesets
Message-ID: <20130416164132.6F0264833C@hg.openjdk.java.net>

Changeset: 3b890cd4da64
Author:    ctornqvi
Date:      2013-04-03 21:41 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3b890cd4da64

8009125: Add NMT tests for Virtual Memory operations
Summary: Tests added for Reserve/Commit/Uncommit/Unreserve operations
Reviewed-by: zgu, mgerdin

! src/share/vm/prims/whitebox.cpp
- test/runtime/NMT/AllocTestType.java
+ test/runtime/NMT/MallocTestType.java
+ test/runtime/NMT/ThreadedMallocTestType.java
+ test/runtime/NMT/ThreadedVirtualAllocTestType.java
+ test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/OutputAnalyzerTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 8554c55669b0
Author:    hseigel
Date:      2013-04-04 08:47 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8554c55669b0

8010943: guarantee(length == 0) failed: invalid method ordering length
Summary: Add DumpSharedSpaces to IF condition to handle verify during -Xshare:dump.
Reviewed-by: coleenp, zgu

! src/share/vm/oops/instanceKlass.cpp

Changeset: bad3bed4b323
Author:    ccheung
Date:      2013-03-29 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bad3bed4b323

8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c
Summary: a simple fix to add FileList_free(fl) before returning NULL.
Reviewed-by: zgu, coleenp, minqi

! src/share/tools/launcher/wildcard.c

Changeset: 17bf4d428955
Author:    ccheung
Date:      2013-04-03 16:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/17bf4d428955

8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp
Reviewed-by: zgu, iklam

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp

Changeset: cc32ccaaf47f
Author:    mikael
Date:      2013-04-04 10:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cc32ccaaf47f

8003310: Enable -Wunused-function when compiling with gcc
Summary: Add the -Wunused-function flag and remove a number of unused functions.
Reviewed-by: dholmes, coleenp, kvn

! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/synchronizer.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 4c8bb5e4f68f
Author:    zgu
Date:      2013-04-05 12:19 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4c8bb5e4f68f

8011161: NMT: Memory leak when encountering out of memory error while initializing memory snapshot
Summary: Fix memory leaks when NMT fails to initialize snapshot and worker thread
Reviewed-by: dcubed, ccheung, rdurbin

! src/share/vm/services/memTracker.cpp

Changeset: 8be1318fbe77
Author:    dcubed
Date:      2013-04-05 10:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8be1318fbe77

Merge

! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 46d24f112c27
Author:    dcubed
Date:      2013-04-05 16:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/46d24f112c27

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh

Changeset: 4b7cf00ccb08
Author:    ccheung
Date:      2013-04-05 11:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4b7cf00ccb08

8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp
Reviewed-by: zgu, coleenp, hseigel, dholmes

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp

Changeset: b933e75e7cbe
Author:    zgu
Date:      2013-04-05 23:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b933e75e7cbe

Merge


Changeset: 09b0d3e9ba6c
Author:    bharadwaj
Date:      2013-04-09 08:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/09b0d3e9ba6c

8011671: JCK tests on static interface methods fail under b84: Illegal type at constant pool entry 5
Summary: Restore incorrect removal of support for static interface method verification in Java 8
Reviewed-by: kvn, coleenp

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

Changeset: 9b4a6a172a8a
Author:    amurillo
Date:      2013-04-11 01:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9b4a6a172a8a

Added tag hs25-b27 for changeset 09b0d3e9ba6c

! .hgtags

Changeset: e437668ced9d
Author:    amurillo
Date:      2013-04-11 01:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e437668ced9d

8011948: new hotspot build - hs25-b28
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 480d934f62a8
Author:    mgerdin
Date:      2013-04-11 16:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/480d934f62a8

Merge

! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 705ef39fcaa9
Author:    neliasso
Date:      2013-04-05 11:09 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/705ef39fcaa9

8006016: Memory leak at hotspot/src/share/vm/adlc/output_c.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: f67065f02409
Author:    bharadwaj
Date:      2013-04-08 07:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f67065f02409

8010913: compiler/6863420 often exceeds timeout
Summary: add longer timeout for jtreg, add internal timeout thread to prevent spurious timeouts
Reviewed-by: twisti, kvn
Contributed-by: drchase <david.r.chase at oracle.com>

! test/compiler/6863420/Test.java

Changeset: b84fd7d73702
Author:    iignatyev
Date:      2013-04-09 09:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b84fd7d73702

8007288: Additional WB API for compiler's testing
Reviewed-by: kvn, vlivanov

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
+ test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
+ test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 84ab5667f290
Author:    roland
Date:      2013-04-10 09:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/84ab5667f290

8011706: specjvm2008 test xml.transform gets array bound exception with c1
Summary: loop invariant code motion may move load before store to the same field
Reviewed-by: kvn

! src/share/vm/c1/c1_ValueMap.cpp
+ test/compiler/8011706/Test8011706.java

Changeset: d79859ff6535
Author:    kmo
Date:      2013-04-11 07:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d79859ff6535

8011952: Missing ResourceMarks in TraceMethodHandles
Summary: add missing ResourceMark under TraceMethodHandles in LinkResolver
Reviewed-by: dholmes

! src/share/vm/interpreter/linkResolver.cpp

Changeset: 9befe2fce567
Author:    vlivanov
Date:      2013-04-11 09:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9befe2fce567

8011972: Field can be erroneously marked as contended when @Contended annotation isn't present
Reviewed-by: kvn, kmo, shade

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp

Changeset: b5db9d29062f
Author:    vlivanov
Date:      2013-04-11 11:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b5db9d29062f

Merge


Changeset: 7a5aec879506
Author:    bharadwaj
Date:      2013-04-11 17:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7a5aec879506

Merge

! src/share/vm/prims/whitebox.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 5dcfeb396fed
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5dcfeb396fed

Added tag jdk8-b85 for changeset 42fe530cd478

! .hgtags

Changeset: 511e334ee345
Author:    amurillo
Date:      2013-04-11 16:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/511e334ee345

Merge

! .hgtags
- test/runtime/NMT/AllocTestType.java

Changeset: 6d88a566d369
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6d88a566d369

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 5201379fe487
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5201379fe487

Added tag hs25-b28 for changeset 6d88a566d369

! .hgtags

Changeset: c60f69931e1a
Author:    amurillo
Date:      2013-04-11 21:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c60f69931e1a

8011949: new hotspot build - hs25-b29
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 9aa8d8037ee3
Author:    mgerdin
Date:      2013-04-16 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9aa8d8037ee3

Merge

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp



From john.cuthbertson at oracle.com  Tue Apr 16 17:21:15 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 16 Apr 2013 10:21:15 -0700
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <516D1C98.8000606@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516D1C98.8000606@oracle.com>
Message-ID: <516D888B.7080005@oracle.com>

Hi Mikael,

Thanks for submitting the CR. But we should move it back to GC. We are 
responsible for the barrier code.

Martin: Thanks for finding this. I'll review you the fix. How did you 
find it? Do you have a test case? The reason I ask is because we haven't 
seen many missing RSet entry type of errors (December was the last IIRC).

JohnC

On 4/16/2013 2:40 AM, Mikael Gerdin wrote:
> Martin,
>
> (CC:ed runtime)
>
> On 2013-04-16 10:38, Doerr, Martin wrote:
>> Hi all,
>>
>> we found a G1 bug in the template interpreter on x86_64 and sparc with
>> compressed Oops.
>>
>> ?do_oop_store? performs a ?store_heap_oop? which compresses the input
>> register.
>>
>> This compressed Oop is passed to the succeeding g1_write_barrier_post,
>> which is wrong.
>>
>> Correctly, g1_write_barrier_post needs the uncompressed Oop for the heap
>> region crossing check.
>>
>> This fix preserves the uncompressed Oop in a register which gets passed
>> to the g1_write_barrier_post:
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>>
>> Please supply a bug id and review this change.
>
> I filed JDK-8012335 for this. I filed it on hotspot/runtime since I 
> think that most of the GC team are not that familiar with the 
> interpreter code.
>
> Unfortunately I know too little about the interpreter to review this 
> but your argument sounds reasonable to me.
>
> /Mikael
>
>>
>> Kind regards,
>>
>> Martin
>>



From coleen.phillimore at oracle.com  Tue Apr 16 18:54:55 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 14:54:55 -0400
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <516D1C98.8000606@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516D1C98.8000606@oracle.com>
Message-ID: <516D9E7F.40501@oracle.com>


Well, historically the GC group has added this barrier code to the 
interpreter, but I reviewed this change and it looks fine to me.

I can do the checkin if someone else can review it.  Oh also, is there a 
small jtreg test case that can be added for this?

Thanks,
Coleen

On 04/16/2013 05:40 AM, Mikael Gerdin wrote:
> Martin,
>
> (CC:ed runtime)
>
> On 2013-04-16 10:38, Doerr, Martin wrote:
>> Hi all,
>>
>> we found a G1 bug in the template interpreter on x86_64 and sparc with
>> compressed Oops.
>>
>> ?do_oop_store? performs a ?store_heap_oop? which compresses the input
>> register.
>>
>> This compressed Oop is passed to the succeeding g1_write_barrier_post,
>> which is wrong.
>>
>> Correctly, g1_write_barrier_post needs the uncompressed Oop for the heap
>> region crossing check.
>>
>> This fix preserves the uncompressed Oop in a register which gets passed
>> to the g1_write_barrier_post:
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>>
>> Please supply a bug id and review this change.
>
> I filed JDK-8012335 for this. I filed it on hotspot/runtime since I 
> think that most of the GC team are not that familiar with the 
> interpreter code.
>
> Unfortunately I know too little about the interpreter to review this 
> but your argument sounds reasonable to me.
>
> /Mikael
>
>>
>> Kind regards,
>>
>> Martin
>>



From coleen.phillimore at oracle.com  Tue Apr 16 19:05:48 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 15:05:48 -0400
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <516D888B.7080005@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516D1C98.8000606@oracle.com> <516D888B.7080005@oracle.com>
Message-ID: <516DA10C.9070603@oracle.com>


Hi,  I read my mail out of order.  Yes you guys own this code, but I 
reviewed it so you can use me as code reviewer.

Coleen

On 04/16/2013 01:21 PM, John Cuthbertson wrote:
> Hi Mikael,
>
> Thanks for submitting the CR. But we should move it back to GC. We are 
> responsible for the barrier code.
>
> Martin: Thanks for finding this. I'll review you the fix. How did you 
> find it? Do you have a test case? The reason I ask is because we 
> haven't seen many missing RSet entry type of errors (December was the 
> last IIRC).
>
> JohnC
>
> On 4/16/2013 2:40 AM, Mikael Gerdin wrote:
>> Martin,
>>
>> (CC:ed runtime)
>>
>> On 2013-04-16 10:38, Doerr, Martin wrote:
>>> Hi all,
>>>
>>> we found a G1 bug in the template interpreter on x86_64 and sparc with
>>> compressed Oops.
>>>
>>> ?do_oop_store? performs a ?store_heap_oop? which compresses the input
>>> register.
>>>
>>> This compressed Oop is passed to the succeeding g1_write_barrier_post,
>>> which is wrong.
>>>
>>> Correctly, g1_write_barrier_post needs the uncompressed Oop for the 
>>> heap
>>> region crossing check.
>>>
>>> This fix preserves the uncompressed Oop in a register which gets passed
>>> to the g1_write_barrier_post:
>>>
>>> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>>>
>>> Please supply a bug id and review this change.
>>
>> I filed JDK-8012335 for this. I filed it on hotspot/runtime since I 
>> think that most of the GC team are not that familiar with the 
>> interpreter code.
>>
>> Unfortunately I know too little about the interpreter to review this 
>> but your argument sounds reasonable to me.
>>
>> /Mikael
>>
>>>
>>> Kind regards,
>>>
>>> Martin
>>>
>



From john.cuthbertson at oracle.com  Tue Apr 16 19:26:31 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 16 Apr 2013 12:26:31 -0700
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <516D9E7F.40501@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516D1C98.8000606@oracle.com> <516D9E7F.40501@oracle.com>
Message-ID: <516DA5E7.6000006@oracle.com>

Hi Coleen,

I'm in the middle of reviewing the fix and I'll sponsor the push. I've 
asked Martin if there was a test case.

JohnC

On 4/16/2013 11:54 AM, Coleen Phillimore wrote:
>
> Well, historically the GC group has added this barrier code to the 
> interpreter, but I reviewed this change and it looks fine to me.
>
> I can do the checkin if someone else can review it.  Oh also, is there 
> a small jtreg test case that can be added for this?
>
> Thanks,
> Coleen
>
> On 04/16/2013 05:40 AM, Mikael Gerdin wrote:
>> Martin,
>>
>> (CC:ed runtime)
>>
>> On 2013-04-16 10:38, Doerr, Martin wrote:
>>> Hi all,
>>>
>>> we found a G1 bug in the template interpreter on x86_64 and sparc with
>>> compressed Oops.
>>>
>>> ?do_oop_store? performs a ?store_heap_oop? which compresses the input
>>> register.
>>>
>>> This compressed Oop is passed to the succeeding g1_write_barrier_post,
>>> which is wrong.
>>>
>>> Correctly, g1_write_barrier_post needs the uncompressed Oop for the 
>>> heap
>>> region crossing check.
>>>
>>> This fix preserves the uncompressed Oop in a register which gets passed
>>> to the g1_write_barrier_post:
>>>
>>> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>>>
>>> Please supply a bug id and review this change.
>>
>> I filed JDK-8012335 for this. I filed it on hotspot/runtime since I 
>> think that most of the GC team are not that familiar with the 
>> interpreter code.
>>
>> Unfortunately I know too little about the interpreter to review this 
>> but your argument sounds reasonable to me.
>>
>> /Mikael
>>
>>>
>>> Kind regards,
>>>
>>> Martin
>>>
>



From jon.masamitsu at oracle.com  Tue Apr 16 19:32:02 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 16 Apr 2013 12:32:02 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <516D644D.6000601@oracle.com>
References: <515CFAE6.8010903@oracle.com> <516CD7A1.5010408@oracle.com>
	<516D644D.6000601@oracle.com>
Message-ID: <516DA732.5020300@oracle.com>



On 04/16/13 07:46, Mikael Gerdin wrote:
> Jon,
>
> On 2013-04-16 06:46, Jon Masamitsu wrote:
>> This version incorporates the code review comments and fixes
>> some bugs uncovered by the changes.
>>
>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.01/
>
> I like the usage of placement new, but I don't think you need to add 
> it to _ValueObj and Metachunk, you could just have used the global 
> placement new instead:
You're right.  This is better and better.

>   Metachunk* result = ::new (chunk_limit) Metachunk(chunk_word_size, 
> this);
> though you might need to "#include <new>" for that.

The solaris and linux builds didn't complain about needing the include.  
I'll
go try windows.

>
>
> VirtualSpaceList::purge has some tabs in it.
>
> The comment in purge:
> 1000       // Will this work if the entire Virtualspace is used?
> Are you going to remove that when you've convinced yourself if it will 
> work or not? :)

Deleted the comment.

>
>
> Besides these small comments I think this is good.
>
>>
>> This version does not free the current VirtualSpaceNode.
>> I tried it but backed it out to simply the code while debugging.  I
>> will try it again later (but not with this set of changes).
>>
>> This is a webrev based on the changes for 8011173.
>>
>> http://cr.openjdk.java.net/~jmasa/8011173/webrev.00/
>
> Are you going to push this change? It looks like you've got enough 
> reviews to push it.

I need to merge and do a few tests.  That will give Coleen a chance to 
look at it.
Then I can push.

Thanks for the review.

Jon
>
> /Mikael
>
>>
>> Jon
>>
>> On 4/3/2013 9:00 PM, Jon Masamitsu wrote:
>>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>>
>>> When the classes for a dead class loader are unloaded, all the 
>>> Metachunks
>>> that had been used by that class loader are put on the Metachunk
>>> free list for later reuse.   If all the Metachunks allocated out of a
>>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>>  from the free list and deallocate the VirtualSpaceNode.
>>>
>>> The constructor for VirtualSpaceNode was moved to be below the
>>> definition of
>>> SpaceManager.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>
>>> Thanks.
>>>
>>> Jon
>>


From john.cuthbertson at oracle.com  Tue Apr 16 19:34:25 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 16 Apr 2013 12:34:25 -0700
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <516DA10C.9070603@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516D1C98.8000606@oracle.com> <516D888B.7080005@oracle.com>
	<516DA10C.9070603@oracle.com>
Message-ID: <516DA7C1.3070808@oracle.com>

Hi Coleen,

Thanks. I will add you as a reviewer.

JohnC

On 4/16/2013 12:05 PM, Coleen Phillimore wrote:
>
> Hi,  I read my mail out of order.  Yes you guys own this code, but I 
> reviewed it so you can use me as code reviewer.
>
> Coleen
>
> On 04/16/2013 01:21 PM, John Cuthbertson wrote:
>> Hi Mikael,
>>
>> Thanks for submitting the CR. But we should move it back to GC. We 
>> are responsible for the barrier code.
>>
>> Martin: Thanks for finding this. I'll review you the fix. How did you 
>> find it? Do you have a test case? The reason I ask is because we 
>> haven't seen many missing RSet entry type of errors (December was the 
>> last IIRC).
>>
>> JohnC
>>
>> On 4/16/2013 2:40 AM, Mikael Gerdin wrote:
>>> Martin,
>>>
>>> (CC:ed runtime)
>>>
>>> On 2013-04-16 10:38, Doerr, Martin wrote:
>>>> Hi all,
>>>>
>>>> we found a G1 bug in the template interpreter on x86_64 and sparc with
>>>> compressed Oops.
>>>>
>>>> ?do_oop_store? performs a ?store_heap_oop? which compresses the input
>>>> register.
>>>>
>>>> This compressed Oop is passed to the succeeding g1_write_barrier_post,
>>>> which is wrong.
>>>>
>>>> Correctly, g1_write_barrier_post needs the uncompressed Oop for the 
>>>> heap
>>>> region crossing check.
>>>>
>>>> This fix preserves the uncompressed Oop in a register which gets 
>>>> passed
>>>> to the g1_write_barrier_post:
>>>>
>>>> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>>>>
>>>> Please supply a bug id and review this change.
>>>
>>> I filed JDK-8012335 for this. I filed it on hotspot/runtime since I 
>>> think that most of the GC team are not that familiar with the 
>>> interpreter code.
>>>
>>> Unfortunately I know too little about the interpreter to review this 
>>> but your argument sounds reasonable to me.
>>>
>>> /Mikael
>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Martin
>>>>
>>
>



From coleen.phillimore at oracle.com  Tue Apr 16 19:58:21 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 15:58:21 -0400
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <516DA732.5020300@oracle.com>
References: <515CFAE6.8010903@oracle.com> <516CD7A1.5010408@oracle.com>
	<516D644D.6000601@oracle.com> <516DA732.5020300@oracle.com>
Message-ID: <516DAD5D.1090007@oracle.com>


Jon,
This looks good.   I like the placement new.
Coleen

On 04/16/2013 03:32 PM, Jon Masamitsu wrote:
>
>
> On 04/16/13 07:46, Mikael Gerdin wrote:
>> Jon,
>>
>> On 2013-04-16 06:46, Jon Masamitsu wrote:
>>> This version incorporates the code review comments and fixes
>>> some bugs uncovered by the changes.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.01/
>>
>> I like the usage of placement new, but I don't think you need to add 
>> it to _ValueObj and Metachunk, you could just have used the global 
>> placement new instead:
> You're right.  This is better and better.
>
>>   Metachunk* result = ::new (chunk_limit) Metachunk(chunk_word_size, 
>> this);
>> though you might need to "#include <new>" for that.
>
> The solaris and linux builds didn't complain about needing the 
> include.  I'll
> go try windows.
>
>>
>>
>> VirtualSpaceList::purge has some tabs in it.
>>
>> The comment in purge:
>> 1000       // Will this work if the entire Virtualspace is used?
>> Are you going to remove that when you've convinced yourself if it 
>> will work or not? :)
>
> Deleted the comment.
>
>>
>>
>> Besides these small comments I think this is good.
>>
>>>
>>> This version does not free the current VirtualSpaceNode.
>>> I tried it but backed it out to simply the code while debugging.  I
>>> will try it again later (but not with this set of changes).
>>>
>>> This is a webrev based on the changes for 8011173.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8011173/webrev.00/
>>
>> Are you going to push this change? It looks like you've got enough 
>> reviews to push it.
>
> I need to merge and do a few tests.  That will give Coleen a chance to 
> look at it.
> Then I can push.
>
> Thanks for the review.
>
> Jon
>>
>> /Mikael
>>
>>>
>>> Jon
>>>
>>> On 4/3/2013 9:00 PM, Jon Masamitsu wrote:
>>>> After class unloading deallocate any VirtualSpaceNodes not being used.
>>>>
>>>> When the classes for a dead class loader are unloaded, all the 
>>>> Metachunks
>>>> that had been used by that class loader are put on the Metachunk
>>>> free list for later reuse.   If all the Metachunks allocated out of a
>>>> VirtualSpaceNode are on the Metachunk free list, remove the Metachunks
>>>>  from the free list and deallocate the VirtualSpaceNode.
>>>>
>>>> The constructor for VirtualSpaceNode was moved to be below the
>>>> definition of
>>>> SpaceManager.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>>
>>>> Thanks.
>>>>
>>>> Jon
>>>



From yumin.qi at oracle.com  Tue Apr 16 20:52:25 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 16 Apr 2013 13:52:25 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516D4A86.90405@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com>
Message-ID: <516DBA09.9070400@oracle.com>

Hi, all

   new webrev at
   http://cr.openjdk.java.net/~minqi/8010992/webrev3

   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
use FREE_C_HEAP_OBJECT to free it in ~Thread.
                     quickSort.cpp, remove conditional includes.

Thanks
Yumin


On 4/16/2013 5:56 AM, David Holmes wrote:
> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>> Adding back compiler and gc teams
>>>
>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>> Zhenyu,
>>>>
>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>> Maybe you need a replacement delete operator, please check
>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>
>>>> i can just do
>>>>
>>>> delete ((type *)&array_name[index]);
>>>>
>>>> so the destructor will be called, is this right?
>>>
>>> No, it will also deallocate the memory unless you use a variant of
>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>> actually deallocate the memory.
>>>
>> Yes, I meant placement delete operator, which takes two pointers.
>
> But you can only call that explicitly as a function. The delete 
> expression will never use it, so I don't see how it applies. We need 
> to call the destructor without de-allocating and the only way I can 
> see to do that is to call the destructor explicitly.
>
> David
> -----
>
>
>> -Zhengyu
>>
>>
>>> I think this is getting out of hand - if we go this path then we
>>> should simply have a custom operator new[] and operator delete[] and
>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>> destructs and then de-allocates.
>>>
>>> I have no issue with calling destructors explicitly.
>>>
>>> David
>>> -----
>>>
>>>> Thanks
>>>> Yumin
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>> memflags)                  \
>>>>>>   624 { \
>>>>>>   625     if (array_name != NULL)
>>>>>> { \
>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>> {                                 \
>>>>>>   627         /* placement to call dtor on type
>>>>>> */                                        \
>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>   629 } \
>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>> memflags);                                \
>>>>>>   631 } \
>>>>>>   632   }
>>>>>>
>>>>>>
>>>>>> I really don't like this, calling dtor  ...
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>> new webrev at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>
>>>>>>> Can I have a review from GC team for this change?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>> Hi Yumin,
>>>>>>>>
>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>
>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer to 
>>>>>>>> it!
>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> allocation.hpp:
>>>>>>>>
>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>> element
>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>> before deallocating ?
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>
>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>> .
>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>
>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>> Since we
>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>> _ValueObj,
>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>> which
>>>>>>>>>>> will call ctors.
>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>> dstor
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>> new
>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>
>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>> global
>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>> the
>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>> have to
>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>



From jon.masamitsu at oracle.com  Tue Apr 16 21:00:53 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 16 Apr 2013 14:00:53 -0700
Subject: Request for review - 8011268: NPG: Free unused VirtualSpaceNodes
In-Reply-To: <516DAD5D.1090007@oracle.com>
References: <515CFAE6.8010903@oracle.com> <516CD7A1.5010408@oracle.com>
	<516D644D.6000601@oracle.com> <516DA732.5020300@oracle.com>
	<516DAD5D.1090007@oracle.com>
Message-ID: <516DBC05.4050502@oracle.com>

Thanks.

Jon

On 4/16/2013 12:58 PM, Coleen Phillimore wrote:
>
> Jon,
> This looks good.   I like the placement new.
> Coleen
>
> On 04/16/2013 03:32 PM, Jon Masamitsu wrote:
>>
>>
>> On 04/16/13 07:46, Mikael Gerdin wrote:
>>> Jon,
>>>
>>> On 2013-04-16 06:46, Jon Masamitsu wrote:
>>>> This version incorporates the code review comments and fixes
>>>> some bugs uncovered by the changes.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.01/
>>>
>>> I like the usage of placement new, but I don't think you need to add 
>>> it to _ValueObj and Metachunk, you could just have used the global 
>>> placement new instead:
>> You're right.  This is better and better.
>>
>>>   Metachunk* result = ::new (chunk_limit) Metachunk(chunk_word_size, 
>>> this);
>>> though you might need to "#include <new>" for that.
>>
>> The solaris and linux builds didn't complain about needing the 
>> include.  I'll
>> go try windows.
>>
>>>
>>>
>>> VirtualSpaceList::purge has some tabs in it.
>>>
>>> The comment in purge:
>>> 1000       // Will this work if the entire Virtualspace is used?
>>> Are you going to remove that when you've convinced yourself if it 
>>> will work or not? :)
>>
>> Deleted the comment.
>>
>>>
>>>
>>> Besides these small comments I think this is good.
>>>
>>>>
>>>> This version does not free the current VirtualSpaceNode.
>>>> I tried it but backed it out to simply the code while debugging.  I
>>>> will try it again later (but not with this set of changes).
>>>>
>>>> This is a webrev based on the changes for 8011173.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8011173/webrev.00/
>>>
>>> Are you going to push this change? It looks like you've got enough 
>>> reviews to push it.
>>
>> I need to merge and do a few tests.  That will give Coleen a chance 
>> to look at it.
>> Then I can push.
>>
>> Thanks for the review.
>>
>> Jon
>>>
>>> /Mikael
>>>
>>>>
>>>> Jon
>>>>
>>>> On 4/3/2013 9:00 PM, Jon Masamitsu wrote:
>>>>> After class unloading deallocate any VirtualSpaceNodes not being 
>>>>> used.
>>>>>
>>>>> When the classes for a dead class loader are unloaded, all the 
>>>>> Metachunks
>>>>> that had been used by that class loader are put on the Metachunk
>>>>> free list for later reuse.   If all the Metachunks allocated out of a
>>>>> VirtualSpaceNode are on the Metachunk free list, remove the 
>>>>> Metachunks
>>>>>  from the free list and deallocate the VirtualSpaceNode.
>>>>>
>>>>> The constructor for VirtualSpaceNode was moved to be below the
>>>>> definition of
>>>>> SpaceManager.
>>>>>
>>>>> http://cr.openjdk.java.net/~jmasa/8011268/webrev.00/
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jon
>>>>
>



From jon.masamitsu at oracle.com  Tue Apr 16 21:40:45 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 16 Apr 2013 14:40:45 -0700
Subject: Request for review (s) - 8011173 NPG: Replace the ChunkList
	implementation with class FreeList<Metachunk>
In-Reply-To: <515A0673.9060407@oracle.com>
References: <515A0673.9060407@oracle.com>
Message-ID: <516DC55D.6060405@oracle.com>

Final webrev with all review comment changes.
Thanks Mikael, John, Thomas and Coleen.

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


On 04/01/13 15:13, Jon Masamitsu wrote:
> For the perm gen removal project the ChunkList class
> which implemented a simple freelist of Metachunk's was added.
> This change replaces ChunkList with FreeList<Metachunk>.
>
> Changes include
>
> - Deletion of ChunkList
> - Code to initialize the freelists in the FreeList style
> - Replacement of call to ChunkList methods with the
> equivalent calls to FreeList methods.
>
> http://cr.openjdk.java.net/~jmasa/8011173
>
> Thanks.
>
> Jon


From coleen.phillimore at oracle.com  Tue Apr 16 21:45:49 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 17:45:49 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DBA09.9070400@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
Message-ID: <516DC68D.8040906@oracle.com>


Hi Yumin,

It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear 
when you'd want to use it.   The NEW_C_HEAP_OBJ call in thread.cpp could 
use the latter and not need the call to HandleMark::initialize().    And 
the change in handles.hpp wouldn't be needed then either.

The rest looks good.  I see why you didn't use placement delete because 
it isn't really supported by C++ (checking some web searching engine).

Coleen


On 04/16/2013 04:52 PM, Yumin Qi wrote:
> Hi, all
>
>   new webrev at
>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>                     quickSort.cpp, remove conditional includes.
>
> Thanks
> Yumin
>
>
> On 4/16/2013 5:56 AM, David Holmes wrote:
>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>> Adding back compiler and gc teams
>>>>
>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>> Zhenyu,
>>>>>
>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>> Maybe you need a replacement delete operator, please check
>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>
>>>>> i can just do
>>>>>
>>>>> delete ((type *)&array_name[index]);
>>>>>
>>>>> so the destructor will be called, is this right?
>>>>
>>>> No, it will also deallocate the memory unless you use a variant of
>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>> actually deallocate the memory.
>>>>
>>> Yes, I meant placement delete operator, which takes two pointers.
>>
>> But you can only call that explicitly as a function. The delete 
>> expression will never use it, so I don't see how it applies. We need 
>> to call the destructor without de-allocating and the only way I can 
>> see to do that is to call the destructor explicitly.
>>
>> David
>> -----
>>
>>
>>> -Zhengyu
>>>
>>>
>>>> I think this is getting out of hand - if we go this path then we
>>>> should simply have a custom operator new[] and operator delete[] and
>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>> destructs and then de-allocates.
>>>>
>>>> I have no issue with calling destructors explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>> memflags)                  \
>>>>>>>   624 { \
>>>>>>>   625     if (array_name != NULL)
>>>>>>> { \
>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>> {                                 \
>>>>>>>   627         /* placement to call dtor on type
>>>>>>> */                                        \
>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>   629 } \
>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>> memflags);                                \
>>>>>>>   631 } \
>>>>>>>   632   }
>>>>>>>
>>>>>>>
>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>> new webrev at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>
>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>> Hi Yumin,
>>>>>>>>>
>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>
>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>> to it!
>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> allocation.hpp:
>>>>>>>>>
>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>> element
>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>> before deallocating ?
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>
>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>> .
>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>
>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>> Since we
>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>> which
>>>>>>>>>>>> will call ctors.
>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>> global
>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>



From karen.kinnear at oracle.com  Tue Apr 16 21:53:25 2013
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 16 Apr 2013 17:53:25 -0400
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <98226c25-b171-4861-9976-04de6aff5ad2@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
Message-ID: <5A3391DA-4A7C-497E-A488-483D84061829@oracle.com>

Markus,

Looks good.

Minor comments:

1. systemDictionary.cpp
Does the post_class_load_event internal logic want to be #ifdef INCLUDE_TRACE/#endif
so it builds with embedded?

2. tracestream.hpp
  print_val (both)
  - don't you need a ResourceMark rm to use as_C_string() and name_and_sig_as_C_string()?

thanks,
Karen

p.s. guess I didn't track this closely enough - I thought the class load event was already in hs24? 
On Apr 16, 2013, at 5:35 PM, Markus Gr?nlund wrote:

> Hi again,
>  
> The changeset for this has been updated slightly to reflect underlying changes in hs24.
>  
> Still looking for reviews for this change to add information about class loading and unloading to the event based tracing framework for HS24.
>  
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>  
> Webrev (updated):
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>  
> Thanks in advance
> Markus
>  
>  
>  
>  
> From: Markus Gr?nlund 
> Sent: den 15 april 2013 10:17
> To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Subject: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24)
>  
> Greetings,
>  
> Kindly asking for reviews for the change to add class load and unload information to the event based tracing framework to HS24.
>  
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>  
> Webrev:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>  
> Thanks
> Markus

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

From yumin.qi at oracle.com  Tue Apr 16 22:08:22 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 16 Apr 2013 15:08:22 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC9AA.9040103@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DC9AA.9040103@oracle.com>
Message-ID: <516DCBD6.4050702@oracle.com>


On 4/16/2013 2:59 PM, Zhengyu Gu wrote:
> Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
> confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)
>
Yes, that will be better.

Thanks
Yumin
> Otherwise, it is good.
>
> Thanks,
>
> -Zhengyu
>
>
> On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>>
>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of 
>> unclear when you'd want to use it.   The NEW_C_HEAP_OBJ call in 
>> thread.cpp could use the latter and not need the call to 
>> HandleMark::initialize().    And the change in handles.hpp wouldn't 
>> be needed then either.
>>
>> The rest looks good.  I see why you didn't use placement delete 
>> because it isn't really supported by C++ (checking some web searching 
>> engine).
>>
>> Coleen
>>
>>
>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete 
>>>> expression will never use it, so I don't see how it applies. We 
>>>> need to call the destructor without de-allocating and the only way 
>>>> I can see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>



From coleen.phillimore at oracle.com  Tue Apr 16 22:05:13 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 18:05:13 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC9AA.9040103@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DC9AA.9040103@oracle.com>
Message-ID: <516DCB19.2050600@oracle.com>


On 04/16/2013 05:59 PM, Zhengyu Gu wrote:
> Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
> confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)

Or change the other 2 occurrences of NEW_C_HEAP_OBJ's to 
NEW_C_HEAP_OBJECT (better name) and completely remove NEW_C_HEAP_OBJ.  
Most code uses NEW_C_HEAP_ARRAY() with 1 element to get the 
NEW_C_HEAP_OBJ behavior anyway.

The other uses are structs, they won't change behavior.

Coleen

>
> Otherwise, it is good.
>
> Thanks,
>
> -Zhengyu
>
>
> On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>>
>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of 
>> unclear when you'd want to use it.   The NEW_C_HEAP_OBJ call in 
>> thread.cpp could use the latter and not need the call to 
>> HandleMark::initialize().    And the change in handles.hpp wouldn't 
>> be needed then either.
>>
>> The rest looks good.  I see why you didn't use placement delete 
>> because it isn't really supported by C++ (checking some web searching 
>> engine).
>>
>> Coleen
>>
>>
>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete 
>>>> expression will never use it, so I don't see how it applies. We 
>>>> need to call the destructor without de-allocating and the only way 
>>>> I can see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>



From yumin.qi at oracle.com  Tue Apr 16 22:12:06 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 16 Apr 2013 15:12:06 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DCB19.2050600@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DC9AA.9040103@oracle.com>
	<516DCB19.2050600@oracle.com>
Message-ID: <516DCCB6.9060304@oracle.com>

Let me check how many places NEW_C_HEAP_OBJ  used in hotspot.

Thanks
Yumin
On 4/16/2013 3:05 PM, Coleen Phillimore wrote:
>
> On 04/16/2013 05:59 PM, Zhengyu Gu wrote:
>> Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
>> confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)
>
> Or change the other 2 occurrences of NEW_C_HEAP_OBJ's to 
> NEW_C_HEAP_OBJECT (better name) and completely remove NEW_C_HEAP_OBJ.  
> Most code uses NEW_C_HEAP_ARRAY() with 1 element to get the 
> NEW_C_HEAP_OBJ behavior anyway.
>
> The other uses are structs, they won't change behavior.
>
> Coleen
>
>>
>> Otherwise, it is good.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>>>
>>> Hi Yumin,
>>>
>>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
>>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
>>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of 
>>> unclear when you'd want to use it.   The NEW_C_HEAP_OBJ call in 
>>> thread.cpp could use the latter and not need the call to 
>>> HandleMark::initialize().    And the change in handles.hpp wouldn't 
>>> be needed then either.
>>>
>>> The rest looks good.  I see why you didn't use placement delete 
>>> because it isn't really supported by C++ (checking some web 
>>> searching engine).
>>>
>>> Coleen
>>>
>>>
>>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>>> Hi, all
>>>>
>>>>   new webrev at
>>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>
>>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in 
>>>> Thread::Thread, use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>>                     quickSort.cpp, remove conditional includes.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>>> Adding back compiler and gc teams
>>>>>>>
>>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>>> Zhenyu,
>>>>>>>>
>>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>>
>>>>>>>> i can just do
>>>>>>>>
>>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>>
>>>>>>>> so the destructor will be called, is this right?
>>>>>>>
>>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>>> delete (which is what I think Zhengyu was referring to) that 
>>>>>>> doesn't
>>>>>>> actually deallocate the memory.
>>>>>>>
>>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>>
>>>>> But you can only call that explicitly as a function. The delete 
>>>>> expression will never use it, so I don't see how it applies. We 
>>>>> need to call the destructor without de-allocating and the only way 
>>>>> I can see to do that is to call the destructor explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>>> should simply have a custom operator new[] and operator delete[] 
>>>>>>> and
>>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is 
>>>>>>> simple
>>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>>> destructs and then de-allocates.
>>>>>>>
>>>>>>> I have no issue with calling destructors explicitly.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>>> memflags)                  \
>>>>>>>>>>   624 { \
>>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>>> { \
>>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>>> {                                 \
>>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>>> */                                        \
>>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>>   629 } \
>>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>>> memflags);                                \
>>>>>>>>>>   631 } \
>>>>>>>>>>   632   }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>>> new webrev at:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>>
>>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>>
>>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>>
>>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem 
>>>>>>>>>>>> to leak
>>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any 
>>>>>>>>>>>> pointer to it!
>>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>>
>>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>>> element
>>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>>> dtor's
>>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>>
>>>>>>>>>>>> Why does only Solaris need the allocation headers included 
>>>>>>>>>>>> ?? I
>>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>>> should not call new, but I think we can use 
>>>>>>>>>>>>>>> NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that 
>>>>>>>>>>>>>> is what
>>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage 
>>>>>>>>>>>>>>>>> of global
>>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as 
>>>>>>>>>>>>>>>>> same for
>>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>



From zhengyu.gu at oracle.com  Tue Apr 16 21:59:06 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 16 Apr 2013 17:59:06 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC68D.8040906@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com>
Message-ID: <516DC9AA.9040103@oracle.com>

Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)

Otherwise, it is good.

Thanks,

-Zhengyu


On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>
> Hi Yumin,
>
> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear 
> when you'd want to use it.   The NEW_C_HEAP_OBJ call in thread.cpp 
> could use the latter and not need the call to 
> HandleMark::initialize().    And the change in handles.hpp wouldn't be 
> needed then either.
>
> The rest looks good.  I see why you didn't use placement delete 
> because it isn't really supported by C++ (checking some web searching 
> engine).
>
> Coleen
>
>
> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete 
>>> expression will never use it, so I don't see how it applies. We need 
>>> to call the destructor without de-allocating and the only way I can 
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>> leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>> dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>> what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] 
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>



From john.cuthbertson at oracle.com  Tue Apr 16 23:41:32 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 16 Apr 2013 16:41:32 -0700
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
Message-ID: <516DE1AC.8030403@oracle.com>

Hi Martin,

This looks good to me. Coleen has also reviewed the change and given it 
the thumbs up. I'll let you get back to me regarding a test case before 
pushing the changes.

JohnC

On 4/16/2013 1:38 AM, Doerr, Martin wrote:
>
> Hi all,
>
> we found a G1 bug in the template interpreter on x86_64 and sparc with 
> compressed Oops.
>
> "do_oop_store" performs a "store_heap_oop" which compresses the input 
> register.
>
> This compressed Oop is passed to the succeeding g1_write_barrier_post, 
> which is wrong.
>
> Correctly, g1_write_barrier_post needs the uncompressed Oop for the 
> heap region crossing check.
>
> This fix preserves the uncompressed Oop in a register which gets 
> passed to the g1_write_barrier_post:
>
> http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/ 
> <http://cr.openjdk.java.net/%7Egoetz/webrevs/g1-cOops_bug/>
>
> Please supply a bug id and review this change.
>
> Kind regards,
>
> Martin
>

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

From david.holmes at oracle.com  Wed Apr 17 01:12:43 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Apr 2013 11:12:43 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC68D.8040906@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com>
Message-ID: <516DF70B.6000302@oracle.com>

On 17/04/2013 7:45 AM, Coleen Phillimore wrote:
>
> Hi Yumin,
>
> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a
> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric
> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear
> when you'd want to use it.

The critical difference is the invocation of the default constructor.

I think we have gone done the wrong path here because we really want the 
language to handle correct allocation and initialization (and 
de-allocation, destruction) of arrays. The allocation side seems correct 
but for deallocation I see a couple of problems:

a) you now need to know how big the array is so you can iterate through 
and invoke the destructor for each element. This might not be an issue 
for current usage but may be in general.

b) The destruction logic is incorrect I think:

((type*)&array_name[index])->~type();

This will only work correctly if the object is exactly of type "type". 
If a subclass has been stored into the array then we will invoke the 
destructor of the baseclass, due to the explicit cast to the base type. 
I don't even think a virtual destructor will be of any help there.

Aside - this comment is not relevant (allocation.hpp):

637         /* placement to call dtor on type */ 
                 \


> The NEW_C_HEAP_OBJ call in thread.cpp could
> use the latter and not need the call to HandleMark::initialize().    And
> the change in handles.hpp wouldn't be needed then either.

I'm not clear on the proposal here. But HandleMark is a PITA!

> The rest looks good.  I see why you didn't use placement delete because
> it isn't really supported by C++ (checking some web searching engine).

Placement delete doesn't help because it doesn't involve invoking 
destructors.

David

> Coleen
>
>
> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete
>>> expression will never use it, so I don't see how it applies. We need
>>> to call the destructor without de-allocating and the only way I can
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>


From david.holmes at oracle.com  Wed Apr 17 01:46:15 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Apr 2013 11:46:15 +1000
Subject: RFR(M): 8012182: Add information about class loading and unloading
	to event based tracing framework (hs24) - updated
In-Reply-To: <98226c25-b171-4861-9976-04de6aff5ad2@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
Message-ID: <516DFEE7.7070800@oracle.com>

Hi Markus,

On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
> Hi again,
>
> The changeset for this has been updated slightly to reflect underlying
> changes in hs24.
>
> Still looking for reviews for this change to add information about class
> loading and unloading to the event based tracing framework for HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev (updated):
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/

systemDictionary.cpp:

Minor nit: this comment, now it is split from earlier comment

801         // class_loader is NOT the defining loader, do a little more 
bookkeeping.

should say

801         // If class_loader is NOT the defining loader, do a little 
more bookkeeping.

I still find it odd that you post the event before the loader constraint 
checks are done. Not normally an issue of course. And conversely it 
seems odd that JVMTI only posts an event if we needed to do the loader 
constraint checking ???

---

traceStream.hpp

Following on to Karen's comment, so you rely on the ResourceMark being 
in the "caller" (which is the generated code in this case) ? Should that 
be documented in the file?

David
-----

> Thanks in advance
>
> Markus
>
> *From:*Markus Gr?nlund
> *Sent:* den 15 april 2013 10:17
> *To:* hotspot-runtime-dev at openjdk.java.net;
> serviceability-dev at openjdk.java.net
> *Subject:* RFR(M): 8012182: Add information about class loading and
> unloading to event based tracing framework (hs24)
>
> Greetings,
>
> Kindly asking for reviews for the change to add class load and unload
> information to the event based tracing framework to HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev:
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>
> Thanks
>
> Markus
>


From david.holmes at oracle.com  Wed Apr 17 02:16:26 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Apr 2013 12:16:26 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DF70B.6000302@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DF70B.6000302@oracle.com>
Message-ID: <516E05FA.4050804@oracle.com>

Bah! Now hotspot-runtime got left off the cc list. :(

David

On 17/04/2013 11:12 AM, David Holmes wrote:
> On 17/04/2013 7:45 AM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>>
>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a
>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric
>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear
>> when you'd want to use it.
>
> The critical difference is the invocation of the default constructor.
>
> I think we have gone done the wrong path here because we really want the
> language to handle correct allocation and initialization (and
> de-allocation, destruction) of arrays. The allocation side seems correct
> but for deallocation I see a couple of problems:
>
> a) you now need to know how big the array is so you can iterate through
> and invoke the destructor for each element. This might not be an issue
> for current usage but may be in general.
>
> b) The destruction logic is incorrect I think:
>
> ((type*)&array_name[index])->~type();
>
> This will only work correctly if the object is exactly of type "type".
> If a subclass has been stored into the array then we will invoke the
> destructor of the baseclass, due to the explicit cast to the base type.
> I don't even think a virtual destructor will be of any help there.
>
> Aside - this comment is not relevant (allocation.hpp):
>
> 637         /* placement to call dtor on type */                 \
>
>
>> The NEW_C_HEAP_OBJ call in thread.cpp could
>> use the latter and not need the call to HandleMark::initialize().    And
>> the change in handles.hpp wouldn't be needed then either.
>
> I'm not clear on the proposal here. But HandleMark is a PITA!
>
>> The rest looks good.  I see why you didn't use placement delete because
>> it isn't really supported by C++ (checking some web searching engine).
>
> Placement delete doesn't help because it doesn't involve invoking
> destructors.
>
> David
>
>> Coleen
>>
>>
>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete
>>>> expression will never use it, so I don't see how it applies. We need
>>>> to call the destructor without de-allocating and the only way I can
>>>> see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[]
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>


From jon.masamitsu at oracle.com  Wed Apr 17 06:10:25 2013
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Wed, 17 Apr 2013 06:10:25 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011173: NPG: Replace the ChunkList
	implementation with class FreeList<Metachunk>
Message-ID: <20130417061029.AAA504837A@hg.openjdk.java.net>

Changeset: df254344edf1
Author:    jmasa
Date:      2013-04-01 10:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/df254344edf1

8011173: NPG: Replace the ChunkList implementation with class FreeList<Metachunk>
Reviewed-by: mgerdin, tschatzl, johnc, coleenp

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



From thomas.schatzl at oracle.com  Wed Apr 17 07:23:47 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 17 Apr 2013 09:23:47 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <516C8D42.1030207@oracle.com>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
Message-ID: <1366183427.4102.2.camel@cirrus>

Hi,

  I had the same concerns about inconsistencies with -Xms and
-XX:InitialHeapSize, but -Xms is (apparently) defined to set both
minimum and initial heap size.
I already raised that issue in an earlier discussion.

If you have an official source that states that -Xms only sets minimum
or initial heap size, I will gladly change this. I could not find
anything; actually the documentation (java -X) for -Xms states only that it sets the initial heap size.

The observations below result from this definition.

On Mon, 2013-04-15 at 16:29 -0700, John Cuthbertson wrote:
> Hi Thomas,
> 
> Why do we treat:
> 
> java -Xms8M  -XX:InitialHeapSize=4M...
> 
> as an error while accepting:

Because -Xms sets minimum heap size to 8M, and if you then set initial
heap size to 4M there is a conflict in the general condition that
minimum <= initial <= max.

> 
> java -XX:InitialHeapSize=4M -Xms8M...
> 
> It looks inconsistent. In both cases the user has asked for an initial 
> heap size less than his requested minimum.

As mentioned, -Xms unfortunately seems to be defined to set both initial
and minimum heap size. So there is no conflict.

> 
> In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be 
> coalesced into a single line for each? This would make the setting of 
> Initial and Min consistent with the code that sets Max on line 87.
> 

Done.

See http://cr.openjdk.java.net/~tschatzl/8006088/webrev.7/ for the new
webrev.

In addition to this change I fixed the headers of the jprt test cases to
avoid some issues with jtreg. Namely precompile the used classes and
install the whitebox api class into the boot class path.

> > Bugs.sun.com:
> > http://bugs.sun.com/view_bug.do?bug_id=8006088
> >
> > JIRA:
> > https://jbs.oracle.com/bugs/browse/JDK-8006088
> >
> > Testing:
> > jprt, manual invocation of all test cases

Testing:
jprt, jtreg run of test cases

> Other than these nits - it looks good to me. Very exhaustive test case.
> 

Thanks,
  Thomas





From bengt.rutisson at oracle.com  Wed Apr 17 08:47:23 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 17 Apr 2013 10:47:23 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps for
	PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
Message-ID: <516E619B.8010405@oracle.com>


Hi all,

Can I have a couple of reviews for this very small change?

http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/

Background

A customer commented that it is hard to coordinate the information from 
PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime with 
the information from PrintGC and PrintGCDetails in stable way since the 
former flags don't include timestamps.

This patch adds time and date stamps to the output from 
PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.

Thanks,
Bengt


From thomas.schatzl at oracle.com  Wed Apr 17 09:15:10 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 17 Apr 2013 11:15:10 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E619B.8010405@oracle.com>
References: <516E619B.8010405@oracle.com>
Message-ID: <1366190110.4102.41.camel@cirrus>

Hi,

On Wed, 2013-04-17 at 10:47 +0200, Bengt Rutisson wrote:
> Hi all,
> 
> Can I have a couple of reviews for this very small change?
> 
> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
> 
> Background
> 
> A customer commented that it is hard to coordinate the information from 
> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime with 
> the information from PrintGC and PrintGCDetails in stable way since the 
> former flags don't include timestamps.
> 
> This patch adds time and date stamps to the output from 
> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.

Looks good.

Thomas



From kirk at kodewerk.com  Wed Apr 17 09:32:44 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Wed, 17 Apr 2013 11:32:44 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E619B.8010405@oracle.com>
References: <516E619B.8010405@oracle.com>
Message-ID: <E1DCD30D-4826-4A73-9A55-E201CEFAFEA0@kodewerk.com>

I know I don't get a voice in the review but I approve it!!!

-- Kirk

On 2013-04-17, at 10:47 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:

> 
> Hi all,
> 
> Can I have a couple of reviews for this very small change?
> 
> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
> 
> Background
> 
> A customer commented that it is hard to coordinate the information from PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime with the information from PrintGC and PrintGCDetails in stable way since the former flags don't include timestamps.
> 
> This patch adds time and date stamps to the output from PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
> 
> Thanks,
> Bengt



From stefan.karlsson at oracle.com  Wed Apr 17 10:02:24 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 17 Apr 2013 12:02:24 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E619B.8010405@oracle.com>
References: <516E619B.8010405@oracle.com>
Message-ID: <10621537-FA69-4043-A437-ED224C8FEE1F@oracle.com>

Looks good.

StefanK

On 17 apr 2013, at 10:47, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:

> 
> Hi all,
> 
> Can I have a couple of reviews for this very small change?
> 
> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
> 
> Background
> 
> A customer commented that it is hard to coordinate the information from PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime with the information from PrintGC and PrintGCDetails in stable way since the former flags don't include timestamps.
> 
> This patch adds time and date stamps to the output from PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
> 
> Thanks,
> Bengt


From leonid.mesnik at oracle.com  Wed Apr 17 10:16:38 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Wed, 17 Apr 2013 14:16:38 +0400
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E619B.8010405@oracle.com>
References: <516E619B.8010405@oracle.com>
Message-ID: <516E7686.7040008@oracle.com>

Bengt

Could you please add a unit test for this fix.

Leonid
On 04/17/2013 12:47 PM, Bengt Rutisson wrote:
>
> Hi all,
>
> Can I have a couple of reviews for this very small change?
>
> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>
> Background
>
> A customer commented that it is hard to coordinate the information 
> from PrintGCApplicationConcurrentTime and 
> PrintGCApplicationStoppedTime with the information from PrintGC and 
> PrintGCDetails in stable way since the former flags don't include 
> timestamps.
>
> This patch adds time and date stamps to the output from 
> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>
> Thanks,
> Bengt


-- 
Leonid Mesnik
JVM SQE



From bengt.rutisson at oracle.com  Wed Apr 17 11:01:41 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 17 Apr 2013 13:01:41 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E7686.7040008@oracle.com>
References: <516E619B.8010405@oracle.com> <516E7686.7040008@oracle.com>
Message-ID: <516E8115.9030500@oracle.com>


Leonid,

Thanks for looking at this.

On 4/17/13 12:16 PM, Leonid Mesnik wrote:
> Bengt
>
> Could you please add a unit test for this fix.

I am not too keen on writing a test for this. I see your point, but the 
fix is very small and we already have lots of code that does the same 
thing without any tests. If we should add a test I think it should be 
for PrintGCTimeStamps and PrintGCDateStamps in general. However, I don't 
think our logging is parsable enough to make such a test stable. 
Timestamps can get mixed in in the middle of lines and unexpected 
messages can be logged at almost any point in time.

Thanks,
Bengt



>
> Leonid
> On 04/17/2013 12:47 PM, Bengt Rutisson wrote:
>>
>> Hi all,
>>
>> Can I have a couple of reviews for this very small change?
>>
>> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>>
>> Background
>>
>> A customer commented that it is hard to coordinate the information 
>> from PrintGCApplicationConcurrentTime and 
>> PrintGCApplicationStoppedTime with the information from PrintGC and 
>> PrintGCDetails in stable way since the former flags don't include 
>> timestamps.
>>
>> This patch adds time and date stamps to the output from 
>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>>
>> Thanks,
>> Bengt
>
>

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

From jesper.wilhelmsson at oracle.com  Wed Apr 17 11:12:47 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 17 Apr 2013 13:12:47 +0200
Subject: Why the type of GCId in gcTrace.hpp is uint?
In-Reply-To: <F6ACE14573EC5F40AEA19AEB2F62E579017E30@CNHZ-EXMAIL-04.ali.com>
References: <F6ACE14573EC5F40AEA19AEB2F62E579017D6F@CNHZ-EXMAIL-04.ali.com>
	<5141ECE1.7000104@oracle.com>
	<F6ACE14573EC5F40AEA19AEB2F62E579017E30@CNHZ-EXMAIL-04.ali.com>
Message-ID: <516E83AF.8020203@oracle.com>

??,

I have a fix four this in review right now. I send the mail yesterday, feel free 
to have a look at it.

I changed the GC ID and Compiler ID since they are both unsigned int values. The 
Javalangthread is a long so I didn't include that in this change.
/Jesper


??(Yunda) skrev 15/3/13 3:36 AM:
> Jesper,
>
> Thanks. I think you should consider that in trace.xml the type of compileID is INTEGER and the type of javalangthread is JAVALANGTHREAD. Since they all have similar meanings( as an ID), could they be a same type?
>
> Regards,
> Yunda
>
>> -----Original Message-----
>> From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com]
>> Sent: Thursday, March 14, 2013 11:30 PM
>> To: ??(Yunda)
>> Cc: hotspot-gc-dev openjdk.java.net (hotspot-gc-dev at openjdk.java.net);
>> serviceability-dev at openjdk.java.net
>> Subject: Re: Why the type of GCId in gcTrace.hpp is uint?
>>
>> Hi Yunda,
>>
>> Thanks for reporting this! It is a bug indeed.
>> I filed CR 8010090 and will fix it asap.
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
>>
>> Thanks,
>> /Jesper
>>
>>
>> On 14/3/13 11:59 AM, ??(Yunda) wrote:
>>> Hi all,
>>>
>>> I notice that in gcTrace.hpp
>>> <http://hg.openjdk.java.net/hsx/hsx24/hotspot/file/be21f8a4d42c/src/sh
>>> are/vm/gc_implementation/shared/gcTrace.hpp>
>>> the type of GCId is unit, but in trace.xml
>>> <http://hg.openjdk.java.net/hsx/hsx24/hotspot/file/be21f8a4d42c/src/sh
>>> are/vm/gc_implementation/shared/gcTrace.hpp>
>>> the type is ULONG. Could someone tell me if there?s a special reason,
>>> or it?s just a mistake?
>>>
>>> Regards,
>>>
>>> Yunda
>>>
>>>
>>> ----------------------------------------------------------------------
>>> ----------
>>>
>>> This email (including any attachments) is confidential and may be
>>> legally privileged. If you received this email in error, please delete
>>> it immediately and do not copy it or use it for any purpose or
>>> disclose its contents to any other person. Thank you.
>>>
>>> ???(??????)??????????????????????
>> ????????
>>> ???????????????????????????????
>> ?????????
>
> ________________________________
>
> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.
>
> ???(??????)??????????????????????????????????????????????????????????????????????
>


From martin.doerr at sap.com  Wed Apr 17 12:00:11 2013
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 17 Apr 2013 12:00:11 +0000
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <516DE1AC.8030403@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516DE1AC.8030403@oracle.com>
Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165668F42E62@DEWDFEMB13A.global.corp.sap>

Hi John,

we have seen crashes when running SPEC jbb2013 on linux x86_64 with the following options (with our SAPJVM):
-XX:+UseCompressedOops -Xms8192m -Xmx8192m -Xmn1600m -XX:+UseG1GC -XX:SurvivorRatio=4

With these options, our VM uses zero based compressed oops (shift 3).

It crashed with SIGSEGV:

#  SIGSEGV (0xb) at pc=0x000000004a4c2e00, pid=1961, tid=140227895330560
# accessing faulting address: 0x000000004a4c2e00
#
# JRE version: 7.0_21
# Java VM: SAP Java Server VM (7.1.130414 23.5-b02 Apr 14 2013 19:29:41 - dev - optU - linux amd64 - 6 - bas2:193987 (mixed mode) compressed oops)
# Problematic frame:
# C  0x000000004a4c2e00 (sp=0x00007f8959e37ad8) (pc=0x000000004a4c2e00)

The same test is passing since we fixed this issue.

Best regards,
Martin


From: John Cuthbertson [mailto:john.cuthbertson at oracle.com]
Sent: Mittwoch, 17. April 2013 01:42
To: Doerr, Martin
Cc: hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc

Hi Martin,

This looks good to me. Coleen has also reviewed the change and given it the thumbs up. I'll let you get back to me regarding a test case before pushing the changes.

JohnC
On 4/16/2013 1:38 AM, Doerr, Martin wrote:
Hi all,

we found a G1 bug in the template interpreter on x86_64 and sparc with compressed Oops.
"do_oop_store" performs a "store_heap_oop" which compresses the input register.
This compressed Oop is passed to the succeeding g1_write_barrier_post, which is wrong.
Correctly, g1_write_barrier_post needs the uncompressed Oop for the heap region crossing check.

This fix preserves the uncompressed Oop in a register which gets passed to the g1_write_barrier_post:
http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/<http://cr.openjdk.java.net/%7Egoetz/webrevs/g1-cOops_bug/>

Please supply a bug id and review this change.

Kind regards,
Martin


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

From mikael.gerdin at oracle.com  Wed Apr 17 12:05:24 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 17 Apr 2013 14:05:24 +0200
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is
	set in command-line
In-Reply-To: <516571AA.60602@oracle.com>
References: <516571AA.60602@oracle.com>
Message-ID: <516E9004.7040804@oracle.com>

Kevin,

On 2013-04-10 16:05, Kevin Walls wrote:
> Hi,
>
> I'd like a review of this testcase change.  It fails as it has a GC
> option set in the jtreg tag which may conflict with what jtreg sends,
> and fail to run.
>
> Although the test was created for a CMS problem, double-counting of full
> collections, here it is adapted to check all collectors:
>
> http://cr.openjdk.java.net/~kevinw/7109087/webrev/

Since you know the number of iterations I think it would be better to 
use an ArrayList and use list.ensureCapacity(20) to avoid allocations in 
addCollectionCount.

You could also make the GarbageCollectorMXBean list available from a 
static variable since I'm not sure what happens in that call path.

Here you access theseCounts as a List instead of a List<Long>, maybe the 
"counts" map should be a Map<String, List<Long>>?

+            for (int i = 0; i < iterations - 1; i++) {
+                List theseCounts = counts.get(collector);
+                long a = (Long) theseCounts.get(i);

/Mikael


>
> Thanks
> Kevin


From coleen.phillimore at oracle.com  Wed Apr 17 12:31:37 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 17 Apr 2013 08:31:37 -0400
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E8115.9030500@oracle.com>
References: <516E619B.8010405@oracle.com> <516E7686.7040008@oracle.com>
	<516E8115.9030500@oracle.com>
Message-ID: <516E9629.3020508@oracle.com>


I think this is noreg-sqe ?   Do you have a pointer to this document?

Here is the pointer to the description for labels for regression or no
regression tests on fixed bugs:

http://openjdk.java.net/guide/changePlanning.html#bug

See Step #6


Coleen

On 4/17/2013 7:01 AM, Bengt Rutisson wrote:
>
> Leonid,
>
> Thanks for looking at this.
>
> On 4/17/13 12:16 PM, Leonid Mesnik wrote:
>> Bengt
>>
>> Could you please add a unit test for this fix.
>
> I am not too keen on writing a test for this. I see your point, but 
> the fix is very small and we already have lots of code that does the 
> same thing without any tests. If we should add a test I think it 
> should be for PrintGCTimeStamps and PrintGCDateStamps in general. 
> However, I don't think our logging is parsable enough to make such a 
> test stable. Timestamps can get mixed in in the middle of lines and 
> unexpected messages can be logged at almost any point in time.
>
> Thanks,
> Bengt
>
>
>
>>
>> Leonid
>> On 04/17/2013 12:47 PM, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Can I have a couple of reviews for this very small change?
>>>
>>> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>>>
>>> Background
>>>
>>> A customer commented that it is hard to coordinate the information 
>>> from PrintGCApplicationConcurrentTime and 
>>> PrintGCApplicationStoppedTime with the information from PrintGC and 
>>> PrintGCDetails in stable way since the former flags don't include 
>>> timestamps.
>>>
>>> This patch adds time and date stamps to the output from 
>>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>>>
>>> Thanks,
>>> Bengt
>>
>>
>

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

From kirk at kodewerk.com  Wed Apr 17 12:44:48 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Wed, 17 Apr 2013 14:44:48 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E9629.3020508@oracle.com>
References: <516E619B.8010405@oracle.com> <516E7686.7040008@oracle.com>
	<516E8115.9030500@oracle.com> <516E9629.3020508@oracle.com>
Message-ID: <47991E3C-A058-4624-8552-4F6933317D7C@kodewerk.com>

Hi,

I'm going to complain on the parsability comment  ;-). Logs are already very difficult to parse.. and adding DateStamps makes them particularly nasty. Problem is, they are inconsistently implemented across different configurations.

Regards,
Kirk
On 2013-04-17, at 2:31 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
> I think this is noreg-sqe ?   Do you have a pointer to this document?
> Here is the pointer to the description for labels for regression or no 
> regression tests on fixed bugs:
> 
> http://openjdk.java.net/guide/changePlanning.html#bug
> 
> See Step #6
> 
> Coleen
> 
> On 4/17/2013 7:01 AM, Bengt Rutisson wrote:
>> 
>> Leonid,
>> 
>> Thanks for looking at this.
>> 
>> On 4/17/13 12:16 PM, Leonid Mesnik wrote:
>>> Bengt 
>>> 
>>> Could you please add a unit test for this fix. 
>> 
>> I am not too keen on writing a test for this. I see your point, but the fix is very small and we already have lots of code that does the same thing without any tests. If we should add a test I think it should be for PrintGCTimeStamps and PrintGCDateStamps in general. However, I don't think our logging is parsable enough to make such a test stable. Timestamps can get mixed in in the middle of lines and unexpected messages can be logged at almost any point in time.
>> 
>> Thanks,
>> Bengt
>> 
>> 
>> 
>>> 
>>> Leonid 
>>> On 04/17/2013 12:47 PM, Bengt Rutisson wrote: 
>>>> 
>>>> Hi all, 
>>>> 
>>>> Can I have a couple of reviews for this very small change? 
>>>> 
>>>> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/ 
>>>> 
>>>> Background 
>>>> 
>>>> A customer commented that it is hard to coordinate the information from PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime with the information from PrintGC and PrintGCDetails in stable way since the former flags don't include timestamps. 
>>>> 
>>>> This patch adds time and date stamps to the output from PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime. 
>>>> 
>>>> Thanks, 
>>>> Bengt 
>>> 
>>> 
>> 
> 

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

From bengt.rutisson at oracle.com  Wed Apr 17 13:10:03 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 17 Apr 2013 15:10:03 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E9629.3020508@oracle.com>
References: <516E619B.8010405@oracle.com> <516E7686.7040008@oracle.com>
	<516E8115.9030500@oracle.com> <516E9629.3020508@oracle.com>
Message-ID: <516E9F2B.4050801@oracle.com>


On 4/17/13 2:31 PM, Coleen Phillimore wrote:
>
> I think this is noreg-sqe ?   Do you have a pointer to this document?
> Here is the pointer to the description for labels for regression or no
> regression tests on fixed bugs:
>
> http://openjdk.java.net/guide/changePlanning.html#bug
>
> See Step #6

Thanks, Coleen!

I tagged the bug with noreg-sqe and added a comment.

Bengt

>
> Coleen
>
> On 4/17/2013 7:01 AM, Bengt Rutisson wrote:
>>
>> Leonid,
>>
>> Thanks for looking at this.
>>
>> On 4/17/13 12:16 PM, Leonid Mesnik wrote:
>>> Bengt
>>>
>>> Could you please add a unit test for this fix.
>>
>> I am not too keen on writing a test for this. I see your point, but 
>> the fix is very small and we already have lots of code that does the 
>> same thing without any tests. If we should add a test I think it 
>> should be for PrintGCTimeStamps and PrintGCDateStamps in general. 
>> However, I don't think our logging is parsable enough to make such a 
>> test stable. Timestamps can get mixed in in the middle of lines and 
>> unexpected messages can be logged at almost any point in time.
>>
>> Thanks,
>> Bengt
>>
>>
>>
>>>
>>> Leonid
>>> On 04/17/2013 12:47 PM, Bengt Rutisson wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Can I have a couple of reviews for this very small change?
>>>>
>>>> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>>>>
>>>> Background
>>>>
>>>> A customer commented that it is hard to coordinate the information 
>>>> from PrintGCApplicationConcurrentTime and 
>>>> PrintGCApplicationStoppedTime with the information from PrintGC and 
>>>> PrintGCDetails in stable way since the former flags don't include 
>>>> timestamps.
>>>>
>>>> This patch adds time and date stamps to the output from 
>>>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>>
>>
>

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

From leonid.mesnik at oracle.com  Wed Apr 17 13:37:23 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Wed, 17 Apr 2013 17:37:23 +0400
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E9F2B.4050801@oracle.com>
References: <516E619B.8010405@oracle.com> <516E7686.7040008@oracle.com>
	<516E8115.9030500@oracle.com> <516E9629.3020508@oracle.com>
	<516E9F2B.4050801@oracle.com>
Message-ID: <516EA593.5030304@oracle.com>

Bengt

Thank you for tagging issue.
I think noreg-sqe is not correct. The fix is not really covered by 
existing tests.
However noreg-hard could be used here. (Hard to develop stable test)

Leonid

On 04/17/2013 05:10 PM, Bengt Rutisson wrote:
>
> On 4/17/13 2:31 PM, Coleen Phillimore wrote:
>>
>> I think this is noreg-sqe ?   Do you have a pointer to this document?
>> Here is the pointer to the description for labels for regression or no
>> regression tests on fixed bugs:
>>
>> http://openjdk.java.net/guide/changePlanning.html#bug
>>
>> See Step #6
>
> Thanks, Coleen!
>
> I tagged the bug with noreg-sqe and added a comment.
>
> Bengt
>
>>
>> Coleen
>>
>> On 4/17/2013 7:01 AM, Bengt Rutisson wrote:
>>>
>>> Leonid,
>>>
>>> Thanks for looking at this.
>>>
>>> On 4/17/13 12:16 PM, Leonid Mesnik wrote:
>>>> Bengt
>>>>
>>>> Could you please add a unit test for this fix.
>>>
>>> I am not too keen on writing a test for this. I see your point, but 
>>> the fix is very small and we already have lots of code that does the 
>>> same thing without any tests. If we should add a test I think it 
>>> should be for PrintGCTimeStamps and PrintGCDateStamps in general. 
>>> However, I don't think our logging is parsable enough to make such a 
>>> test stable. Timestamps can get mixed in in the middle of lines and 
>>> unexpected messages can be logged at almost any point in time.
>>>
>>> Thanks,
>>> Bengt
>>>
>>>
>>>
>>>>
>>>> Leonid
>>>> On 04/17/2013 12:47 PM, Bengt Rutisson wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Can I have a couple of reviews for this very small change?
>>>>>
>>>>> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>>>>>
>>>>> Background
>>>>>
>>>>> A customer commented that it is hard to coordinate the information 
>>>>> from PrintGCApplicationConcurrentTime and 
>>>>> PrintGCApplicationStoppedTime with the information from PrintGC 
>>>>> and PrintGCDetails in stable way since the former flags don't 
>>>>> include timestamps.
>>>>>
>>>>> This patch adds time and date stamps to the output from 
>>>>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>
>>>>
>>>
>>
>


-- 
Leonid Mesnik
JVM SQE

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

From markus.gronlund at oracle.com  Wed Apr 17 07:47:57 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 17 Apr 2013 00:47:57 -0700 (PDT)
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <516DFEE7.7070800@oracle.com>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
Message-ID: <c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>

First,

I forgot to mention in the original post that parts of this code was contributed-by:

Calvin Cheung (calvin.cheung at oracle.com) 

Calvin will be attributed to this fact in a Contributed-by: when this goes back.


Now,

"I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"

Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...

With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.


"Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"

Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.


Thanks
Markus



-----Original Message-----
From: David Holmes 
Sent: den 17 april 2013 03:46
To: Markus Gr?nlund
Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

Hi Markus,

On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
> Hi again,
>
> The changeset for this has been updated slightly to reflect underlying 
> changes in hs24.
>
> Still looking for reviews for this change to add information about 
> class loading and unloading to the event based tracing framework for HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev (updated):
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/

systemDictionary.cpp:

Minor nit: this comment, now it is split from earlier comment

801         // class_loader is NOT the defining loader, do a little more 
bookkeeping.

should say

801         // If class_loader is NOT the defining loader, do a little 
more bookkeeping.

I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???

---

traceStream.hpp

Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?

David
-----

> Thanks in advance
>
> Markus
>
> *From:*Markus Gr?nlund
> *Sent:* den 15 april 2013 10:17
> *To:* hotspot-runtime-dev at openjdk.java.net;
> serviceability-dev at openjdk.java.net
> *Subject:* RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24)
>
> Greetings,
>
> Kindly asking for reviews for the change to add class load and unload 
> information to the event based tracing framework to HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev:
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>
> Thanks
>
> Markus
>


From markus.gronlund at oracle.com  Wed Apr 17 10:41:08 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 17 Apr 2013 03:41:08 -0700 (PDT)
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
Message-ID: <51da3125-6338-44d3-8b62-7d904cec56ef@default>

Hi again,

Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.

Also updated the patch to include comments + contributions.

Webrev version 3:
http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/

BugID:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182

Many thanks for your comments.

Cheers
Markus



-----Original Message-----
From: Markus Gr?nlund 
Sent: den 17 april 2013 09:48
To: David Holmes
Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

First,

I forgot to mention in the original post that parts of this code was contributed-by:

Calvin Cheung (calvin.cheung at oracle.com) 

Calvin will be attributed to this fact in a Contributed-by: when this goes back.


Now,

"I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"

Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...

With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.


"Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"

Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.


Thanks
Markus



-----Original Message-----
From: David Holmes
Sent: den 17 april 2013 03:46
To: Markus Gr?nlund
Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

Hi Markus,

On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
> Hi again,
>
> The changeset for this has been updated slightly to reflect underlying 
> changes in hs24.
>
> Still looking for reviews for this change to add information about 
> class loading and unloading to the event based tracing framework for HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev (updated):
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/

systemDictionary.cpp:

Minor nit: this comment, now it is split from earlier comment

801         // class_loader is NOT the defining loader, do a little more 
bookkeeping.

should say

801         // If class_loader is NOT the defining loader, do a little 
more bookkeeping.

I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???

---

traceStream.hpp

Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?

David
-----

> Thanks in advance
>
> Markus
>
> *From:*Markus Gr?nlund
> *Sent:* den 15 april 2013 10:17
> *To:* hotspot-runtime-dev at openjdk.java.net;
> serviceability-dev at openjdk.java.net
> *Subject:* RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24)
>
> Greetings,
>
> Kindly asking for reviews for the change to add class load and unload 
> information to the event based tracing framework to HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev:
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>
> Thanks
>
> Markus
>


From kevin.walls at oracle.com  Wed Apr 17 15:53:53 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 17 Apr 2013 16:53:53 +0100
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is
	set in command-line
In-Reply-To: <516E9004.7040804@oracle.com>
References: <516571AA.60602@oracle.com> <516E9004.7040804@oracle.com>
Message-ID: <516EC591.5060702@oracle.com>

On 17/04/13 13:05, Mikael Gerdin wrote:
> Kevin,
>
> On 2013-04-10 16:05, Kevin Walls wrote:
>> Hi,
>>
>> I'd like a review of this testcase change.  It fails as it has a GC
>> option set in the jtreg tag which may conflict with what jtreg sends,
>> and fail to run.
>>
>> Although the test was created for a CMS problem, double-counting of full
>> collections, here it is adapted to check all collectors:
>>
>> http://cr.openjdk.java.net/~kevinw/7109087/webrev/
>
> Since you know the number of iterations I think it would be better to 
> use an ArrayList and use list.ensureCapacity(20) to avoid allocations 
> in addCollectionCount.
>
> You could also make the GarbageCollectorMXBean list available from a 
> static variable since I'm not sure what happens in that call path.
>
> Here you access theseCounts as a List instead of a List<Long>, maybe 
> the "counts" map should be a Map<String, List<Long>>?
>
> +            for (int i = 0; i < iterations - 1; i++) {
> +                List theseCounts = counts.get(collector);
> +                long a = (Long) theseCounts.get(i);
>
> /Mikael
>
>
>>
>> Thanks
>> Kevin


Hi Mikael, thanks -

ensureCapacity: not sure it stops the addCollectionCount() method 
changing/adding to the list?  We could verify the list is of the right 
length, although I don't think it's that important?...  
addCollectionCount adds one thing to the List for each collector each 
time it's called...  I don't think we can guarantee that collectors 
aren't getting invoked at any time, but we can make it unlikely, like 
the next point you make:

Yes, don't really need to call  into the ManagementFactory each 
iteration, and can reduce it to a single call to 
ManagementFactory.getGarbageCollectorMXBeans();  We don't need the 
List<MemoryPoolMXBean> at all.

Yes, those casts to Long can be eradicated.

Also there was an unused "count" variable in main(), removed it.. 8-)

And I should clone from hotspot-gc for this change.

New webrev: http://cr.openjdk.java.net/~kevinw/7109087/webrev.02/

Thanks
Kevin



From john.cuthbertson at oracle.com  Wed Apr 17 17:37:12 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 17 Apr 2013 10:37:12 -0700
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516E619B.8010405@oracle.com>
References: <516E619B.8010405@oracle.com>
Message-ID: <516EDDC8.3070404@oracle.com>

Hi Bengt,

Looks good.

JohnC

On 4/17/2013 1:47 AM, Bengt Rutisson wrote:
>
> Hi all,
>
> Can I have a couple of reviews for this very small change?
>
> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>
> Background
>
> A customer commented that it is hard to coordinate the information 
> from PrintGCApplicationConcurrentTime and 
> PrintGCApplicationStoppedTime with the information from PrintGC and 
> PrintGCDetails in stable way since the former flags don't include 
> timestamps.
>
> This patch adds time and date stamps to the output from 
> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>
> Thanks,
> Bengt



From john.cuthbertson at oracle.com  Wed Apr 17 17:46:38 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 17 Apr 2013 10:46:38 -0700
Subject: RFR (S): G1: Fix bug with compressed oops on x86_64 and sparc
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F42E62@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F42BED@DEWDFEMB13A.global.corp.sap>
	<516DE1AC.8030403@oracle.com>
	<7C9B87B351A4BA4AA9EC95BB4181165668F42E62@DEWDFEMB13A.global.corp.sap>
Message-ID: <516EDFFE.3010405@oracle.com>

Hi Martin,

Thanks for getting back to me about the test case. Although I haven't 
seen any jbb2013 failures, the fix is still good. I'll push it today.

JohnC

On 4/17/2013 5:00 AM, Doerr, Martin wrote:
>
> Hi John,
>
> we have seen crashes when running SPEC jbb2013 on linux x86_64 with 
> the following options (with our SAPJVM):
>
> -XX:+UseCompressedOops -Xms8192m -Xmx8192m -Xmn1600m -XX:+UseG1GC 
> -XX:SurvivorRatio=4
>
> With these options, our VM uses zero based compressed oops (shift 3).
>
> It crashed with SIGSEGV:
>
> #  SIGSEGV (0xb) at pc=0x000000004a4c2e00, pid=1961, tid=140227895330560
>
> # accessing faulting address: 0x000000004a4c2e00
>
> #
>
> # JRE version: 7.0_21
>
> # Java VM: SAP Java Server VM (7.1.130414 23.5-b02 Apr 14 2013 
> 19:29:41 - dev - optU - linux amd64 - 6 - bas2:193987 (mixed mode) 
> compressed oops)
>
> # Problematic frame:
>
> # C  0x000000004a4c2e00 (sp=0x00007f8959e37ad8) (pc=0x000000004a4c2e00)
>
> The same test is passing since we fixed this issue.
>
> Best regards,
>
> Martin
>
> *From:*John Cuthbertson [mailto:john.cuthbertson at oracle.com]
> *Sent:* Mittwoch, 17. April 2013 01:42
> *To:* Doerr, Martin
> *Cc:* hotspot-gc-dev at openjdk.java.net
> *Subject:* Re: RFR (S): G1: Fix bug with compressed oops on x86_64 and 
> sparc
>
> Hi Martin,
>
> This looks good to me. Coleen has also reviewed the change and given 
> it the thumbs up. I'll let you get back to me regarding a test case 
> before pushing the changes.
>
> JohnC
>
> On 4/16/2013 1:38 AM, Doerr, Martin wrote:
>
>     Hi all,
>
>     we found a G1 bug in the template interpreter on x86_64 and sparc
>     with compressed Oops.
>
>     "do_oop_store" performs a "store_heap_oop" which compresses the
>     input register.
>
>     This compressed Oop is passed to the succeeding
>     g1_write_barrier_post, which is wrong.
>
>     Correctly, g1_write_barrier_post needs the uncompressed Oop for
>     the heap region crossing check.
>
>     This fix preserves the uncompressed Oop in a register which gets
>     passed to the g1_write_barrier_post:
>
>     http://cr.openjdk.java.net/~goetz/webrevs/g1-cOops_bug/
>     <http://cr.openjdk.java.net/%7Egoetz/webrevs/g1-cOops_bug/>
>
>     Please supply a bug id and review this change.
>
>     Kind regards,
>
>     Martin
>

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

From thomas.schatzl at oracle.com  Wed Apr 17 17:53:38 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 17 Apr 2013 10:53:38 -0700 (PDT)
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
Message-ID: <2c47440e-e423-48ed-9c76-b9530a895764@default>

Hi all,

  could I have some reviews for the change for CR 7057939?

The problem presented in that CR is that if MaxNewSize is not specified on the command line, it will never be updated by the internal sizing logic.

So programs like jmap that read MaxNewSize always display uintx_max.

The patch simply updates the MaxNewSize global after the sizing logic
has been applied for all heaps (in GenCollectorPolicy and
G1CollectorPolicy) as this problem is not only specific to parallel gc.

The change for G1CollectorPolicy is slightly more complicated because there are multiple exits in the constructor of G1YoungGenSizer (where this
calculation happens).
Also depending on the sizing goals for G1, a different calculation for MaxNewSize has to be applied.

In particular, if NewRatio is defined, the MaxNewSize is MaxHeapSize divided by NewRatio, otherwise it is dependent on G1MaxNewSizePercent.

I also moved some asserts from G1YoungGenSizer to checks in argument processing as the asserts are actually mandatory (range checking).

Bugs.sun:
http://bugs.sun.com/view_bug.do?bug_id=7057939

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-7057939

Webrev:
http://cr.openjdk.java.net/~tschatzl/7057939/webrev/

Testing:
jprt, jtreg tests

Thanks,
Thomas


From yumin.qi at oracle.com  Wed Apr 17 17:54:11 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 17 Apr 2013 10:54:11 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DBA09.9070400@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
Message-ID: <516EE1C3.9010106@oracle.com>

Hi,  This version Change back the HandleMark creating in Thread creation 
back to previous version and add more comments to allocation.hpp for 
documenting the usage of newly introduced macros.

http://cr.openjdk.java.net/~minqi/8010992/webrev3

Thanks
Yumin

On 4/16/2013 1:52 PM, Yumin Qi wrote:
> Hi, all
>
>   new webrev at
>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>                     quickSort.cpp, remove conditional includes.
>
> Thanks
> Yumin
>
>
> On 4/16/2013 5:56 AM, David Holmes wrote:
>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>> Adding back compiler and gc teams
>>>>
>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>> Zhenyu,
>>>>>
>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>> Maybe you need a replacement delete operator, please check
>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>
>>>>> i can just do
>>>>>
>>>>> delete ((type *)&array_name[index]);
>>>>>
>>>>> so the destructor will be called, is this right?
>>>>
>>>> No, it will also deallocate the memory unless you use a variant of
>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>> actually deallocate the memory.
>>>>
>>> Yes, I meant placement delete operator, which takes two pointers.
>>
>> But you can only call that explicitly as a function. The delete 
>> expression will never use it, so I don't see how it applies. We need 
>> to call the destructor without de-allocating and the only way I can 
>> see to do that is to call the destructor explicitly.
>>
>> David
>> -----
>>
>>
>>> -Zhengyu
>>>
>>>
>>>> I think this is getting out of hand - if we go this path then we
>>>> should simply have a custom operator new[] and operator delete[] and
>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>> destructs and then de-allocates.
>>>>
>>>> I have no issue with calling destructors explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>> memflags)                  \
>>>>>>>   624 { \
>>>>>>>   625     if (array_name != NULL)
>>>>>>> { \
>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>> {                                 \
>>>>>>>   627         /* placement to call dtor on type
>>>>>>> */                                        \
>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>   629 } \
>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>> memflags);                                \
>>>>>>>   631 } \
>>>>>>>   632   }
>>>>>>>
>>>>>>>
>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>> new webrev at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>
>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>> Hi Yumin,
>>>>>>>>>
>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>
>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>> to it!
>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> allocation.hpp:
>>>>>>>>>
>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>> element
>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>> before deallocating ?
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>
>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>> .
>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>
>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>> Since we
>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>> which
>>>>>>>>>>>> will call ctors.
>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>> global
>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>



From tao.mao at oracle.com  Wed Apr 17 18:06:30 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 17 Apr 2013 11:06:30 -0700
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
In-Reply-To: <2c47440e-e423-48ed-9c76-b9530a895764@default>
References: <2c47440e-e423-48ed-9c76-b9530a895764@default>
Message-ID: <516EE4A6.1090108@oracle.com>

"404, Not Found" error for webrev.

Tao

On 4/17/13 10:53 AM, Thomas Schatzl wrote:
> Hi all,
>
>    could I have some reviews for the change for CR 7057939?
>
> The problem presented in that CR is that if MaxNewSize is not specified on the command line, it will never be updated by the internal sizing logic.
>
> So programs like jmap that read MaxNewSize always display uintx_max.
>
> The patch simply updates the MaxNewSize global after the sizing logic
> has been applied for all heaps (in GenCollectorPolicy and
> G1CollectorPolicy) as this problem is not only specific to parallel gc.
>
> The change for G1CollectorPolicy is slightly more complicated because there are multiple exits in the constructor of G1YoungGenSizer (where this
> calculation happens).
> Also depending on the sizing goals for G1, a different calculation for MaxNewSize has to be applied.
>
> In particular, if NewRatio is defined, the MaxNewSize is MaxHeapSize divided by NewRatio, otherwise it is dependent on G1MaxNewSizePercent.
>
> I also moved some asserts from G1YoungGenSizer to checks in argument processing as the asserts are actually mandatory (range checking).
>
> Bugs.sun:
> http://bugs.sun.com/view_bug.do?bug_id=7057939
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-7057939
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/7057939/webrev/
>
> Testing:
> jprt, jtreg tests
>
> Thanks,
> Thomas


From thomas.schatzl at oracle.com  Wed Apr 17 18:22:26 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 17 Apr 2013 20:22:26 +0200
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
In-Reply-To: <516EE4A6.1090108@oracle.com>
References: <2c47440e-e423-48ed-9c76-b9530a895764@default>
	<516EE4A6.1090108@oracle.com>
Message-ID: <1366222946.2656.0.camel@cirrus>

Hi,

On Wed, 2013-04-17 at 11:06 -0700, Tao Mao wrote:
> "404, Not Found" error for webrev.
> 

Fixed. Moved from / to webrev.

Sorry,
Thomas




From rednaxelafx at gmail.com  Wed Apr 17 18:33:43 2013
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Thu, 18 Apr 2013 02:33:43 +0800
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
In-Reply-To: <2c47440e-e423-48ed-9c76-b9530a895764@default>
References: <2c47440e-e423-48ed-9c76-b9530a895764@default>
Message-ID: <CA+cQ+tQbQY75T9is_VoNwkC57TPB5vtmayJnv-shkhmEFFqUAA@mail.gmail.com>

Hi Thomas,

Could the same kind of update be done for OldSize and SurvivorRatio?
For OldSize, if it's not explicitly set then it'll always show a default
value which is like 5MB or something, regardless of the collector used.
For SurvivorRatio, when using UseParallelGC or UseParallelOldGC, if it's
not explicitly set then InitialSurvivorRatio is the flag that actually
takes effect. It's better if SurvivorRatio could be updated accordingly too.

Thanks,
Kris



On Thu, Apr 18, 2013 at 1:53 AM, Thomas Schatzl
<thomas.schatzl at oracle.com>wrote:

> Hi all,
>
>   could I have some reviews for the change for CR 7057939?
>
> The problem presented in that CR is that if MaxNewSize is not specified on
> the command line, it will never be updated by the internal sizing logic.
>
> So programs like jmap that read MaxNewSize always display uintx_max.
>
> The patch simply updates the MaxNewSize global after the sizing logic
> has been applied for all heaps (in GenCollectorPolicy and
> G1CollectorPolicy) as this problem is not only specific to parallel gc.
>
> The change for G1CollectorPolicy is slightly more complicated because
> there are multiple exits in the constructor of G1YoungGenSizer (where this
> calculation happens).
> Also depending on the sizing goals for G1, a different calculation for
> MaxNewSize has to be applied.
>
> In particular, if NewRatio is defined, the MaxNewSize is MaxHeapSize
> divided by NewRatio, otherwise it is dependent on G1MaxNewSizePercent.
>
> I also moved some asserts from G1YoungGenSizer to checks in argument
> processing as the asserts are actually mandatory (range checking).
>
> Bugs.sun:
> http://bugs.sun.com/view_bug.do?bug_id=7057939
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-7057939
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/7057939/webrev/
>
> Testing:
> jprt, jtreg tests
>
> Thanks,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130418/beff3e34/attachment.htm>

From markus.gronlund at oracle.com  Wed Apr 17 17:39:51 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 17 Apr 2013 10:39:51 -0700 (PDT)
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <51da3125-6338-44d3-8b62-7d904cec56ef@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
Message-ID: <3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>

Hi again,

Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...

Event notification now posted after check_constraints and exception checks.

Webrev version 4:
http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/


BugID:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182

Thanks again
Markus


-----Original Message-----
From: Markus Gr?nlund 
Sent: den 17 april 2013 12:41
To: David Holmes; Karen Kinnear
Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

Hi again,

Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.

Also updated the patch to include comments + contributions.

Webrev version 3:
http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/

BugID:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182

Many thanks for your comments.

Cheers
Markus



-----Original Message-----
From: Markus Gr?nlund
Sent: den 17 april 2013 09:48
To: David Holmes
Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

First,

I forgot to mention in the original post that parts of this code was contributed-by:

Calvin Cheung (calvin.cheung at oracle.com) 

Calvin will be attributed to this fact in a Contributed-by: when this goes back.


Now,

"I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"

Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...

With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.


"Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"

Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.


Thanks
Markus



-----Original Message-----
From: David Holmes
Sent: den 17 april 2013 03:46
To: Markus Gr?nlund
Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

Hi Markus,

On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
> Hi again,
>
> The changeset for this has been updated slightly to reflect underlying 
> changes in hs24.
>
> Still looking for reviews for this change to add information about 
> class loading and unloading to the event based tracing framework for HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev (updated):
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/

systemDictionary.cpp:

Minor nit: this comment, now it is split from earlier comment

801         // class_loader is NOT the defining loader, do a little more 
bookkeeping.

should say

801         // If class_loader is NOT the defining loader, do a little 
more bookkeeping.

I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???

---

traceStream.hpp

Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?

David
-----

> Thanks in advance
>
> Markus
>
> *From:*Markus Gr?nlund
> *Sent:* den 15 april 2013 10:17
> *To:* hotspot-runtime-dev at openjdk.java.net;
> serviceability-dev at openjdk.java.net
> *Subject:* RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24)
>
> Greetings,
>
> Kindly asking for reviews for the change to add class load and unload 
> information to the event based tracing framework to HS24.
>
> BugID:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Webrev:
>
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>
> Thanks
>
> Markus
>


From serguei.spitsyn at oracle.com  Wed Apr 17 18:44:49 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 17 Apr 2013 11:44:49 -0700
Subject: RFR(M): 8012182: Add information about class loading and unloading
	to event based tracing framework (hs24) - updated
In-Reply-To: <3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
Message-ID: <516EEDA1.8080606@oracle.com>

Hi Markus,

Not a thorough review but it looks good to me.
Just one question.

Did you want to put the post_class_load_event function body also under 
#if condition?
The same way as it is done for post_class_unload_events:

2634 void SystemDictionary::post_class_unload_events(BoolObjectClosure* is_alive) {
2635 #if INCLUDE_TRACE
. . .
2650 #endif /* INCLUDE_TRACE */
2651 }


Thanks,
Serguei


On 4/17/13 10:39 AM, Markus Gr?nlund wrote:
> Hi again,
>
> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>
> Event notification now posted after check_constraints and exception checks.
>
> Webrev version 4:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Thanks again
> Markus
>
>
> -----Original Message-----
> From: Markus Gr?nlund
> Sent: den 17 april 2013 12:41
> To: David Holmes; Karen Kinnear
> Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> Hi again,
>
> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>
> Also updated the patch to include comments + contributions.
>
> Webrev version 3:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Many thanks for your comments.
>
> Cheers
> Markus
>
>
>
> -----Original Message-----
> From: Markus Gr?nlund
> Sent: den 17 april 2013 09:48
> To: David Holmes
> Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> First,
>
> I forgot to mention in the original post that parts of this code was contributed-by:
>
> Calvin Cheung (calvin.cheung at oracle.com)
>
> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>
>
> Now,
>
> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>
> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>
> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>
>
> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>
> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 17 april 2013 03:46
> To: Markus Gr?nlund
> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> Hi Markus,
>
> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> The changeset for this has been updated slightly to reflect underlying
>> changes in hs24.
>>
>> Still looking for reviews for this change to add information about
>> class loading and unloading to the event based tracing framework for HS24.
>>
>> BugID:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Webrev (updated):
>>
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
> systemDictionary.cpp:
>
> Minor nit: this comment, now it is split from earlier comment
>
> 801         // class_loader is NOT the defining loader, do a little more
> bookkeeping.
>
> should say
>
> 801         // If class_loader is NOT the defining loader, do a little
> more bookkeeping.
>
> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>
> ---
>
> traceStream.hpp
>
> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>
> David
> -----
>
>> Thanks in advance
>>
>> Markus
>>
>> *From:*Markus Gr?nlund
>> *Sent:* den 15 april 2013 10:17
>> *To:* hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net
>> *Subject:* RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24)
>>
>> Greetings,
>>
>> Kindly asking for reviews for the change to add class load and unload
>> information to the event based tracing framework to HS24.
>>
>> BugID:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>
>> Thanks
>>
>> Markus
>>

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

From coleen.phillimore at oracle.com  Wed Apr 17 21:35:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 17 Apr 2013 17:35:32 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516EE1C3.9010106@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com>
Message-ID: <516F15A4.8000309@oracle.com>


I still think this looks great.  Thanks for adding the comments.
Coleen

On 4/17/2013 1:54 PM, Yumin Qi wrote:
> Hi, This version Change back the HandleMark creating in Thread 
> creation back to previous version and add more comments to 
> allocation.hpp for documenting the usage of newly introduced macros.
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
> Thanks
> Yumin
>
> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete 
>>> expression will never use it, so I don't see how it applies. We need 
>>> to call the destructor without de-allocating and the only way I can 
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>> leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>> dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>> what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] 
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>



From yumin.qi at oracle.com  Wed Apr 17 22:30:47 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 17 Apr 2013 15:30:47 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516F15A4.8000309@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F15A4.8000309@oracle.com>
Message-ID: <516F2297.9010604@oracle.com>

Thanks Coleen!

On 4/17/2013 2:35 PM, Coleen Phillimore wrote:
>
> I still think this looks great.  Thanks for adding the comments.
> Coleen
>
> On 4/17/2013 1:54 PM, Yumin Qi wrote:
>> Hi, This version Change back the HandleMark creating in Thread 
>> creation back to previous version and add more comments to 
>> allocation.hpp for documenting the usage of newly introduced macros.
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>> Thanks
>> Yumin
>>
>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete 
>>>> expression will never use it, so I don't see how it applies. We 
>>>> need to call the destructor without de-allocating and the only way 
>>>> I can see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>



From john.cuthbertson at oracle.com  Thu Apr 18 00:17:01 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Thu, 18 Apr 2013 00:17:01 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8012335: G1: Fix bug with compressed oops
	in template interpreter on x86 and sparc.
Message-ID: <20130418001707.2D002483E5@hg.openjdk.java.net>

Changeset: f2e682ef3156
Author:    johnc
Date:      2013-04-17 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f2e682ef3156

8012335: G1: Fix bug with compressed oops in template interpreter on x86 and sparc.
Summary: In do_oop_store the uncompressed value of the oop being stored needs to be preserved and passed to g1_write_barrier_post. This is necessary for the heap region cross check to work correctly.
Reviewed-by: coleenp, johnc
Contributed-by: Martin Doerr <martin.doerr at sap.com>

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp



From david.holmes at oracle.com  Thu Apr 18 02:41:46 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 12:41:46 +1000
Subject: RFR(M): 8012182: Add information about class loading and unloading
	to event based tracing framework (hs24) - updated
In-Reply-To: <3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
Message-ID: <516F5D6A.4060608@oracle.com>

On 18/04/2013 3:39 AM, Markus Gr?nlund wrote:
> Hi again,
>
> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>
> Event notification now posted after check_constraints and exception checks.

Okay that seems fine.

I just have the same query as Serguei as to why the unload code is 
conditional on INCLUDE_TRACE but the load code isnt ??

Thanks,
David

> Webrev version 4:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Thanks again
> Markus
>
>
> -----Original Message-----
> From: Markus Gr?nlund
> Sent: den 17 april 2013 12:41
> To: David Holmes; Karen Kinnear
> Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> Hi again,
>
> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>
> Also updated the patch to include comments + contributions.
>
> Webrev version 3:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Many thanks for your comments.
>
> Cheers
> Markus
>
>
>
> -----Original Message-----
> From: Markus Gr?nlund
> Sent: den 17 april 2013 09:48
> To: David Holmes
> Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> First,
>
> I forgot to mention in the original post that parts of this code was contributed-by:
>
> Calvin Cheung (calvin.cheung at oracle.com)
>
> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>
>
> Now,
>
> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>
> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>
> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>
>
> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>
> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 17 april 2013 03:46
> To: Markus Gr?nlund
> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> Hi Markus,
>
> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> The changeset for this has been updated slightly to reflect underlying
>> changes in hs24.
>>
>> Still looking for reviews for this change to add information about
>> class loading and unloading to the event based tracing framework for HS24.
>>
>> BugID:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Webrev (updated):
>>
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>
> systemDictionary.cpp:
>
> Minor nit: this comment, now it is split from earlier comment
>
> 801         // class_loader is NOT the defining loader, do a little more
> bookkeeping.
>
> should say
>
> 801         // If class_loader is NOT the defining loader, do a little
> more bookkeeping.
>
> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>
> ---
>
> traceStream.hpp
>
> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>
> David
> -----
>
>> Thanks in advance
>>
>> Markus
>>
>> *From:*Markus Gr?nlund
>> *Sent:* den 15 april 2013 10:17
>> *To:* hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net
>> *Subject:* RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24)
>>
>> Greetings,
>>
>> Kindly asking for reviews for the change to add class load and unload
>> information to the event based tracing framework to HS24.
>>
>> BugID:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>
>> Thanks
>>
>> Markus
>>


From david.holmes at oracle.com  Thu Apr 18 02:52:05 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 12:52:05 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516EE1C3.9010106@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com>
Message-ID: <516F5FD5.8020406@oracle.com>

Hi Yumin,

Only thing missing - as discussed - is that HandleMark should now extend 
StackObj, with a comment about the special CHeap HandleMark in thread.

Thanks for your perseverance on this.

David

On 18/04/2013 3:54 AM, Yumin Qi wrote:
> Hi,  This version Change back the HandleMark creating in Thread creation
> back to previous version and add more comments to allocation.hpp for
> documenting the usage of newly introduced macros.
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
> Thanks
> Yumin
>
> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete
>>> expression will never use it, so I don't see how it applies. We need
>>> to call the destructor without de-allocating and the only way I can
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>


From yunda.mly at taobao.com  Thu Apr 18 03:12:16 2013
From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=)
Date: Thu, 18 Apr 2013 03:12:16 +0000
Subject: Why the type of GCId in gcTrace.hpp is uint?
In-Reply-To: <516E83AF.8020203@oracle.com>
References: <F6ACE14573EC5F40AEA19AEB2F62E579017D6F@CNHZ-EXMAIL-04.ali.com>
	<5141ECE1.7000104@oracle.com>
	<F6ACE14573EC5F40AEA19AEB2F62E579017E30@CNHZ-EXMAIL-04.ali.com>
	<516E83AF.8020203@oracle.com>
Message-ID: <F6ACE14573EC5F40AEA19AEB2F62E57901C2A2@CNHZ-EXMAIL-04.ali.com>

Jesper,

Thanks and I'll have a look at it.

Regards,
Yunda


> -----Original Message-----
> From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com]
> Sent: Wednesday, April 17, 2013 7:13 PM
> To: ??(Yunda)
> Cc: hotspot-gc-dev openjdk.java.net (hotspot-gc-dev at openjdk.java.net);
> serviceability-dev at openjdk.java.net
> Subject: Re: Why the type of GCId in gcTrace.hpp is uint?
>
> ??,
>
> I have a fix four this in review right now. I send the mail yesterday, feel free to
> have a look at it.
>
> I changed the GC ID and Compiler ID since they are both unsigned int values.
> The Javalangthread is a long so I didn't include that in this change.
> /Jesper
>
>
> ??(Yunda) skrev 15/3/13 3:36 AM:
> > Jesper,
> >
> > Thanks. I think you should consider that in trace.xml the type of compileID is
> INTEGER and the type of javalangthread is JAVALANGTHREAD. Since they all
> have similar meanings( as an ID), could they be a same type?
> >
> > Regards,
> > Yunda
> >
> >> -----Original Message-----
> >> From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com]
> >> Sent: Thursday, March 14, 2013 11:30 PM
> >> To: ??(Yunda)
> >> Cc: hotspot-gc-dev openjdk.java.net (hotspot-gc-dev at openjdk.java.net);
> >> serviceability-dev at openjdk.java.net
> >> Subject: Re: Why the type of GCId in gcTrace.hpp is uint?
> >>
> >> Hi Yunda,
> >>
> >> Thanks for reporting this! It is a bug indeed.
> >> I filed CR 8010090 and will fix it asap.
> >>
> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
> >>
> >> Thanks,
> >> /Jesper
> >>
> >>
> >> On 14/3/13 11:59 AM, ??(Yunda) wrote:
> >>> Hi all,
> >>>
> >>> I notice that in gcTrace.hpp
> >>> <http://hg.openjdk.java.net/hsx/hsx24/hotspot/file/be21f8a4d42c/src/sh
> >>> are/vm/gc_implementation/shared/gcTrace.hpp>
> >>> the type of GCId is unit, but in trace.xml
> >>> <http://hg.openjdk.java.net/hsx/hsx24/hotspot/file/be21f8a4d42c/src/sh
> >>> are/vm/gc_implementation/shared/gcTrace.hpp>
> >>> the type is ULONG. Could someone tell me if there?s a special reason,
> >>> or it?s just a mistake?
> >>>
> >>> Regards,
> >>>
> >>> Yunda
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> ----------
> >>>
> >>> This email (including any attachments) is confidential and may be
> >>> legally privileged. If you received this email in error, please delete
> >>> it immediately and do not copy it or use it for any purpose or
> >>> disclose its contents to any other person. Thank you.
> >>>
> >>> ???(??????)?????????????????????
> ?
> >> ????????
> >>> ??????????????????????????????
> ?
> >> ?????????
> >
> > ________________________________
> >
> > This email (including any attachments) is confidential and may be legally
> privileged. If you received this email in error, please delete it immediately and
> do not copy it or use it for any purpose or disclose its contents to any other
> person. Thank you.
>
> >
> > ???(??????)??????????????????????
> ????????????????????????????????
> ????????????????
> >

________________________________

This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.

???(??????)??????????????????????????????????????????????????????????????????????

From yunda.mly at taobao.com  Thu Apr 18 03:48:16 2013
From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=)
Date: Thu, 18 Apr 2013 03:48:16 +0000
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: <516D5D57.2060804@oracle.com>
References: <516D5D57.2060804@oracle.com>
Message-ID: <F6ACE14573EC5F40AEA19AEB2F62E57901C309@CNHZ-EXMAIL-04.ali.com>

Jesper,

I think the GC part looks good. But I found the value put into Compile ID is actually int, not uint(share/vm/opto/compile.hpp):
470   int               compile_id() const          { return _compile_id; }
Are you sure it is non-negative?


Regards,
Yunda


> -----Original Message-----
> From: hotspot-gc-dev-bounces at openjdk.java.net
> [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jesper
> Wilhelmsson
> Sent: Tuesday, April 16, 2013 10:17 PM
> To: hotspot-gc-dev openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Subject: RFR (S): 8010090 - GC ID has the wrong type
>
> Hi,
>
> Could I have a couple of reviews for this really small change.
>
> The type of the GC ID and the Compile ID in the different tracing events should
> be UINT as the values put into these fields are uint.
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
>
> Thanks,
> /Jesper

________________________________

This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.

???(??????)??????????????????????????????????????????????????????????????????????

From bengt.rutisson at oracle.com  Thu Apr 18 05:55:06 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 18 Apr 2013 07:55:06 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <516EA593.5030304@oracle.com>
References: <516E619B.8010405@oracle.com> <516E7686.7040008@oracle.com>
	<516E8115.9030500@oracle.com> <516E9629.3020508@oracle.com>
	<516E9F2B.4050801@oracle.com> <516EA593.5030304@oracle.com>
Message-ID: <516F8ABA.1040902@oracle.com>


Thanks, Leonid!

I updated the bug to have the noreg-hard tag.

Bengt

On 4/17/13 3:37 PM, Leonid Mesnik wrote:
> Bengt
>
> Thank you for tagging issue.
> I think noreg-sqe is not correct. The fix is not really covered by 
> existing tests.
> However noreg-hard could be used here. (Hard to develop stable test)
>
> Leonid
>
> On 04/17/2013 05:10 PM, Bengt Rutisson wrote:
>>
>> On 4/17/13 2:31 PM, Coleen Phillimore wrote:
>>>
>>> I think this is noreg-sqe ?   Do you have a pointer to this document?
>>> Here is the pointer to the description for labels for regression or no
>>> regression tests on fixed bugs:
>>>
>>> http://openjdk.java.net/guide/changePlanning.html#bug
>>>
>>> See Step #6
>>
>> Thanks, Coleen!
>>
>> I tagged the bug with noreg-sqe and added a comment.
>>
>> Bengt
>>
>>>
>>> Coleen
>>>
>>> On 4/17/2013 7:01 AM, Bengt Rutisson wrote:
>>>>
>>>> Leonid,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> On 4/17/13 12:16 PM, Leonid Mesnik wrote:
>>>>> Bengt
>>>>>
>>>>> Could you please add a unit test for this fix.
>>>>
>>>> I am not too keen on writing a test for this. I see your point, but 
>>>> the fix is very small and we already have lots of code that does 
>>>> the same thing without any tests. If we should add a test I think 
>>>> it should be for PrintGCTimeStamps and PrintGCDateStamps in 
>>>> general. However, I don't think our logging is parsable enough to 
>>>> make such a test stable. Timestamps can get mixed in in the middle 
>>>> of lines and unexpected messages can be logged at almost any point 
>>>> in time.
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>
>>>>
>>>>>
>>>>> Leonid
>>>>> On 04/17/2013 12:47 PM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Can I have a couple of reviews for this very small change?
>>>>>>
>>>>>> http://cr.openjdk.java.net/~brutisso/8012455/webrev.00/
>>>>>>
>>>>>> Background
>>>>>>
>>>>>> A customer commented that it is hard to coordinate the 
>>>>>> information from PrintGCApplicationConcurrentTime and 
>>>>>> PrintGCApplicationStoppedTime with the information from PrintGC 
>>>>>> and PrintGCDetails in stable way since the former flags don't 
>>>>>> include timestamps.
>>>>>>
>>>>>> This patch adds time and date stamps to the output from 
>>>>>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -- 
> Leonid Mesnik
> JVM SQE

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

From bengt.rutisson at oracle.com  Thu Apr 18 05:59:00 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 18 Apr 2013 07:59:00 +0200
Subject: Request for review (XS): 8012455: Missing time and date stamps
	for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
In-Reply-To: <CAAnWq9CnjOUaoxbXVMFUYwD94GvYAisKxs=6gbA2h0rdc=BRsA@mail.gmail.com>
References: <516E619B.8010405@oracle.com>
	<CAAnWq9CnjOUaoxbXVMFUYwD94GvYAisKxs=6gbA2h0rdc=BRsA@mail.gmail.com>
Message-ID: <516F8BA4.7060501@oracle.com>


Thanks Thomas, Kirk, Stefan, John and Brandon for the reviews!

Bengt

On 4/17/13 7:50 PM, Brandon Mitchell wrote:
> On Wed, Apr 17, 2013 at 1:47 AM, Bengt Rutisson
> <bengt.rutisson at oracle.com> wrote:
>> A customer commented that it is hard to coordinate the information from
>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime with the
>> information from PrintGC and PrintGCDetails in stable way since the former
>> flags don't include timestamps.
>>
>> This patch adds time and date stamps to the output from
>> PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime.
> We added the same patch at Twitter. Very useful. :-)
>
> Brandon



From jesper.wilhelmsson at oracle.com  Thu Apr 18 07:36:51 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 18 Apr 2013 09:36:51 +0200
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: <F6ACE14573EC5F40AEA19AEB2F62E57901C309@CNHZ-EXMAIL-04.ali.com>
References: <516D5D57.2060804@oracle.com>
	<F6ACE14573EC5F40AEA19AEB2F62E57901C309@CNHZ-EXMAIL-04.ali.com>
Message-ID: <516FA293.8080607@oracle.com>

??,

Thanks for looking at this!

Looking at the code, it is not that easy to determine the intention when it 
comes to the signedness of compile id. But judging from the original variable it 
should be unsigned.

The original variable in which the compile id is stored, _compile_id in the 
class CompileTask, is a uint. The method compile_id() that is its getter has the 
return type int (this is likely a bug).

In CompileBroker::invoke_compiler_on_method, compile_id() is called and the 
result is stored in compile_id which is a uint. The variable compile_id is then 
used to populate the compileID in the Compilation event which used to be INTEGER 
(signed) but is about to become a UINT. Nils Eliasson from the compiler team has 
approved this change.

Thanks,
/Jesper


??(Yunda) skrev 18/4/13 5:48 AM:
> Jesper,
>
> I think the GC part looks good. But I found the value put into Compile ID is actually int, not uint(share/vm/opto/compile.hpp):
> 470   int               compile_id() const          { return _compile_id; }
> Are you sure it is non-negative?
>
>
> Regards,
> Yunda
>
>
>> -----Original Message-----
>> From: hotspot-gc-dev-bounces at openjdk.java.net
>> [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jesper
>> Wilhelmsson
>> Sent: Tuesday, April 16, 2013 10:17 PM
>> To: hotspot-gc-dev openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
>> Subject: RFR (S): 8010090 - GC ID has the wrong type
>>
>> Hi,
>>
>> Could I have a couple of reviews for this really small change.
>>
>> The type of the GC ID and the Compile ID in the different tracing events should
>> be UINT as the values put into these fields are uint.
>>
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
>>
>> Thanks,
>> /Jesper
>
> ________________________________
>
> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.
>
> ???(??????)??????????????????????????????????????????????????????????????????????
>


From bengt.rutisson at oracle.com  Thu Apr 18 07:42:09 2013
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Thu, 18 Apr 2013 07:42:09 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8012455: Missing time and date stamps for
	PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
Message-ID: <20130418074211.516A4483F6@hg.openjdk.java.net>

Changeset: 07a4efc5ed14
Author:    brutisso
Date:      2013-04-18 06:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/07a4efc5ed14

8012455: Missing time and date stamps for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
Summary: also reviewed by: kirk at kodewerk.com, brandon at twitter.com
Reviewed-by: tschatzl, stefank, johnc

! src/share/vm/services/runtimeService.cpp



From yumin.qi at oracle.com  Thu Apr 18 07:53:31 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 18 Apr 2013 00:53:31 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516F5FD5.8020406@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F5FD5.8020406@oracle.com>
Message-ID: <516FA67B.20308@oracle.com>

Thanks Coleen and David, I update the webrev (same URL) for 
HandleMark(handles.hpp) and also several files' Copyright year.

Thanks
Yumin

On 4/17/2013 7:52 PM, David Holmes wrote:
> Hi Yumin,
>
> Only thing missing - as discussed - is that HandleMark should now 
> extend StackObj, with a comment about the special CHeap HandleMark in 
> thread.
>
> Thanks for your perseverance on this.
>
> David
>
> On 18/04/2013 3:54 AM, Yumin Qi wrote:
>> Hi,  This version Change back the HandleMark creating in Thread creation
>> back to previous version and add more comments to allocation.hpp for
>> documenting the usage of newly introduced macros.
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>> Thanks
>> Yumin
>>
>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete
>>>> expression will never use it, so I don't see how it applies. We need
>>>> to call the destructor without de-allocating and the only way I can
>>>> see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>



From yunda.mly at taobao.com  Thu Apr 18 08:05:53 2013
From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=)
Date: Thu, 18 Apr 2013 08:05:53 +0000
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: <516FA293.8080607@oracle.com>
References: <516D5D57.2060804@oracle.com>
	<F6ACE14573EC5F40AEA19AEB2F62E57901C309@CNHZ-EXMAIL-04.ali.com>
	<516FA293.8080607@oracle.com>
Message-ID: <F6ACE14573EC5F40AEA19AEB2F62E57901C3FD@CNHZ-EXMAIL-04.ali.com>

Jesper,

Thanks for your clear explanation and I think you are right that it's a bug that the method compile_id() doesn't have the return type unit.

Regards,
Yunda


> -----Original Message-----
> From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com]
> Sent: Thursday, April 18, 2013 3:37 PM
> To: ??(Yunda)
> Cc: hotspot-gc-dev openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (S): 8010090 - GC ID has the wrong type
>
> ??,
>
> Thanks for looking at this!
>
> Looking at the code, it is not that easy to determine the intention when it
> comes to the signedness of compile id. But judging from the original variable it
> should be unsigned.
>
> The original variable in which the compile id is stored, _compile_id in the class
> CompileTask, is a uint. The method compile_id() that is its getter has the return
> type int (this is likely a bug).
>
> In CompileBroker::invoke_compiler_on_method, compile_id() is called and the
> result is stored in compile_id which is a uint. The variable compile_id is then
> used to populate the compileID in the Compilation event which used to be
> INTEGER
> (signed) but is about to become a UINT. Nils Eliasson from the compiler team
> has approved this change.
>
> Thanks,
> /Jesper
>
>
> ??(Yunda) skrev 18/4/13 5:48 AM:
> > Jesper,
> >
> > I think the GC part looks good. But I found the value put into Compile ID is
> actually int, not uint(share/vm/opto/compile.hpp):
> > 470   int               compile_id() const          { return
> _compile_id; }
> > Are you sure it is non-negative?
> >
> >
> > Regards,
> > Yunda
> >
> >
> >> -----Original Message-----
> >> From: hotspot-gc-dev-bounces at openjdk.java.net
> >> [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jesper
> >> Wilhelmsson
> >> Sent: Tuesday, April 16, 2013 10:17 PM
> >> To: hotspot-gc-dev openjdk.java.net;
> >> hotspot-compiler-dev at openjdk.java.net
> >> Subject: RFR (S): 8010090 - GC ID has the wrong type
> >>
> >> Hi,
> >>
> >> Could I have a couple of reviews for this really small change.
> >>
> >> The type of the GC ID and the Compile ID in the different tracing
> >> events should be UINT as the values put into these fields are uint.
> >>
> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/
> >>
> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
> >>
> >> Thanks,
> >> /Jesper
> >
> > ________________________________
> >
> > This email (including any attachments) is confidential and may be legally
> privileged. If you received this email in error, please delete it immediately and
> do not copy it or use it for any purpose or disclose its contents to any other
> person. Thank you.
>
> >
> > ???(??????)??????????????????????
> ????????????????????????????????
> ?????
> > ???????????
> >

________________________________

This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.

???(??????)??????????????????????????????????????????????????????????????????????

From david.holmes at oracle.com  Thu Apr 18 10:27:52 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 20:27:52 +1000
Subject: RFR(M): 8012182: Add information about class loading and unloading
	to event based tracing framework (hs24) - updated
In-Reply-To: <a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
	<516F5D6A.4060608@oracle.com>
	<a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>
Message-ID: <516FCAA8.4090201@oracle.com>

Looks good to me.

Thanks,
David

On 18/04/2013 3:46 PM, Markus Gr?nlund wrote:
> Thanks David and Sergeui,
>
> I have added (back) the INCLUDE_TRACE for the load code.
>
> Webrev version 5:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev05/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 18 april 2013 04:42
> To: Markus Gr?nlund
> Cc: Karen Kinnear; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> On 18/04/2013 3:39 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>>
>> Event notification now posted after check_constraints and exception checks.
>
> Okay that seems fine.
>
> I just have the same query as Serguei as to why the unload code is conditional on INCLUDE_TRACE but the load code isnt ??
>
> Thanks,
> David
>
>> Webrev version 4:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>>
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Thanks again
>> Markus
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 12:41
>> To: David Holmes; Karen Kinnear
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi again,
>>
>> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>>
>> Also updated the patch to include comments + contributions.
>>
>> Webrev version 3:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Many thanks for your comments.
>>
>> Cheers
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 09:48
>> To: David Holmes
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24) - updated
>>
>> First,
>>
>> I forgot to mention in the original post that parts of this code was contributed-by:
>>
>> Calvin Cheung (calvin.cheung at oracle.com)
>>
>> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>>
>>
>> Now,
>>
>> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>>
>> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>>
>> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>>
>>
>> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>>
>> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>>
>>
>> Thanks
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: den 17 april 2013 03:46
>> To: Markus Gr?nlund
>> Cc: hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi Markus,
>>
>> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>>> Hi again,
>>>
>>> The changeset for this has been updated slightly to reflect
>>> underlying changes in hs24.
>>>
>>> Still looking for reviews for this change to add information about
>>> class loading and unloading to the event based tracing framework for HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev (updated):
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>>
>> systemDictionary.cpp:
>>
>> Minor nit: this comment, now it is split from earlier comment
>>
>> 801         // class_loader is NOT the defining loader, do a little more
>> bookkeeping.
>>
>> should say
>>
>> 801         // If class_loader is NOT the defining loader, do a little
>> more bookkeeping.
>>
>> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>>
>> ---
>>
>> traceStream.hpp
>>
>> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>>
>> David
>> -----
>>
>>> Thanks in advance
>>>
>>> Markus
>>>
>>> *From:*Markus Gr?nlund
>>> *Sent:* den 15 april 2013 10:17
>>> *To:* hotspot-runtime-dev at openjdk.java.net;
>>> serviceability-dev at openjdk.java.net
>>> *Subject:* RFR(M): 8012182: Add information about class loading and
>>> unloading to event based tracing framework (hs24)
>>>
>>> Greetings,
>>>
>>> Kindly asking for reviews for the change to add class load and unload
>>> information to the event based tracing framework to HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>>
>>> Thanks
>>>
>>> Markus
>>>


From thomas.schatzl at oracle.com  Thu Apr 18 13:13:30 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 18 Apr 2013 15:13:30 +0200
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
In-Reply-To: <CA+cQ+tQbQY75T9is_VoNwkC57TPB5vtmayJnv-shkhmEFFqUAA@mail.gmail.com>
References: <2c47440e-e423-48ed-9c76-b9530a895764@default>
	<CA+cQ+tQbQY75T9is_VoNwkC57TPB5vtmayJnv-shkhmEFFqUAA@mail.gmail.com>
Message-ID: <1366290810.2927.9.camel@cirrus>

Hi,

On Thu, 2013-04-18 at 02:33 +0800, Krystal Mok wrote:
> Hi Thomas,
>
> Could the same kind of update be done for OldSize and SurvivorRatio?
> For OldSize, if it's not explicitly set then it'll always show a
> default value which is like 5MB or something, regardless of the
> collector used.

Going with the naming convention, OldSize would show the initial old
generation size.

> For SurvivorRatio, when using UseParallelGC or UseParallelOldGC, if
> it's not explicitly set then InitialSurvivorRatio is the flag that
> actually takes effect. It's better if SurvivorRatio could be updated
> accordingly too.

I think all collectors show these problems, just like in the MaxNewSize
case.

I created a CR which will become available later at
http://bugs.sun.com/view_bug.do?bug_id=8012591 . It is a bit more
generic as it requests to look at the other flags directly printed by
jmap as well.

Hth,
Thomas




From mikael.gerdin at oracle.com  Thu Apr 18 13:32:15 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 18 Apr 2013 15:32:15 +0200
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is
	set in command-line
In-Reply-To: <516EC591.5060702@oracle.com>
References: <516571AA.60602@oracle.com> <516E9004.7040804@oracle.com>
	<516EC591.5060702@oracle.com>
Message-ID: <516FF5DF.3070708@oracle.com>

Kevin,

On 04/17/2013 05:53 PM, Kevin Walls wrote:
> On 17/04/13 13:05, Mikael Gerdin wrote:
>> Kevin,
>>
>> On 2013-04-10 16:05, Kevin Walls wrote:
>>> Hi,
>>>
>>> I'd like a review of this testcase change.  It fails as it has a GC
>>> option set in the jtreg tag which may conflict with what jtreg sends,
>>> and fail to run.
>>>
>>> Although the test was created for a CMS problem, double-counting of full
>>> collections, here it is adapted to check all collectors:
>>>
>>> http://cr.openjdk.java.net/~kevinw/7109087/webrev/
>>
>> Since you know the number of iterations I think it would be better to
>> use an ArrayList and use list.ensureCapacity(20) to avoid allocations
>> in addCollectionCount.
>>
>> You could also make the GarbageCollectorMXBean list available from a
>> static variable since I'm not sure what happens in that call path.
>>
>> Here you access theseCounts as a List instead of a List<Long>, maybe
>> the "counts" map should be a Map<String, List<Long>>?
>>
>> +            for (int i = 0; i < iterations - 1; i++) {
>> +                List theseCounts = counts.get(collector);
>> +                long a = (Long) theseCounts.get(i);
>>
>> /Mikael
>>
>>
>>>
>>> Thanks
>>> Kevin
>
>
> Hi Mikael, thanks -
>
> ensureCapacity: not sure it stops the addCollectionCount() method
> changing/adding to the list?  We could verify the list is of the right
> length, although I don't think it's that important?...

I meant that ensureCapacity() on ArrayList will make sure that we won't 
need to reallocate the backing array when adding elements.
LinkedList on the other hand will allocate a new list node every time 
you add an element to the list.

We can't be 100% sure that we won't trigger a spurious GC when running 
the test but if we avoid allocating we can reduce the risk somewhat.

/Mikael

> addCollectionCount adds one thing to the List for each collector each
> time it's called...  I don't think we can guarantee that collectors
> aren't getting invoked at any time, but we can make it unlikely, like
> the next point you make:
>
> Yes, don't really need to call  into the ManagementFactory each
> iteration, and can reduce it to a single call to
> ManagementFactory.getGarbageCollectorMXBeans();  We don't need the
> List<MemoryPoolMXBean> at all.
>
> Yes, those casts to Long can be eradicated.
>
> Also there was an unused "count" variable in main(), removed it.. 8-)
>
> And I should clone from hotspot-gc for this change.
>
> New webrev: http://cr.openjdk.java.net/~kevinw/7109087/webrev.02/
>
> Thanks
> Kevin
>



From kevin.walls at oracle.com  Thu Apr 18 14:15:03 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 18 Apr 2013 15:15:03 +0100
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is
	set in command-line
In-Reply-To: <516FF5DF.3070708@oracle.com>
References: <516571AA.60602@oracle.com> <516E9004.7040804@oracle.com>
	<516EC591.5060702@oracle.com> <516FF5DF.3070708@oracle.com>
Message-ID: <516FFFE7.1090409@oracle.com>


OK, yes great we can even initialise the ArrayList in its constructor to 
help reduce that risk.  Updated in the same location as below.

Thanks!
Kevin



On 18/04/13 14:32, Mikael Gerdin wrote:
> Kevin,
>
> On 04/17/2013 05:53 PM, Kevin Walls wrote:
>> On 17/04/13 13:05, Mikael Gerdin wrote:
>>> Kevin,
>>>
>>> On 2013-04-10 16:05, Kevin Walls wrote:
>>>> Hi,
>>>>
>>>> I'd like a review of this testcase change.  It fails as it has a GC
>>>> option set in the jtreg tag which may conflict with what jtreg sends,
>>>> and fail to run.
>>>>
>>>> Although the test was created for a CMS problem, double-counting of 
>>>> full
>>>> collections, here it is adapted to check all collectors:
>>>>
>>>> http://cr.openjdk.java.net/~kevinw/7109087/webrev/
>>>
>>> Since you know the number of iterations I think it would be better to
>>> use an ArrayList and use list.ensureCapacity(20) to avoid allocations
>>> in addCollectionCount.
>>>
>>> You could also make the GarbageCollectorMXBean list available from a
>>> static variable since I'm not sure what happens in that call path.
>>>
>>> Here you access theseCounts as a List instead of a List<Long>, maybe
>>> the "counts" map should be a Map<String, List<Long>>?
>>>
>>> +            for (int i = 0; i < iterations - 1; i++) {
>>> +                List theseCounts = counts.get(collector);
>>> +                long a = (Long) theseCounts.get(i);
>>>
>>> /Mikael
>>>
>>>
>>>>
>>>> Thanks
>>>> Kevin
>>
>>
>> Hi Mikael, thanks -
>>
>> ensureCapacity: not sure it stops the addCollectionCount() method
>> changing/adding to the list?  We could verify the list is of the right
>> length, although I don't think it's that important?...
>
> I meant that ensureCapacity() on ArrayList will make sure that we 
> won't need to reallocate the backing array when adding elements.
> LinkedList on the other hand will allocate a new list node every time 
> you add an element to the list.
>
> We can't be 100% sure that we won't trigger a spurious GC when running 
> the test but if we avoid allocating we can reduce the risk somewhat.
>
> /Mikael
>
>> addCollectionCount adds one thing to the List for each collector each
>> time it's called...  I don't think we can guarantee that collectors
>> aren't getting invoked at any time, but we can make it unlikely, like
>> the next point you make:
>>
>> Yes, don't really need to call  into the ManagementFactory each
>> iteration, and can reduce it to a single call to
>> ManagementFactory.getGarbageCollectorMXBeans();  We don't need the
>> List<MemoryPoolMXBean> at all.
>>
>> Yes, those casts to Long can be eradicated.
>>
>> Also there was an unused "count" variable in main(), removed it.. 8-)
>>
>> And I should clone from hotspot-gc for this change.
>>
>> New webrev: http://cr.openjdk.java.net/~kevinw/7109087/webrev.02/
>>
>> Thanks
>> Kevin
>>
>



From rednaxelafx at gmail.com  Thu Apr 18 14:47:39 2013
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Thu, 18 Apr 2013 22:47:39 +0800
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
In-Reply-To: <1366290810.2927.9.camel@cirrus>
References: <2c47440e-e423-48ed-9c76-b9530a895764@default>
	<CA+cQ+tQbQY75T9is_VoNwkC57TPB5vtmayJnv-shkhmEFFqUAA@mail.gmail.com>
	<1366290810.2927.9.camel@cirrus>
Message-ID: <CA+cQ+tSvhbZxGKZ=6SEvXm7ZNYQeiA1YeipOpyEJo+JgOHZhsQ@mail.gmail.com>

For SurvivorRatio, the handling in ParallelScavenge is a little bit
different than other collectors in HotSpot. The collectors in the
Generational GC framework and G1 use SurvivorRatio directly, so the value
shown by jmap is the one that's taking effect. But ParallelScavenge doesn't
use SurvivorRatio directly, instead it uses IntialSurvivorRatio and
MinSurvivorRatio, with the latter two set ergonomically when the former is
set explicitly. So with ParallelScavenge the SurvivorRatio value shown in
jmap might not reflect what's really taking effect.

Thank you very much for fixing this. It's been annoying for a long time,
and I've been bugged a lot by people confused by the values shown in jmap
-heap.

Regards,
Kris


On Thu, Apr 18, 2013 at 9:13 PM, Thomas Schatzl
<thomas.schatzl at oracle.com>wrote:

> Hi,
>
> On Thu, 2013-04-18 at 02:33 +0800, Krystal Mok wrote:
> > Hi Thomas,
> >
> > Could the same kind of update be done for OldSize and SurvivorRatio?
> > For OldSize, if it's not explicitly set then it'll always show a
> > default value which is like 5MB or something, regardless of the
> > collector used.
>
> Going with the naming convention, OldSize would show the initial old
> generation size.
>
> > For SurvivorRatio, when using UseParallelGC or UseParallelOldGC, if
> > it's not explicitly set then InitialSurvivorRatio is the flag that
> > actually takes effect. It's better if SurvivorRatio could be updated
> > accordingly too.
>
> I think all collectors show these problems, just like in the MaxNewSize
> case.
>
> I created a CR which will become available later at
> http://bugs.sun.com/view_bug.do?bug_id=8012591 . It is a bit more
> generic as it requests to look at the other flags directly printed by
> jmap as well.
>
> Hth,
> Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130418/2b9246e4/attachment.htm>

From mikael.gerdin at oracle.com  Thu Apr 18 14:51:35 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 18 Apr 2013 16:51:35 +0200
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is
	set in command-line
In-Reply-To: <516FFFE7.1090409@oracle.com>
References: <516571AA.60602@oracle.com> <516E9004.7040804@oracle.com>
	<516EC591.5060702@oracle.com> <516FF5DF.3070708@oracle.com>
	<516FFFE7.1090409@oracle.com>
Message-ID: <51700877.7060706@oracle.com>

Kevin,

On 2013-04-18 16:15, Kevin Walls wrote:
>
> OK, yes great we can even initialise the ArrayList in its constructor to
> help reduce that risk.  Updated in the same location as below.

Great, ship it!

/Mikael
>
> Thanks!
> Kevin
>
>
>
> On 18/04/13 14:32, Mikael Gerdin wrote:
>> Kevin,
>>
>> On 04/17/2013 05:53 PM, Kevin Walls wrote:
>>> On 17/04/13 13:05, Mikael Gerdin wrote:
>>>> Kevin,
>>>>
>>>> On 2013-04-10 16:05, Kevin Walls wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like a review of this testcase change.  It fails as it has a GC
>>>>> option set in the jtreg tag which may conflict with what jtreg sends,
>>>>> and fail to run.
>>>>>
>>>>> Although the test was created for a CMS problem, double-counting of
>>>>> full
>>>>> collections, here it is adapted to check all collectors:
>>>>>
>>>>> http://cr.openjdk.java.net/~kevinw/7109087/webrev/
>>>>
>>>> Since you know the number of iterations I think it would be better to
>>>> use an ArrayList and use list.ensureCapacity(20) to avoid allocations
>>>> in addCollectionCount.
>>>>
>>>> You could also make the GarbageCollectorMXBean list available from a
>>>> static variable since I'm not sure what happens in that call path.
>>>>
>>>> Here you access theseCounts as a List instead of a List<Long>, maybe
>>>> the "counts" map should be a Map<String, List<Long>>?
>>>>
>>>> +            for (int i = 0; i < iterations - 1; i++) {
>>>> +                List theseCounts = counts.get(collector);
>>>> +                long a = (Long) theseCounts.get(i);
>>>>
>>>> /Mikael
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> Kevin
>>>
>>>
>>> Hi Mikael, thanks -
>>>
>>> ensureCapacity: not sure it stops the addCollectionCount() method
>>> changing/adding to the list?  We could verify the list is of the right
>>> length, although I don't think it's that important?...
>>
>> I meant that ensureCapacity() on ArrayList will make sure that we
>> won't need to reallocate the backing array when adding elements.
>> LinkedList on the other hand will allocate a new list node every time
>> you add an element to the list.
>>
>> We can't be 100% sure that we won't trigger a spurious GC when running
>> the test but if we avoid allocating we can reduce the risk somewhat.
>>
>> /Mikael
>>
>>> addCollectionCount adds one thing to the List for each collector each
>>> time it's called...  I don't think we can guarantee that collectors
>>> aren't getting invoked at any time, but we can make it unlikely, like
>>> the next point you make:
>>>
>>> Yes, don't really need to call  into the ManagementFactory each
>>> iteration, and can reduce it to a single call to
>>> ManagementFactory.getGarbageCollectorMXBeans();  We don't need the
>>> List<MemoryPoolMXBean> at all.
>>>
>>> Yes, those casts to Long can be eradicated.
>>>
>>> Also there was an unused "count" variable in main(), removed it.. 8-)
>>>
>>> And I should clone from hotspot-gc for this change.
>>>
>>> New webrev: http://cr.openjdk.java.net/~kevinw/7109087/webrev.02/
>>>
>>> Thanks
>>> Kevin
>>>
>>
>


From kevin.walls at oracle.com  Thu Apr 18 15:57:17 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 18 Apr 2013 16:57:17 +0100
Subject: RFR: 7109087: gc/7072527/TestFullGCCount.java fails when GC is
	set in command-line
In-Reply-To: <51700877.7060706@oracle.com>
References: <516571AA.60602@oracle.com> <516E9004.7040804@oracle.com>
	<516EC591.5060702@oracle.com> <516FF5DF.3070708@oracle.com>
	<516FFFE7.1090409@oracle.com> <51700877.7060706@oracle.com>
Message-ID: <517017DD.4030700@oracle.com>

Thanks - I will!


On 18/04/13 15:51, Mikael Gerdin wrote:
> Kevin,
>
> On 2013-04-18 16:15, Kevin Walls wrote:
>>
>> OK, yes great we can even initialise the ArrayList in its constructor to
>> help reduce that risk.  Updated in the same location as below.
>
> Great, ship it!
>
> /Mikael
>>
>> Thanks!
>> Kevin
>>
>>
>>
>> On 18/04/13 14:32, Mikael Gerdin wrote:
>>> Kevin,
>>>
>>> On 04/17/2013 05:53 PM, Kevin Walls wrote:
>>>> On 17/04/13 13:05, Mikael Gerdin wrote:
>>>>> Kevin,
>>>>>
>>>>> On 2013-04-10 16:05, Kevin Walls wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'd like a review of this testcase change.  It fails as it has a GC
>>>>>> option set in the jtreg tag which may conflict with what jtreg 
>>>>>> sends,
>>>>>> and fail to run.
>>>>>>
>>>>>> Although the test was created for a CMS problem, double-counting of
>>>>>> full
>>>>>> collections, here it is adapted to check all collectors:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~kevinw/7109087/webrev/
>>>>>
>>>>> Since you know the number of iterations I think it would be better to
>>>>> use an ArrayList and use list.ensureCapacity(20) to avoid allocations
>>>>> in addCollectionCount.
>>>>>
>>>>> You could also make the GarbageCollectorMXBean list available from a
>>>>> static variable since I'm not sure what happens in that call path.
>>>>>
>>>>> Here you access theseCounts as a List instead of a List<Long>, maybe
>>>>> the "counts" map should be a Map<String, List<Long>>?
>>>>>
>>>>> +            for (int i = 0; i < iterations - 1; i++) {
>>>>> +                List theseCounts = counts.get(collector);
>>>>> +                long a = (Long) theseCounts.get(i);
>>>>>
>>>>> /Mikael
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Kevin
>>>>
>>>>
>>>> Hi Mikael, thanks -
>>>>
>>>> ensureCapacity: not sure it stops the addCollectionCount() method
>>>> changing/adding to the list?  We could verify the list is of the right
>>>> length, although I don't think it's that important?...
>>>
>>> I meant that ensureCapacity() on ArrayList will make sure that we
>>> won't need to reallocate the backing array when adding elements.
>>> LinkedList on the other hand will allocate a new list node every time
>>> you add an element to the list.
>>>
>>> We can't be 100% sure that we won't trigger a spurious GC when running
>>> the test but if we avoid allocating we can reduce the risk somewhat.
>>>
>>> /Mikael
>>>
>>>> addCollectionCount adds one thing to the List for each collector each
>>>> time it's called...  I don't think we can guarantee that collectors
>>>> aren't getting invoked at any time, but we can make it unlikely, like
>>>> the next point you make:
>>>>
>>>> Yes, don't really need to call  into the ManagementFactory each
>>>> iteration, and can reduce it to a single call to
>>>> ManagementFactory.getGarbageCollectorMXBeans();  We don't need the
>>>> List<MemoryPoolMXBean> at all.
>>>>
>>>> Yes, those casts to Long can be eradicated.
>>>>
>>>> Also there was an unused "count" variable in main(), removed it.. 8-)
>>>>
>>>> And I should clone from hotspot-gc for this change.
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~kevinw/7109087/webrev.02/
>>>>
>>>> Thanks
>>>> Kevin
>>>>
>>>
>>



From markus.gronlund at oracle.com  Thu Apr 18 05:46:47 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 17 Apr 2013 22:46:47 -0700 (PDT)
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <516F5D6A.4060608@oracle.com>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
	<516F5D6A.4060608@oracle.com>
Message-ID: <a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>

Thanks David and Sergeui,

I have added (back) the INCLUDE_TRACE for the load code.

Webrev version 5:
http://cr.openjdk.java.net/~mgronlun/8012182/webrev05/


BugID:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182


Thanks
Markus



-----Original Message-----
From: David Holmes 
Sent: den 18 april 2013 04:42
To: Markus Gr?nlund
Cc: Karen Kinnear; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

On 18/04/2013 3:39 AM, Markus Gr?nlund wrote:
> Hi again,
>
> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>
> Event notification now posted after check_constraints and exception checks.

Okay that seems fine.

I just have the same query as Serguei as to why the unload code is conditional on INCLUDE_TRACE but the load code isnt ??

Thanks,
David

> Webrev version 4:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Thanks again
> Markus
>
>
> -----Original Message-----
> From: Markus Gr?nlund
> Sent: den 17 april 2013 12:41
> To: David Holmes; Karen Kinnear
> Cc: serviceability-dev at openjdk.java.net; 
> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24) - updated
>
> Hi again,
>
> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>
> Also updated the patch to include comments + contributions.
>
> Webrev version 3:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
> Many thanks for your comments.
>
> Cheers
> Markus
>
>
>
> -----Original Message-----
> From: Markus Gr?nlund
> Sent: den 17 april 2013 09:48
> To: David Holmes
> Cc: serviceability-dev at openjdk.java.net; 
> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: RE: RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24) - updated
>
> First,
>
> I forgot to mention in the original post that parts of this code was contributed-by:
>
> Calvin Cheung (calvin.cheung at oracle.com)
>
> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>
>
> Now,
>
> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>
> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>
> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>
>
> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>
> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 17 april 2013 03:46
> To: Markus Gr?nlund
> Cc: hotspot-runtime-dev at openjdk.java.net; 
> serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24) - updated
>
> Hi Markus,
>
> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> The changeset for this has been updated slightly to reflect 
>> underlying changes in hs24.
>>
>> Still looking for reviews for this change to add information about 
>> class loading and unloading to the event based tracing framework for HS24.
>>
>> BugID:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Webrev (updated):
>>
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>
> systemDictionary.cpp:
>
> Minor nit: this comment, now it is split from earlier comment
>
> 801         // class_loader is NOT the defining loader, do a little more
> bookkeeping.
>
> should say
>
> 801         // If class_loader is NOT the defining loader, do a little
> more bookkeeping.
>
> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>
> ---
>
> traceStream.hpp
>
> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>
> David
> -----
>
>> Thanks in advance
>>
>> Markus
>>
>> *From:*Markus Gr?nlund
>> *Sent:* den 15 april 2013 10:17
>> *To:* hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net
>> *Subject:* RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24)
>>
>> Greetings,
>>
>> Kindly asking for reviews for the change to add class load and unload 
>> information to the event based tracing framework to HS24.
>>
>> BugID:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>
>> Thanks
>>
>> Markus
>>


From markus.gronlund at oracle.com  Thu Apr 18 08:38:12 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Thu, 18 Apr 2013 01:38:12 -0700 (PDT)
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <516FA2C5.4020006@oracle.com>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
	<516F5D6A.4060608@oracle.com>
	<a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>
	<516FA2C5.4020006@oracle.com>
Message-ID: <0ad351a3-c9ba-42c7-b132-2cd4b739e8d7@default>

Thanks Serguei,

Can I please also get a (R)eviewer for this?

Thanks in advance
Markus

-----Original Message-----
From: Serguei Spitsyn 
Sent: den 18 april 2013 09:38
To: Markus Gr?nlund
Cc: David Holmes; Karen Kinnear; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

Markus,

It looks good.

Thanks,
Serguei


On 4/17/13 10:46 PM, Markus Gr?nlund wrote:
> Thanks David and Sergeui,
>
> I have added (back) the INCLUDE_TRACE for the load code.
>
> Webrev version 5:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev05/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 18 april 2013 04:42
> To: Markus Gr?nlund
> Cc: Karen Kinnear; serviceability-dev at openjdk.java.net; 
> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24) - updated
>
> On 18/04/2013 3:39 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>>
>> Event notification now posted after check_constraints and exception checks.
> Okay that seems fine.
>
> I just have the same query as Serguei as to why the unload code is conditional on INCLUDE_TRACE but the load code isnt ??
>
> Thanks,
> David
>
>> Webrev version 4:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>>
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Thanks again
>> Markus
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 12:41
>> To: David Holmes; Karen Kinnear
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi again,
>>
>> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>>
>> Also updated the patch to include comments + contributions.
>>
>> Webrev version 3:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Many thanks for your comments.
>>
>> Cheers
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 09:48
>> To: David Holmes
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24) - updated
>>
>> First,
>>
>> I forgot to mention in the original post that parts of this code was contributed-by:
>>
>> Calvin Cheung (calvin.cheung at oracle.com)
>>
>> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>>
>>
>> Now,
>>
>> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>>
>> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>>
>> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>>
>>
>> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>>
>> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>>
>>
>> Thanks
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: den 17 april 2013 03:46
>> To: Markus Gr?nlund
>> Cc: hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi Markus,
>>
>> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>>> Hi again,
>>>
>>> The changeset for this has been updated slightly to reflect 
>>> underlying changes in hs24.
>>>
>>> Still looking for reviews for this change to add information about 
>>> class loading and unloading to the event based tracing framework for HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev (updated):
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>> systemDictionary.cpp:
>>
>> Minor nit: this comment, now it is split from earlier comment
>>
>> 801         // class_loader is NOT the defining loader, do a little more
>> bookkeeping.
>>
>> should say
>>
>> 801         // If class_loader is NOT the defining loader, do a little
>> more bookkeeping.
>>
>> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>>
>> ---
>>
>> traceStream.hpp
>>
>> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>>
>> David
>> -----
>>
>>> Thanks in advance
>>>
>>> Markus
>>>
>>> *From:*Markus Gr?nlund
>>> *Sent:* den 15 april 2013 10:17
>>> *To:* hotspot-runtime-dev at openjdk.java.net;
>>> serviceability-dev at openjdk.java.net
>>> *Subject:* RFR(M): 8012182: Add information about class loading and 
>>> unloading to event based tracing framework (hs24)
>>>
>>> Greetings,
>>>
>>> Kindly asking for reviews for the change to add class load and 
>>> unload information to the event based tracing framework to HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>>
>>> Thanks
>>>
>>> Markus
>>>



From markus.gronlund at oracle.com  Thu Apr 18 10:36:42 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Thu, 18 Apr 2013 03:36:42 -0700 (PDT)
Subject: RFR(M): 8012182: Add information about class loading and
	unloading to event based tracing framework (hs24) - updated
In-Reply-To: <516FCAA8.4090201@oracle.com>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
	<516F5D6A.4060608@oracle.com>
	<a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>
	<516FCAA8.4090201@oracle.com>
Message-ID: <af2c1b7d-0719-40fd-bf64-d97cdc440f1c@default>

Thank you.

/Markus

-----Original Message-----
From: David Holmes 
Sent: den 18 april 2013 12:28
To: Markus Gr?nlund
Cc: Serguei Spitsyn; Karen Kinnear; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated

Looks good to me.

Thanks,
David

On 18/04/2013 3:46 PM, Markus Gr?nlund wrote:
> Thanks David and Sergeui,
>
> I have added (back) the INCLUDE_TRACE for the load code.
>
> Webrev version 5:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev05/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 18 april 2013 04:42
> To: Markus Gr?nlund
> Cc: Karen Kinnear; serviceability-dev at openjdk.java.net; 
> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and 
> unloading to event based tracing framework (hs24) - updated
>
> On 18/04/2013 3:39 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>>
>> Event notification now posted after check_constraints and exception checks.
>
> Okay that seems fine.
>
> I just have the same query as Serguei as to why the unload code is conditional on INCLUDE_TRACE but the load code isnt ??
>
> Thanks,
> David
>
>> Webrev version 4:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>>
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Thanks again
>> Markus
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 12:41
>> To: David Holmes; Karen Kinnear
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi again,
>>
>> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>>
>> Also updated the patch to include comments + contributions.
>>
>> Webrev version 3:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Many thanks for your comments.
>>
>> Cheers
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 09:48
>> To: David Holmes
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24) - updated
>>
>> First,
>>
>> I forgot to mention in the original post that parts of this code was contributed-by:
>>
>> Calvin Cheung (calvin.cheung at oracle.com)
>>
>> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>>
>>
>> Now,
>>
>> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>>
>> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>>
>> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>>
>>
>> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>>
>> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>>
>>
>> Thanks
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: den 17 april 2013 03:46
>> To: Markus Gr?nlund
>> Cc: hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8012182: Add information about class loading and 
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi Markus,
>>
>> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>>> Hi again,
>>>
>>> The changeset for this has been updated slightly to reflect 
>>> underlying changes in hs24.
>>>
>>> Still looking for reviews for this change to add information about 
>>> class loading and unloading to the event based tracing framework for HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev (updated):
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>>
>> systemDictionary.cpp:
>>
>> Minor nit: this comment, now it is split from earlier comment
>>
>> 801         // class_loader is NOT the defining loader, do a little more
>> bookkeeping.
>>
>> should say
>>
>> 801         // If class_loader is NOT the defining loader, do a little
>> more bookkeeping.
>>
>> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>>
>> ---
>>
>> traceStream.hpp
>>
>> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>>
>> David
>> -----
>>
>>> Thanks in advance
>>>
>>> Markus
>>>
>>> *From:*Markus Gr?nlund
>>> *Sent:* den 15 april 2013 10:17
>>> *To:* hotspot-runtime-dev at openjdk.java.net;
>>> serviceability-dev at openjdk.java.net
>>> *Subject:* RFR(M): 8012182: Add information about class loading and 
>>> unloading to event based tracing framework (hs24)
>>>
>>> Greetings,
>>>
>>> Kindly asking for reviews for the change to add class load and 
>>> unload information to the event based tracing framework to HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>>
>>> Thanks
>>>
>>> Markus
>>>


From serguei.spitsyn at oracle.com  Thu Apr 18 07:37:41 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 Apr 2013 00:37:41 -0700
Subject: RFR(M): 8012182: Add information about class loading and unloading
	to event based tracing framework (hs24) - updated
In-Reply-To: <a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>
References: <98226c25-b171-4861-9976-04de6aff5ad2@default>
	<516DFEE7.7070800@oracle.com>
	<c7fcd3f3-051b-44b3-84d8-7db365ec8554@default>
	<51da3125-6338-44d3-8b62-7d904cec56ef@default>
	<3d6120fa-62c0-4dac-8a6a-4b6cf6086ff5@default>
	<516F5D6A.4060608@oracle.com>
	<a2fe1e9a-1a42-4e21-8845-a00eec688c2f@default>
Message-ID: <516FA2C5.4020006@oracle.com>

Markus,

It looks good.

Thanks,
Serguei


On 4/17/13 10:46 PM, Markus Gr?nlund wrote:
> Thanks David and Sergeui,
>
> I have added (back) the INCLUDE_TRACE for the load code.
>
> Webrev version 5:
> http://cr.openjdk.java.net/~mgronlun/8012182/webrev05/
>
>
> BugID:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>
>
> Thanks
> Markus
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 18 april 2013 04:42
> To: Markus Gr?nlund
> Cc: Karen Kinnear; serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8012182: Add information about class loading and unloading to event based tracing framework (hs24) - updated
>
> On 18/04/2013 3:39 AM, Markus Gr?nlund wrote:
>> Hi again,
>>
>> Seems it wasn't really as straightforward as originally suggesting with collocating the event tracing and the JVMTI code - especially if I attempt to breakout the JVMTI notification code from SystemDictionary::define_instance_class(); this seems to have detrimental effects on the UTE JVMTI tests...so I am leaving all JVMTI code as is...
>>
>> Event notification now posted after check_constraints and exception checks.
> Okay that seems fine.
>
> I just have the same query as Serguei as to why the unload code is conditional on INCLUDE_TRACE but the load code isnt ??
>
> Thanks,
> David
>
>> Webrev version 4:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev04/
>>
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Thanks again
>> Markus
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 12:41
>> To: David Holmes; Karen Kinnear
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi again,
>>
>> Updated webrev (v3) trying to respect the loader constraint checking before event posting - in addition trying to consolidate the event notification code (instrumentation in SystemDictionary::define_instance_class() seems to indicate the ok'ness of moving the JVMTI::should_post call from out of there)...but I am sure Karen will put me right if this ok for real.
>>
>> Also updated the patch to include comments + contributions.
>>
>> Webrev version 3:
>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev03/
>>
>> BugID:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>
>> Many thanks for your comments.
>>
>> Cheers
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: Markus Gr?nlund
>> Sent: den 17 april 2013 09:48
>> To: David Holmes
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: RE: RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24) - updated
>>
>> First,
>>
>> I forgot to mention in the original post that parts of this code was contributed-by:
>>
>> Calvin Cheung (calvin.cheung at oracle.com)
>>
>> Calvin will be attributed to this fact in a Contributed-by: when this goes back.
>>
>>
>> Now,
>>
>> "I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???"
>>
>> Yes, this is not so easy to follow (I haven't gone though it in excruciating detils that is) - there is another JvmtiExport::should_post_class_load() in SystemDictionary::define_instance_class as well...
>>
>> With now having the TracingTime type available unconditionally, it open up some more flexibility to match the tracing code with JvmtiExport::should_post_class_load(), I will see if I can come up with something that allows for tighter pairing with JVMTI.
>>
>>
>> "Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?"
>>
>> Absolutely yes. I will add in comments about the assumptions in TraceStream.hpp. In addition I will fix up the reference variables to be const references as well. Thanks.
>>
>>
>> Thanks
>> Markus
>>
>>
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: den 17 april 2013 03:46
>> To: Markus Gr?nlund
>> Cc: hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8012182: Add information about class loading and
>> unloading to event based tracing framework (hs24) - updated
>>
>> Hi Markus,
>>
>> On 17/04/2013 7:35 AM, Markus Gr?nlund wrote:
>>> Hi again,
>>>
>>> The changeset for this has been updated slightly to reflect
>>> underlying changes in hs24.
>>>
>>> Still looking for reviews for this change to add information about
>>> class loading and unloading to the event based tracing framework for HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev (updated):
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev02/
>> systemDictionary.cpp:
>>
>> Minor nit: this comment, now it is split from earlier comment
>>
>> 801         // class_loader is NOT the defining loader, do a little more
>> bookkeeping.
>>
>> should say
>>
>> 801         // If class_loader is NOT the defining loader, do a little
>> more bookkeeping.
>>
>> I still find it odd that you post the event before the loader constraint checks are done. Not normally an issue of course. And conversely it seems odd that JVMTI only posts an event if we needed to do the loader constraint checking ???
>>
>> ---
>>
>> traceStream.hpp
>>
>> Following on to Karen's comment, so you rely on the ResourceMark being in the "caller" (which is the generated code in this case) ? Should that be documented in the file?
>>
>> David
>> -----
>>
>>> Thanks in advance
>>>
>>> Markus
>>>
>>> *From:*Markus Gr?nlund
>>> *Sent:* den 15 april 2013 10:17
>>> *To:* hotspot-runtime-dev at openjdk.java.net;
>>> serviceability-dev at openjdk.java.net
>>> *Subject:* RFR(M): 8012182: Add information about class loading and
>>> unloading to event based tracing framework (hs24)
>>>
>>> Greetings,
>>>
>>> Kindly asking for reviews for the change to add class load and unload
>>> information to the event based tracing framework to HS24.
>>>
>>> BugID:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012182
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mgronlun/8012182/webrev01/
>>>
>>> Thanks
>>>
>>> Markus
>>>



From john.cuthbertson at oracle.com  Thu Apr 18 17:57:31 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 18 Apr 2013 10:57:31 -0700
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1366183427.4102.2.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus>
	<1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com>
	<1364203467.2703.41.camel@cirrus> <51509569.1020604@oracle.com>
	<1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus>
Message-ID: <5170340B.6020704@oracle.com>

Hi Thomas,

Thanks for the resonse. Inline...

On 4/17/2013 12:23 AM, Thomas Schatzl wrote:
> Hi,
>
>    I had the same concerns about inconsistencies with -Xms and
> -XX:InitialHeapSize, but -Xms is (apparently) defined to set both
> minimum and initial heap size.
> I already raised that issue in an earlier discussion.

OK. I don't have a problem with it. It just looked 'odd'.
>
> If you have an official source that states that -Xms only sets minimum
> or initial heap size, I will gladly change this. I could not find
> anything; actually the documentation (java -X) for -Xms states only that it sets the initial heap size.
>
> The observations below result from this definition.
>
> On Mon, 2013-04-15 at 16:29 -0700, John Cuthbertson wrote:
>> Hi Thomas,
>>
>> Why do we treat:
>>
>> java -Xms8M  -XX:InitialHeapSize=4M...
>>
>> as an error while accepting:
> Because -Xms sets minimum heap size to 8M, and if you then set initial
> heap size to 4M there is a conflict in the general condition that
> minimum <= initial <= max.
>
>> java -XX:InitialHeapSize=4M -Xms8M...
>>
>> It looks inconsistent. In both cases the user has asked for an initial
>> heap size less than his requested minimum.
> As mentioned, -Xms unfortunately seems to be defined to set both initial
> and minimum heap size. So there is no conflict.

You're correct. I've looked at the contents of the Xusage.txt file for a 
couple of really ancient jdks and it says that it sets the initial size.


>> In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be
>> coalesced into a single line for each? This would make the setting of
>> Initial and Min consistent with the code that sets Max on line 87.
>>
> Done.
>
> See http://cr.openjdk.java.net/~tschatzl/8006088/webrev.7/ for the new
> webrev.
>
> In addition to this change I fixed the headers of the jprt test cases to
> avoid some issues with jtreg. Namely precompile the used classes and
> install the whitebox api class into the boot class path.

Thanks. collectorPolicy.cpp looks much cleaner.

Ship it.

JohnC


From tao.mao at oracle.com  Thu Apr 18 23:45:25 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Thu, 18 Apr 2013 16:45:25 -0700
Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode
	from Arguments::check_deprecated_gcs() to
	Arguments::check_deprecated_gc_flags()
In-Reply-To: <5154873F.60002@oracle.com>
References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com>
	<514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com>
	<51509C17.6080808@oracle.com> <51512A97.2030600@oracle.com>
	<51537686.1030601@oracle.com> <5153E3D1.2040002@oracle.com>
	<515482F1.5070002@oracle.com> <5154873F.60002@oracle.com>
Message-ID: <51708595.9010708@oracle.com>

Hi all,

After reading JEP documentation, I don't feel like moving 
CMSIncrementalMode to check_deprecated_gc_flags() because it's 
essentially Incremental CMS collector. It's more expected to live in 
check_deprecated_gcs() (at least to me). What are your opinions? If no 
one opposes, I will close this CR.

Thanks.
Tao

On 3/28/13 11:09 AM, Bengt Rutisson wrote:
> On 3/28/13 6:50 PM, Tao Mao wrote:
>> Hi Bengt,
>>
>> On 3/27/2013 11:31 PM, Bengt Rutisson wrote:
>>>
>>> Hi Tao,
>>>
>>> On 3/27/13 11:45 PM, Tao Mao wrote:
>>>> Please see inline.
>>>> Tao
>>>>
>>>> On 3/25/13 9:56 PM, Bengt Rutisson wrote:
>>>>>
>>>>> Hi Tao,
>>>>>
>>>>> Thanks for updating the tests. Looks good to me.
>>>>>
>>>>> Have you tried running the tests? It is a very small change so it 
>>>>> should be ok. But our testing process is very strange and it may 
>>>>> be that these tests are not run until PIT testing, so running them 
>>>>> once before pushing is a good idea to avoid unnecessary issues 
>>>>> later on.
>>>> They have passed the jtreg tests. I'm going to push it.
>>>>
>>>> script:
>>>> jtreg -jdk:/Users/tamao/home/jdk1.8.0_b74_macosx/ \
>>>> -vmoption:-tamao \
>>>> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestCMSIncrementalMode.java 
>>>> \
>>>> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestIncGC.java
>>>>
>>>> results:
>>>> Test results: passed: 2
>>>> Report written to /Users/tamao/Dropbox/Oracle/JTreport/html/report.html
>>>> Results written to /Users/tamao/Dropbox/Oracle/JTwork
>>>
>>> Great! Thanks!
>>>
>>>>>
>>>>> Also, I see that you decided not to remove "likely" from the other 
>>>>> messages in Arguments::check_deprecated_gcs(). Would you like to 
>>>>> do that as a separate change or do you think we should leave those 
>>>>> messages unchanged?
>>>> So what was the decision for deprecating these gc's? To me, there 
>>>> hasn't seemed to be any definitive decision, yet.
>>>
>>> It is the same decision as for CMSIncrementalMode, where you removed 
>>> the "likely".
>>>
>>> Bengt
>> Where is the latest update regarding this issue? Any mail thread, or web?
>
> I think the JEP is pretty clear about it:
>
> http://openjdk.java.net/jeps/173
>
> " The DefNew + CMS and ParNew + SerialOld combinations and the 
> Incremental Mode of CMS will be deprecated (logging a warning 
> message). This is to be interpreted as that these GC combinations will 
> be removed in some upcoming major release."
>
> Bengt
>>
>> Thank you.
>> Tao
>>
>>>
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>> On 3/25/13 7:48 PM, Tao Mao wrote:
>>>>>> Thank you for pointing it out, Bengt. A new webrev is updated.
>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/
>>>>>>
>>>>>> Please see inline.
>>>>>> Tao
>>>>>>
>>>>>> On 3/24/13 1:16 PM, Bengt Rutisson wrote:
>>>>>>>
>>>>>>> Hi Tao,
>>>>>>>
>>>>>>> On 3/23/13 4:51 AM, Tao Mao wrote:
>>>>>>>> Thank you for review and suggestion. A new webrev is updated.
>>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/
>>>>>>>
>>>>>>> I like Jon's suggestion about removing the word "likely" but 
>>>>>>> that means that you need to update these tests:
>>>>>>>
>>>>>>> test/gc/startup_warnings/TestCMSIncrementalMode.java
>>>>>>> test/gc/startup_warnings/TestIncGC.java
>>>>>> Test files modified.
>>>>>>>
>>>>>>> Also, would it make sense to remove the word "likely" from the 
>>>>>>> warning messages in Arguments::check_deprecated_gcs() too? In 
>>>>>>> that case you need to update these tests as well:
>>>>>>>
>>>>>>> test/gc/startup_warnings/TestDefNewCMS.java
>>>>>>> test/gc/startup_warnings/TestParNewSerialOld.java
>>>>>> Have we made a decision to certainly remove these gc comb's in 
>>>>>> future? If so, it's OK to state so. Anyway, it would be better to 
>>>>>> resolve it with a separate CR.
>>>>>>>
>>>>>>> Bengt
>>>>>>>
>>>>>>>>
>>>>>>>> Tao
>>>>>>>>
>>>>>>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote:
>>>>>>>>> Tao,
>>>>>>>>>
>>>>>>>>> Changes look fine.  I would remove the "likely" so that 
>>>>>>>>> messages read like
>>>>>>>>>
>>>>>>>>> "and will be removed in a future release"
>>>>>>>>>
>>>>>>>>> Fewer words are better and the intent is still clear.
>>>>>>>>>
>>>>>>>>> Jon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/21/2013 4:23 PM, Tao Mao wrote:
>>>>>>>>>> A simple changeset. Need a reviewer!
>>>>>>>>>>
>>>>>>>>>> 8010518 Move deprecating CMSIncrementalMode from 
>>>>>>>>>> Arguments::check_deprecated_gcs() to 
>>>>>>>>>> Arguments::check_deprecated_gc_flags()
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518
>>>>>>>>>>
>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/
>>>>>>>>>>
>>>>>>>>>> changeset:
>>>>>>>>>> Cleanup suggested by Bengt.
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130418/03a1ddfa/attachment.htm>

From david.holmes at oracle.com  Fri Apr 19 02:10:02 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 12:10:02 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516FA67B.20308@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F5FD5.8020406@oracle.com>
	<516FA67B.20308@oracle.com>
Message-ID: <5170A77A.6080006@oracle.com>

On 18/04/2013 5:53 PM, Yumin Qi wrote:
> Thanks Coleen and David, I update the webrev (same URL) for
> HandleMark(handles.hpp) and also several files' Copyright year.

Thanks for that.

One thing that just occurred to me is that NEW_C_HEAP_OBJ can only be 
used for classes that have no virtual methods - as there is nothing to 
initialize the vtable pointer. I think we got lucky with HandleMark in 
that regard, but there should be a warning attached to it as well.

Thanks,
David

> Thanks
> Yumin
>
> On 4/17/2013 7:52 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> Only thing missing - as discussed - is that HandleMark should now
>> extend StackObj, with a comment about the special CHeap HandleMark in
>> thread.
>>
>> Thanks for your perseverance on this.
>>
>> David
>>
>> On 18/04/2013 3:54 AM, Yumin Qi wrote:
>>> Hi,  This version Change back the HandleMark creating in Thread creation
>>> back to previous version and add more comments to allocation.hpp for
>>> documenting the usage of newly introduced macros.
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>>> Hi, all
>>>>
>>>>   new webrev at
>>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>
>>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>>                     quickSort.cpp, remove conditional includes.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>>> Adding back compiler and gc teams
>>>>>>>
>>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>>> Zhenyu,
>>>>>>>>
>>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>>
>>>>>>>> i can just do
>>>>>>>>
>>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>>
>>>>>>>> so the destructor will be called, is this right?
>>>>>>>
>>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>>> actually deallocate the memory.
>>>>>>>
>>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>>
>>>>> But you can only call that explicitly as a function. The delete
>>>>> expression will never use it, so I don't see how it applies. We need
>>>>> to call the destructor without de-allocating and the only way I can
>>>>> see to do that is to call the destructor explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>>> destructs and then de-allocates.
>>>>>>>
>>>>>>> I have no issue with calling destructors explicitly.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>>> memflags)                  \
>>>>>>>>>>   624 { \
>>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>>> { \
>>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>>> {                                 \
>>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>>> */                                        \
>>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>>   629 } \
>>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>>> memflags);                                \
>>>>>>>>>>   631 } \
>>>>>>>>>>   632   }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>>> new webrev at:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>>
>>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>>
>>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>>
>>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to
>>>>>>>>>>>> leak
>>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>>> to it!
>>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>>
>>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>>> element
>>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the
>>>>>>>>>>>> dtor's
>>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>>
>>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator
>>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we
>>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from
>>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they
>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>


From jon.masamitsu at oracle.com  Fri Apr 19 03:10:58 2013
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Fri, 19 Apr 2013 03:10:58 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011268: NPG: Free unused
	VirtualSpaceNodes
Message-ID: <20130419031103.B0EE148441@hg.openjdk.java.net>

Changeset: c23dbf0e8ab7
Author:    jmasa
Date:      2013-03-01 10:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c23dbf0e8ab7

8011268: NPG: Free unused VirtualSpaceNodes
Reviewed-by: mgerdin, coleenp, johnc

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/memory/metachunk.cpp
! src/share/vm/memory/metachunk.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp



From john.coomes at oracle.com  Fri Apr 19 04:38:27 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:38:27 +0000
Subject: hg: hsx/hotspot-gc: 12 new changesets
Message-ID: <20130419043828.286794845A@hg.openjdk.java.net>

Changeset: fc1e08c2bb27
Author:    mduigou
Date:      2013-04-01 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/fc1e08c2bb27

8010267: Add test-clean for cleaning of testoutput directory from output directory. Add depedency on test-clean to clean
Reviewed-by: mchung, tbell

! common/makefiles/Main.gmk

Changeset: 26a4456cb19e
Author:    jgish
Date:      2013-03-26 13:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/26a4456cb19e

8009824: webrev.ksh generated jdk.patch files do not handle renames, copies, and shouldn't be applied
Summary: use hg export --git to produce proper patch file
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Changeset: 760074bec012
Author:    mduigou
Date:      2013-04-01 21:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/760074bec012

8011178: improve common/bin/hgforest.sh python detection (MacOS)
Reviewed-by: ohair

! common/bin/hgforest.sh

Changeset: bcbdbcfe7ed8
Author:    lana
Date:      2013-04-02 11:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/bcbdbcfe7ed8

Merge


Changeset: 7320922b694e
Author:    mduigou
Date:      2013-04-02 14:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/7320922b694e

8011342: hgforest.sh : 'python --version' not supported on older python
Reviewed-by: wetmore

! common/bin/hgforest.sh

Changeset: 575f2ca947ab
Author:    mduigou
Date:      2013-04-03 16:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/575f2ca947ab

8011350: hgforest.sh uses non-POSIX sh features that may fail with some shells
Reviewed-by: tbell, katleman, dholmes

! common/bin/hgforest.sh

Changeset: 11c057460b91
Author:    lana
Date:      2013-04-05 14:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/11c057460b91

Merge


Changeset: 4c13b7994f38
Author:    lana
Date:      2013-04-16 08:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/4c13b7994f38

Merge

! common/makefiles/Main.gmk

Changeset: bee6ff988f9c
Author:    katleman
Date:      2013-04-12 15:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/bee6ff988f9c

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: 8c5b18d6f4fb
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8c5b18d6f4fb

Merge


Changeset: df9b5240f0a7
Author:    katleman
Date:      2013-04-16 14:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/df9b5240f0a7

Merge


Changeset: 6981694f7674
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/6981694f7674

Added tag jdk8-b86 for changeset df9b5240f0a7

! .hgtags



From john.coomes at oracle.com  Fri Apr 19 04:38:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:38:31 +0000
Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b86 for changeset
	44a8ce4a759f
Message-ID: <20130419043834.8FA7A4845B@hg.openjdk.java.net>

Changeset: f1709874d55a
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/f1709874d55a

Added tag jdk8-b86 for changeset 44a8ce4a759f

! .hgtags



From john.coomes at oracle.com  Fri Apr 19 04:38:38 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:38:38 +0000
Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b86 for changeset ca71ec37b2ef
Message-ID: <20130419043847.BCFB04845C@hg.openjdk.java.net>

Changeset: 9550aab82b5d
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/9550aab82b5d

Added tag jdk8-b86 for changeset ca71ec37b2ef

! .hgtags



From john.coomes at oracle.com  Fri Apr 19 04:39:08 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:39:08 +0000
Subject: hg: hsx/hotspot-gc/jaxws: 3 new changesets
Message-ID: <20130419043917.8C6BF4845D@hg.openjdk.java.net>

Changeset: 0989ad8c0860
Author:    alanb
Date:      2013-04-09 14:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/0989ad8c0860

8010393: Update JAX-WS RI to 2.2.9-b12941
Reviewed-by: alanb, erikj
Contributed-by: miroslav.kos at oracle.com, martin.grebac at oracle.com

! makefiles/BuildJaxws.gmk
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyle.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyleFeature.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/Databinding.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingFactory.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingMode.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingModeFeature.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/JavaCallInfo.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLGenerator.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLResolver.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BaseDistributedPropertySet.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BasePropertySet.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ContentType.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/DistributedPropertySet.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContext.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/PropertySet.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ReadOnlyPropertyException.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/impl/encoding/StreamDecoderImpl.java
+ src/share/jaxws_classes/com/oracle/webservices/internal/impl/internalspi/encoding/StreamDecoder.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ExistingAnnotationsType.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaMethod.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaParam.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaWsdlMappingType.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ObjectFactory.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingParameterStyle.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingStyle.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingUse.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/Util.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/WebParamMode.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAction.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAddressing.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlBindingType.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlFaultAction.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlHandlerChain.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlMTOM.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlOneway.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlRequestWrapper.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlResponseWrapper.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlSOAPBinding.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlServiceMode.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebEndpoint.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebFault.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebMethod.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebParam.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebResult.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebService.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceClient.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceProvider.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceRef.java
+ src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/package-info.java
! src/share/jaxws_classes/com/sun/istack/internal/Builder.java
! src/share/jaxws_classes/com/sun/istack/internal/ByteArrayDataSource.java
! src/share/jaxws_classes/com/sun/istack/internal/FinalArrayList.java
! src/share/jaxws_classes/com/sun/istack/internal/FragmentContentHandler.java
! src/share/jaxws_classes/com/sun/istack/internal/Interned.java
! src/share/jaxws_classes/com/sun/istack/internal/NotNull.java
! src/share/jaxws_classes/com/sun/istack/internal/Nullable.java
! src/share/jaxws_classes/com/sun/istack/internal/Pool.java
! src/share/jaxws_classes/com/sun/istack/internal/SAXException2.java
! src/share/jaxws_classes/com/sun/istack/internal/SAXParseException2.java
! src/share/jaxws_classes/com/sun/istack/internal/XMLStreamException2.java
! src/share/jaxws_classes/com/sun/istack/internal/XMLStreamReaderToContentHandler.java
! src/share/jaxws_classes/com/sun/istack/internal/localization/Localizable.java
! src/share/jaxws_classes/com/sun/istack/internal/localization/LocalizableMessage.java
! src/share/jaxws_classes/com/sun/istack/internal/localization/LocalizableMessageFactory.java
! src/share/jaxws_classes/com/sun/istack/internal/localization/Localizer.java
+ src/share/jaxws_classes/com/sun/istack/internal/localization/NullLocalizable.java
! src/share/jaxws_classes/com/sun/istack/internal/logging/Logger.java
! src/share/jaxws_classes/com/sun/istack/internal/package-info.java
+ src/share/jaxws_classes/com/sun/istack/internal/tools/DefaultAuthenticator.java
! src/share/jaxws_classes/com/sun/istack/internal/tools/MaskingClassLoader.java
! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java
! src/share/jaxws_classes/com/sun/istack/internal/tools/SecureLoader.java
! src/share/jaxws_classes/com/sun/istack/internal/tools/package-info.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/AMX.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/AMXGlassfish.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/AMXUtil.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/BootAMXMBean.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/amx/MBeanListener.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/arc/Stability.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/arc/Taxonomy.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/PluginPoint.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProvider.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProviderInfo.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProviderManager.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/StatsProviderManagerDelegate.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/ProbeListener.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/ProbeParam.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/ProbeProvider.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/AverageRangeStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/BoundaryStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/BoundedRangeStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/CountStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/RangeStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/Statistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/Stats.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/StringStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/TimeStatistic.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/annotations/Reset.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatsImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java
! src/share/jaxws_classes/com/sun/tools/etc/META-INF/services/com.sun.tools.internal.xjc.Plugin
! src/share/jaxws_classes/com/sun/tools/internal/jxc/ConfigReader.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/NGCCRuntimeEx.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/SchemaGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/SchemaGeneratorFacade.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/SecureLoader.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/AnnotationParser.java
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/Options.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/SchemaGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/ap/SecureLoader.java
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/api/JXC.java
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/api/impl/j2s/JAXBModelImpl.java
+ src/share/jaxws_classes/com/sun/tools/internal/jxc/api/impl/j2s/JavaCompilerImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/Invoker.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/ToolVersion.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/WsGen.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/WsImport.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/TJavaGeneratorExtension.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/WsgenExtension.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/WsgenProtocol.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensible.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtension.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLOperation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/api/wsdl/TWSDLParserContext.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/package-info.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/ProcessorException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/CustomExceptionGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorBase.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorExtension.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/GeneratorUtil.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/JavaGeneratorExtensionFacade.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/JwsImplGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/Names.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/SeiGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/ServiceGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/generator/W3CAddressingJavaGeneratorExtension.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/AbstractType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/AsyncOperation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/AsyncOperationType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Block.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ExtendedModelVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Fault.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/HeaderFault.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Message.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Model.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelObject.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelProperties.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/ModelVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Operation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Parameter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Port.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Request.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Response.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/Service.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/exporter/ExternalObject.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaArrayType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaInterface.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaMethod.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaParameter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaSimpleType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaStructureMember.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaStructureType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/java/JavaType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBElementMember.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBMapping.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBModel.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBProperty.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBStructuredType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBTypeAndAnnotation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBTypeVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/RpcLitMember.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/RpcLitStructure.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/model/jaxb/Util.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/JavaSimpleTypeCreator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/Modeler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/ModelerConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/ModelerException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/AnnotationProcessorContext.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/FaultInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/MakeSafeTypeVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/MemberInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/ModelBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeModeler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeMoniker.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/TypeMonikerFactory.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceAp.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceWrapperGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/annotation/WrapperInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/AccessorElement.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ClassNameAllocatorImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ConsoleErrorReporter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/JAXBModelBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ModelerUtils.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/PseudoSchemaBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModeler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModelerBase.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/util/ClassNameCollector.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/util/DirectoryUtil.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/processor/util/IndentingWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ConfigurationMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/GeneratorMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/JavacompilerMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ModelMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ModelerMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/ProcessorMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/UtilMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WebserviceapMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WsdlMessages.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/configuration_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/generator_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/javacompiler_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/model_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/modeler_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/processor_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/util_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/webserviceap_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wsdl_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/spi/WSToolsObjectFactory.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/spi/package-info.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/util/ClassNameInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/util/ForkEntityResolver.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/util/WSDLFetcher.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/util/WSDLParseException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/util/WSToolsObjectFactoryImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/AbortException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/AuthInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/BadCommandLineException.java
- src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/ErrorReceiver.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/ErrorReceiverFilter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/FilerCodeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Plugin.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WSCodeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenOptions.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportListener.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/plugin/at_generated/PluginImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Binding.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingFault.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingInput.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingOperation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/BindingOutput.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Definitions.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Documentation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Fault.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Import.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Input.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Kinds.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Message.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/MessagePart.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Operation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/OperationStyle.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Output.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Port.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/PortType.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Service.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/Types.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLDocument.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLDocumentVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/WSDLDocumentVisitorBase.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPAddress.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPBinding.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPOperation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPUrlEncoded.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/http/HTTPUrlReplacement.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/CustomName.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/Exception.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBinding.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBindingsConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/jaxws/Parameter.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEContent.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEMultipartRelated.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEPart.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/mime/MIMEXml.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaKinds.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAP12Binding.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAP12Constants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPAddress.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPBinding.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPBody.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPFault.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPHeader.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPHeaderFault.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPOperation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPStyle.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPUse.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/AbstractDocument.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Defining.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/DuplicateEntityException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Elemental.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Entity.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/EntityAction.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/EntityReferenceAction.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/EntityReferenceValidator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensibilityHelper.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensionImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensionVisitor.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExtensionVisitorBase.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ExternalEntityReference.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/GlobalEntity.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/GloballyKnown.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Identifiable.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/Kind.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/NoSuchEntityException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ParserListener.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/QNameAction.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/TWSDLParserContextImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/framework/WSDLLocation.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/AbstractExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/AbstractReferenceFinderImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Constants.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestParser.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestScanner.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/HTTPExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/InternalizationLogic.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Internalizer.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/JAXWSBindingExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/MIMEExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/MemberSubmissionAddressingExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/MetadataFinder.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/NamespaceContextImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Policy12ExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Policy15ExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/SOAP12ExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/SOAPEntityReferenceValidator.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/SOAPExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/Util.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/VersionChecker.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingMetadataExtensionHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/WSDLInternalizationLogic.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/WSDLParser.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/WhitespaceStripper.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/ClassLoaderBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/Driver.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/Messages.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/ModelLoader.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SecureLoader.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/XJCFacade.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/api/XJC.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/s2j/SchemaCompilerImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/s2j/TypeAndAnnotationImpl.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlIsSetWriter.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlLocationWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/DualObjectFactoryGenerator.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractFieldWithVar.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CArrayInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CBuiltinLeafInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/TypeUtil.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIUserConversion.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMBuilder.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/Internalizer.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/SCDBasedBindingSet.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/AnnotationParserFactoryImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/DomHandlerEx.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle_zh_TW.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle_zh_TW.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/util/DOMUtils.java
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_de.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_es.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_fr.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_it.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_ja.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_ko.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_pt_BR.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_zh_CN.properties
+ src/share/jaxws_classes/com/sun/tools/internal/xjc/util/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/util/Util.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/InternalAccessorFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/WhiteSpaceProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/api/JAXBRIContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/api/impl/NameConverter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/api/impl/NameUtil.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/SAX2DOMEx.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/util/SecureLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/ClassFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/ContextFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/ErrorHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/PropertyInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/PropertyKind.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/Ref.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ArrayInfoImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilderI.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ReferencePropertyInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ParameterizedTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/SecureLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/util/ArrayInfoUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/LeafBeanInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/SwaRefAdapterMarker.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java
- src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/ListElementProperty.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementLeafProperty.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DomLoader.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallerImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/Messages_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/package-info.java
+ src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/SOAPExceptionImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnectionFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/Header.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MessagingException.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MultipartDataSource.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentDisposition.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentType.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/HeaderTokenizer.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeBodyPart.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeMultipart.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePartDataSource.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePullMultipart.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeUtility.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParameterList.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParseException.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/SharedInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/UniqueValue.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/ASCIIUtility.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BASE64DecoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BASE64EncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/BEncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/LineInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/OutputUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QDecoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QEncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QPDecoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/QPEncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/UUDecoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/UUEncoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/Envelope.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/GifDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/JpegDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/MultipartDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocument.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPIOException.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/SOAPVersionMismatchException.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPFactoryDynamicImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailEntryImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderElementImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/impl/TreeException.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/BodyElement1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/DetailEntry1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/FaultElement1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPFactory1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPMessageFactory1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/BodyElement1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/DetailEntry1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/FaultElement1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Message1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPFactory1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPMessageFactory1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/Base64.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ByteInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ByteOutputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/LogDomainConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/MimeHeadersUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/NamespaceContextIterator.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/ParserPool.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/SAAJUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/TeeInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java
! src/share/jaxws_classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/ASCIIUtility.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/BASE64DecoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/Chunk.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/ChunkInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/CleanUpExecutorFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/Data.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DataFile.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DataHead.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DecodingException.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/FileData.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/Header.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/InternetHeaders.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/LineInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEEvent.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParsingException.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEPart.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MimeUtility.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/PropUtil.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/QPDecoderStream.java
+ src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/UUDecoderStream.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java
! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamReaderEx.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyle.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyleFeature.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/Databinding.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingMode.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingModeFeature.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/JavaCallInfo.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/ContentType.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/DistributedPropertySet.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContext.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContextFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/PropertySet.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/NamespaceContexHelper.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/Closeable.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/EPRSDDocumentFilter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/EndpointReferenceUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/ProblemAction.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/ProblemHeaderQName.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CAddressingConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CAddressingMetadataConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CWsaClientTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/W3CWsaServerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WSEPRExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaActionUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaClientTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaPropertyBag.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaServerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelperImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/model/ActionNotSupportedException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/model/InvalidAddressingHeaderException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/model/MissingAddressingHeaderException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingFeatureConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingPolicyMapConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingPolicyValidator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/policy/AddressingPrefixMapper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionAddressingConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaClientTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaServerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/ProblemAction.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/ProblemHeaderQName.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/v200408/WsaTubeHelperImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/BindingID.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/BindingIDFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/Cancelable.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/Component.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentEx.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentRegistry.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/ComponentsFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/DistributedPropertySet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/EndpointAddress.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/FeatureConstructor.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/FeatureListValidator.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/FeatureListValidatorAnnotation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ImpliesWebServiceFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/PropertySet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ResourceLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/SOAPVersion.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ServiceSharedFeatureMarker.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSBinding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSDLLocator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSFeatureList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WSService.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/WebServiceFeatureFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/AddressingPropertySet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/AddressingVersion.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/EPRHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/NonAnonymousResponseProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/OneWayFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/OutboundReferenceParameterHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/WSEndpointReference.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/addressing/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ClientPipelineHook.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/SelectOptimalEncodingFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ServiceInterceptor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ServiceInterceptorFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/ThrowableInPacketCompletionFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/client/WSPortInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/EndpointCreationAttributes.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/ManagedEndpointFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/Reconfigurable.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/policy/ManagedClientAssertion.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/policy/ManagedServiceAssertion.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/config/management/policy/ManagementAssertion.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/ClientCallBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/Databinding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/DatabindingConfig.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/DatabindingFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/EndpointCallBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/JavaCallInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/MappingInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/MetadataReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/SoapBodyStyle.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/WSDLGenInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/fastinfoset/FastInfosetFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ha/HaInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/ha/StickyFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/handler/MessageHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/handler/MessageHandlerContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/AddressingUtils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Attachment.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/AttachmentEx.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/AttachmentSet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/ExceptionHasMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/FilterMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Header.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/HeaderList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Headers.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Message.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageContextFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageHeaders.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageMetadata.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageWrapper.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/MessageWritable.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/SuppressAutomaticWSARequestHeadersFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SAAJMessageHeaders.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SaajStaxWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/stream/InputStreamMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/stream/StreamBasedMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/stream/XMLStreamReaderMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/CheckedException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/ExceptionType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/JavaMethod.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/MEP.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/Parameter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/ParameterBinding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/SEIModel.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/WSDLOperationMapping.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/soap/SOAPBinding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLDescriptorKind.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFeaturedObject.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLInput.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLObject.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPart.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPartDescriptor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ClientPipeAssemblerContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ClientTubeAssemblerContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Codecs.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ContentType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Engine.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Fiber.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptorFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/NextAction.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Pipe.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipeCloner.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipelineAssembler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/PipelineAssemblerFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/SOAPBindingCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ServerPipeAssemblerContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ServerTubeAssemblerContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/StreamSOAPCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Stubs.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/SyncStartForAsyncFeature.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/ThrowableContainerPropertySet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TransportPipeFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TransportTubeFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Tube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TubeCloner.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TubelineAssembler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/TubelineAssemblerFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractFilterPipeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractFilterTubeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractPipeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractTubeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/PipeAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/helper/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/AlternativeSelector.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ModelGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ModelTranslator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ModelUnmarshaller.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/PolicyResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/PolicyResolverFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/SourceModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/ValidationProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/policy/subject/BindingSubject.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractServerAsyncTransport.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Adapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AsyncProvider.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AsyncProviderCallback.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/BoundEndpoint.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ContainerResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/DocumentAddressResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointAwareCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointComponent.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointData.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/EndpointReferenceExtensionContributor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/HttpEndpoint.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolverAnnotation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Invoker.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/LazyMOMProvider.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Module.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/PortAddressResolver.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ProviderInvokerTubeFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ResourceInjector.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/SDDocument.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/SDDocumentFilter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/SDDocumentSource.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ServerPipelineHook.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ServiceDefinition.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/TransportBackChannel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WSEndpoint.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WSWebServiceContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WebModule.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/WebServiceContextDelegate.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/MetaDataResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/MetadataResolverFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/PolicyWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/ServiceDescriptor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/XMLEntityResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGenExtnContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/DefaultClientTubelineAssemblyContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/DefaultServerTubelineAssemblyContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigLoader.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigName.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigNameImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroTubelineAssembler.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubeCreator.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubelineAssemblyContextImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubelineAssemblyController.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/ClientTubelineAssemblyContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/ServerTubelineAssemblyContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubelineAssemblyContext.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubelineAssemblyContextUpdater.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/dev/TubelineAssemblyDecorator.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws-tubes-default.xml
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/AddressingTubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/BasicTransportTubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/HandlerTubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/MonitoringTubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/MustUnderstandTubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/TerminalTubeFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws/ValidationTubeFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/BindingImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/FeatureListUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/HTTPBindingImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/SOAPBindingImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/AsyncInvoker.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/AsyncResponseImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/BindingProviderProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ClientContainer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ClientSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ClientTransportException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ContentNegotiation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/HandlerConfiguration.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/HandlerConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/RequestContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ResponseContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/ResponseContextReceiver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SCAnnotations.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SEIPortInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SenderException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/DataSourceDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/DispatchImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/JAXBDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/MessageDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/PacketDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/RESTSourceDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/SOAPMessageDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/SOAPSourceDispatch.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/AsyncMethodHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/BodyBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/CallbackMethodHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MessageFiller.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/PollingMethodHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ResponseBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIMethodHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/StubAsyncHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/StubHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SyncMethodHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueGetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueGetterFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueSetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/ValueSetterFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/pacakge-info.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/config/management/policy/ManagementAssertionCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/config/management/policy/ManagementPolicyValidator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/config/management/policy/ManagementPrefixMapper.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/config/metro/dev/FeatureReader.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/config/metro/util/ParserUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingFactoryImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingProviderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/BridgeWrapper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/JAXBRIContextFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/JAXBRIContextWrapper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/MarshallerBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/RawAccessorWrapper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/db/glassfish/WrapperBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/BindingTypeFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/EPRRecipe.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/HttpConfigFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/JAXBContextFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/JAXWSProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressing.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressingFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/MemberSubmissionEndpointReference.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/SchemaValidation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/SchemaValidationFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/Serialization.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/SerializationFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/ServerSideException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/StreamingAttachment.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/StreamingAttachmentFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/UsesJAXBContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/UsesJAXBContextFeature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/ValidationErrorHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/WSBindingProvider.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/developer/package-info.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/dump/LoggingDumpTube.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumper.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumping.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumpingFeature.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumpingTube.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/dump/MessageDumpingTubeFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ContentType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ContentTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/DataHandlerDataSource.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/DataSourceStreamingDataHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/HasEncoding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/HeaderTokenizer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ImageDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MIMEPartStreamingDataHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MimeCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MimeMultipartParser.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/ParameterList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/RootOnlyCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/SOAPBindingCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StringDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/SwACodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/XMLHTTPBindingCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/XmlDataContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetMIMETypes.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamReaderFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamReaderRecyclable.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamSOAP11Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamSOAP12Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetStreamSOAPCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/EncodingConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/EncodingPolicyValidator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/EncodingPrefixMapper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/FastInfosetFeatureConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/MtomFeatureConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/MtomPolicyMapConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/policy/SelectOptimalEncodingFeatureConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/DeserializationException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SOAP12Constants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SOAPConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SerializationException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/SerializerConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/streaming/SOAP12NamespaceConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/soap/streaming/SOAPNamespaceConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/xml/XMLPropertyBag.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/CodeType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/DetailType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/ExceptionBean.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/ReasonType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAP11Fault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAP12Fault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/ServerSOAPFaultException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SubcodeType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/TextType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ClientLogicalHandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ClientMessageHandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ClientSOAPHandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerChainsModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/HandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/LogicalMessageContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/LogicalMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/MessageContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/MessageHandlerContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/MessageUpdatableContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/PortInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/SOAPHandlerProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/SOAPMessageContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ServerLogicalHandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ServerMessageHandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/ServerSOAPHandlerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/handler/XMLHandlerProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractHeaderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AttachmentSetImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AttachmentUnmarshallerImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/ByteArrayAttachment.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/DOMHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/DOMMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/DataHandlerAttachment.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/EmptyMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/FaultDetailHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/FaultMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/JAXBAttachment.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/MimeAttachmentSet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/PayloadElementSniffer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/ProblemActionHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/RelatesToHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/RootElementSniffer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/StringHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/Util.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/XMLReaderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/AttachmentMarshallerImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBBridgeSource.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBDispatchMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/MarshallerBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/source/PayloadSourceMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/source/ProtocolSourceMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/source/SourceUtils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/OutboundStreamHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/PayloadStreamReaderMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamAttachment.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamHeader11.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamHeader12.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/AbstractSEIModelImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/AbstractWrapperBeanGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/CheckedExceptionImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/FieldSignature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/Injector.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ParameterImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ReflectAnnotationReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModelerException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/SOAPSEIModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperParameter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/soap/SOAPBindingImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractFeaturedObjectImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractObjectImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLDirectProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartDescriptorImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassAdapter.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/org/objectweb/asm/MethodAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerEndpointScope.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerMessageScope.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerOperationScope.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/BuilderHandlerServiceScope.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/DefaultPolicyResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyMapBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLGeneratorExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/SafePolicyReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/WSDLBoundFaultContainer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/spi/PolicyFeatureConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/spi/PolicyMapConfigurator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/ClientMUTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/MUTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/MessageCreationException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/ServerMUTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/soap/VersionMismatchException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/protocol/xml/XMLMessageException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/AddressingMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/BindingApiMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ClientMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/DispatchMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/EncodingMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/HandlerMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/HttpserverMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ManagementMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ModelerMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/PolicyMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ProviderApiMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/SenderMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/ServerMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/SoapMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/TubelineassemblyMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/UtilMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsdlmodelMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/XmlmessageMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/addressing_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/bindingApi_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/client_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/encoding_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/handler_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/httpserver_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/management_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/modeler_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/policy_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/providerApi_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/sender_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/server_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/soap_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming_zh_TW.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/tubelineassembly.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/util_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsdlmodel_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/resources/xmlmessage_zh_TW.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/MetroConfig.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/ObjectFactory.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubeFactoryConfig.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubeFactoryList.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineDefinition.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineFeature.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineFeatureReader.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/TubelineMapping.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/Tubelines.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/runtime/config/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/AbstractMultiInstanceResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/AbstractWebServiceContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/DefaultResourceInjector.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/DraconianValidationErrorHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointAwareTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointMessageContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/InvokerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/MonitorBase.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/MonitorRootService.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServerPropertyConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServerRtException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServerSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/ServiceDefinitionImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SingletonResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/UnsupportedMediaException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSDLGenResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointMOMProxy.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/AsyncProviderInvokerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/MessageProviderArgumentBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/ProviderArgumentsBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/ProviderEndpointModel.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/ProviderInvokerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/SOAPProviderArgumentBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/SyncProviderInvokerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/provider/XMLProviderArgumentBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/EndpointArgumentsBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/EndpointResponseMessageBuilder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/EndpointValueSetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/Invoker.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/InvokerSource.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/InvokerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/MessageFiller.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/SEIInvokerTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/TieHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/sei/ValueGetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContextFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingHelper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/DatabindingException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/DatabindingProvider.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/FieldGetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/FieldSetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/JAXBWrapperAccessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/MethodGetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/MethodSetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/OldBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertyAccessor.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertyGetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertyGetterBase.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertySetter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/PropertySetterBase.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/RepeatedElementBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/TypeInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/WrapperAccessor.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/WrapperBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/WrapperComposite.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/XMLBridge.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/Attributes.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/DOMStreamReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/MtomStreamWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/PrefixFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/PrefixFactoryImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/SourceReaderFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/TidyXMLStreamReader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLReaderException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/DeferredTransportPipe.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/Headers.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/DeploymentDescriptorParser.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapterList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpMetadataPublisher.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/ResourceLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/WSHTTPConnection.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransport.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpResponseProperties.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/EndpointImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/HttpEndpoint.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/PortableConnectionImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/PortableHttpHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerAdapterList.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerContainer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/server/WSHttpHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ASCIIUtility.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ByteArrayBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ByteArrayDataSource.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/CompletedFuture.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/Constants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/DOMUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/FastInfosetReflection.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/FastInfosetUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/HandlerAnnotationInfo.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/InjectionPlan.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/JAXWSUtils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/MetadataUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/NamespaceSupport.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/NoCloseInputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/NoCloseOutputStream.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/Pool.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/QNameMap.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadAllStream.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadOnlyPropertyException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/RuntimeVersion.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ServiceConfigurationError.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/ServiceFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/StreamUtils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/StringUtils.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/UtilException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/Version.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/VersionUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/exception/JAXWSExceptionBase.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/exception/LocatableWebServiceException.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizable.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableImpl.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessage.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessageFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizer.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/NullLocalizable.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/DumpTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/StandalonePipeAssembler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/StandaloneTubeAssembler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_de.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_es.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_fr.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_it.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_ja.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_ko.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_pt_BR.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_zh_CN.properties
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en_zh_TW.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/CDATA.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/ContentHandlerToXMLStreamWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/DummyLocation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamedNodeMapIterator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NodeListIterator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/StAXResult.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/StAXSource.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderFilter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToXMLStreamWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLStreamWriterFilter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationSignature.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/DispatchException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/OperationDispatcher.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/SDDocumentResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/SOAPActionBasedOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/WSDLOperationFinder.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/EntityResolverWrapper.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/ErrorHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/InaccessibleWSDLException.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MIMEConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MexEntityResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/ParserUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/SOAPConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLConstants.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/DocumentLocationResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/TXWContentHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/UsingAddressing.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/W3CAddressingMetadataWSDLGeneratorExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/W3CAddressingWSDLGeneratorExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGeneratorExtensionFacade.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLPatcher.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Binding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/BindingOperationType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Definitions.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Documented.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Fault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/FaultType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Import.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Message.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/OpenAtts.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Operation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/ParamType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Part.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Port.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/PortType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Service.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/StartWithExtensionsType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/Types.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/Address.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/Binding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/Operation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/http/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/Body.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/BodyType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/Header.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/HeaderFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPAddress.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPBinding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/SOAPOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/Body.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/BodyType.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/Header.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/HeaderFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPAddress.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPBinding.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPFault.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/SOAPOperation.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/soap12/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/xsd/Import.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/xsd/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/document/xsd/package-info.java
! src/share/jaxws_classes/javax/annotation/Generated.java
! src/share/jaxws_classes/javax/annotation/PostConstruct.java
! src/share/jaxws_classes/javax/annotation/PreDestroy.java
! src/share/jaxws_classes/javax/annotation/Resource.java
! src/share/jaxws_classes/javax/annotation/Resources.java
! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java
! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java
! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java
! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java
! src/share/jaxws_classes/javax/xml/bind/Marshaller.java
! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlInlineBinaryData.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMimeType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java
! src/share/jaxws_classes/javax/xml/soap/AttachmentPart.java
! src/share/jaxws_classes/javax/xml/soap/Detail.java
! src/share/jaxws_classes/javax/xml/soap/DetailEntry.java
! src/share/jaxws_classes/javax/xml/soap/FactoryFinder.java
! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java
! src/share/jaxws_classes/javax/xml/soap/MimeHeader.java
! src/share/jaxws_classes/javax/xml/soap/MimeHeaders.java
! src/share/jaxws_classes/javax/xml/soap/Name.java
! src/share/jaxws_classes/javax/xml/soap/Node.java
! src/share/jaxws_classes/javax/xml/soap/SAAJMetaFactory.java
! src/share/jaxws_classes/javax/xml/soap/SAAJResult.java
! src/share/jaxws_classes/javax/xml/soap/SOAPBody.java
! src/share/jaxws_classes/javax/xml/soap/SOAPBodyElement.java
! src/share/jaxws_classes/javax/xml/soap/SOAPConnection.java
! src/share/jaxws_classes/javax/xml/soap/SOAPConnectionFactory.java
! src/share/jaxws_classes/javax/xml/soap/SOAPConstants.java
! src/share/jaxws_classes/javax/xml/soap/SOAPElement.java
! src/share/jaxws_classes/javax/xml/soap/SOAPElementFactory.java
! src/share/jaxws_classes/javax/xml/soap/SOAPEnvelope.java
! src/share/jaxws_classes/javax/xml/soap/SOAPException.java
! src/share/jaxws_classes/javax/xml/soap/SOAPFactory.java
! src/share/jaxws_classes/javax/xml/soap/SOAPFault.java
! src/share/jaxws_classes/javax/xml/soap/SOAPFaultElement.java
! src/share/jaxws_classes/javax/xml/soap/SOAPHeader.java
! src/share/jaxws_classes/javax/xml/soap/SOAPHeaderElement.java
! src/share/jaxws_classes/javax/xml/soap/SOAPMessage.java
! src/share/jaxws_classes/javax/xml/soap/SOAPPart.java
! src/share/jaxws_classes/javax/xml/soap/Text.java
! src/share/jaxws_classes/javax/xml/ws/WebServiceRefs.java
! src/share/jaxws_classes/javax/xml/ws/handler/Handler.java
! src/share/jaxws_classes/javax/xml/ws/soap/AddressingFeature.java
! src/share/jaxws_classes/javax/xml/ws/soap/MTOMFeature.java
! src/share/jaxws_classes/javax/xml/ws/spi/FactoryFinder.java
! src/share/jaxws_classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java

Changeset: a5e7c2f093c9
Author:    lana
Date:      2013-04-16 08:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/a5e7c2f093c9

Merge

- src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlIsSetWriter.java
- src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlLocationWriter.java
- src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyle.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyleFeature.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/Databinding.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingMode.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingModeFeature.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/JavaCallInfo.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/ContentType.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/DistributedPropertySet.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContext.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContextFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/PropertySet.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadOnlyPropertyException.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizable.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableImpl.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessage.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessageFactory.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizer.java
- src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/NullLocalizable.java

Changeset: 8abe95530f58
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/8abe95530f58

Added tag jdk8-b86 for changeset a5e7c2f093c9

! .hgtags



From john.coomes at oracle.com  Fri Apr 19 04:40:55 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:40:55 +0000
Subject: hg: hsx/hotspot-gc/jdk: 50 new changesets
Message-ID: <20130419045128.80B834845E@hg.openjdk.java.net>

Changeset: 87c62f03bc07
Author:    jgodinez
Date:      2013-03-27 12:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/87c62f03bc07

8010005: [parfait] Memory leak in jdk/src/macosx/native/sun/awt/CTextPipe.m
Reviewed-by: bae, prr
Contributed-by: jia-hong.chen at oracle.com

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 9d4f539e36b6
Author:    lana
Date:      2013-04-02 17:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9d4f539e36b6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 2904672aed21
Author:    lana
Date:      2013-04-09 14:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2904672aed21

Merge


Changeset: 96750ebc769b
Author:    denis
Date:      2013-03-27 16:19 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/96750ebc769b

7075105: WIN: Provide a way to format HTML on drop
Reviewed-by: uta, serb

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HtmlTransferable.java
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutAllHtmlFlavorsOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutOnlyAllHtmlFlavorOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutSelectionAndFragmentHtmlFlavorsOnClipboard.java

Changeset: 29570523b6cb
Author:    ant
Date:      2013-03-29 16:12 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/29570523b6cb

8010375: sun.swing.JLightweightFrame should be implemented for XToolkit
Reviewed-by: anthony

! src/share/classes/sun/swing/JLightweightFrame.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
+ src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: c23d58901aa6
Author:    lana
Date:      2013-04-02 16:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c23d58901aa6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 36cb7921bc98
Author:    mcherkas
Date:      2013-04-03 20:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/36cb7921bc98

8011123: serialVersionUID of java.awt.dnd.InvalidDnDOperationException changed in JDK8-b82
Reviewed-by: anthony, serb

! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java

Changeset: 35da3878deef
Author:    mcherkas
Date:      2013-04-03 20:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/35da3878deef

8010925: COPY AND PASTE TO AND FROM SIGNED APPLET FAILS AFTER FIRST INTERNAL COPY PRFRMD
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/native/sun/awt/CClipboard.m

Changeset: 2c36899500a0
Author:    pchelko
Date:      2013-04-05 18:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2c36899500a0

8006941: [macosx] Deadlock in drag and drop
7199783: Setting cursor on DragSourceContext does not work on OSX
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CDragSource.h
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CDropTarget.m
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
+ test/java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java

Changeset: 0b083b0e8e63
Author:    kshefov
Date:      2013-04-08 17:18 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0b083b0e8e63

7153702: [TEST_BUG] [macosx] Synchronization problem in test javax/swing/JPopupMenu/6827786/bug6827786.java
Reviewed-by: serb, alexsch

! test/javax/swing/JPopupMenu/6827786/bug6827786.java

Changeset: 981142561d1b
Author:    lana
Date:      2013-04-09 15:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/981142561d1b

Merge


Changeset: 3b56ef8e1ce1
Author:    martin
Date:      2013-03-26 13:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3b56ef8e1ce1

8007905: To add a system property to create zip file without using ZIP64 end table when entry count > 64k
Summary: Provide a system property to inhibit ZIP64 mode for >64k entries
Reviewed-by: alanb, sherman

! src/share/classes/java/util/zip/ZipOutputStream.java
+ test/java/util/zip/EntryCount64k.java

Changeset: 266b43683a2c
Author:    martin
Date:      2013-03-26 13:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/266b43683a2c

8010316: Improve handling of char sequences containing surrogates
Summary: Fix and optimize codePointAt, codePointBefore and similar methods
Reviewed-by: sherman, okutsu, ulfzibis, kizune

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/Character.java
! test/java/lang/StringBuilder/Supplementary.java

Changeset: caafe6dca35d
Author:    ehelin
Date:      2013-03-21 20:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/caafe6dca35d

8009427: Re-enable tests that were disable to ease complicated push
Reviewed-by: sla, mchung, dcubed
Contributed-by: Erik Helin <erik.helin at oracle.com>

! test/ProblemList.txt

Changeset: 49602f599c08
Author:    dxu
Date:      2013-03-27 09:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/49602f599c08

8010837: FileInputStream.available() throw IOException when encountering negative available values
Summary: Remove the check in the native code to allow negative values
Reviewed-by: mchung

! src/solaris/native/java/io/io_util_md.c
+ test/java/io/FileInputStream/NegativeAvailable.java

Changeset: ae03282ba501
Author:    darcy
Date:      2013-03-27 09:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ae03282ba501

7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
Reviewed-by: mduigou, jfranck

! src/share/classes/sun/reflect/annotation/AnnotationType.java

Changeset: d254a5f9b93f
Author:    acorn
Date:      2013-03-27 13:40 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d254a5f9b93f

8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52
Reviewed-by: acorn, hseigel

! test/vm/verifier/TestStaticIF.java

Changeset: 811c771acf65
Author:    sundar
Date:      2013-03-28 14:36 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/811c771acf65

8010991: Enable test/javax/script/GetInterfaceTest.java again
Reviewed-by: lagergren, hannesw

! test/javax/script/GetInterfaceTest.java

Changeset: a87fac00915e
Author:    weijun
Date:      2013-03-28 20:27 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a87fac00915e

8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/keytool/Main.java
! src/share/classes/sun/security/tools/keytool/Resources.java
+ test/sun/security/tools/keytool/p12importks.sh

Changeset: e433ed08b733
Author:    mchung
Date:      2013-03-28 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e433ed08b733

8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level
Reviewed-by: mchung
Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com

! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

Changeset: b590bd37a6d0
Author:    mduigou
Date:      2013-04-01 12:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b590bd37a6d0

8010268: Remove dependence upon clean target from jdk/test/Makefile prep target
Reviewed-by: tbell, mchung

! test/Makefile

Changeset: 0cccdb9a9a4c
Author:    mduigou
Date:      2013-04-01 20:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0cccdb9a9a4c

7143928: Optimize empty HashMap and ArrayList
Reviewed-by: mduigou
Contributed-by: Sergey Linetskiy <sergey.linetskiy at oracle.com>, John Rose <john.rose at oracle.com>, Mike Duigou <mike.duigou at oracle.com>

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
+ test/java/util/Map/BasicSerialization.java

Changeset: 5ee837ba093a
Author:    mduigou
Date:      2013-04-01 20:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5ee837ba093a

8011187: Remove obsolete/unused targets from jdk/test/Makefile
Reviewed-by: ohair

! test/Makefile

Changeset: de228734b742
Author:    mduigou
Date:      2013-04-01 20:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/de228734b742

8011199: Backout changeset JDK-7143928 (0cccdb9a9a4c)
Reviewed-by: darcy, dholmes

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
- test/java/util/Map/BasicSerialization.java

Changeset: f1b89d4cce82
Author:    sla
Date:      2013-04-02 10:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f1b89d4cce82

8009558: linked_md.c::dll_build_name can get stuck in an infinite loop
Reviewed-by: alanb, sspitsyn

! src/share/back/export/sys.h
! src/share/back/transport.c
! src/share/demo/jvmti/hprof/hprof_md.h
! src/solaris/back/linker_md.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/windows/back/linker_md.c
! src/windows/demo/jvmti/hprof/hprof_md.c

Changeset: e6c3b8e74e50
Author:    sherman
Date:      2013-04-02 10:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e6c3b8e74e50

8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding
8008925: Base64.getMimeDecoder().decode() does not ignore padding chars
Summary: updated implementation and spec for corner cases.
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: 7fbae9125437
Author:    lana
Date:      2013-04-02 11:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7fbae9125437

Merge


Changeset: b4f68aca1000
Author:    darcy
Date:      2013-04-02 16:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b4f68aca1000

8004979: java.lang.reflect.Modifier.toString should include "default"
Reviewed-by: mduigou

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! test/java/lang/reflect/Method/GenericStringTest.java

Changeset: c534937f6e94
Author:    alanb
Date:      2013-04-03 13:15 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c534937f6e94

8011234: Performance regression with ftp protocol when uploading in image mode
Reviewed-by: chegar

! src/share/classes/sun/net/ftp/impl/FtpClient.java

Changeset: eb8f7bc6f964
Author:    alanb
Date:      2013-04-03 13:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eb8f7bc6f964

8011373: Property java.runtime.profile should be removed (left-over code)
Reviewed-by: lancea, dholmes

! src/share/classes/sun/misc/Version.java.template

Changeset: 27ae4f9c7826
Author:    lancea
Date:      2013-04-03 12:47 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/27ae4f9c7826

8011393: Typo in javadoc for SerialClob.truncate
Reviewed-by: darcy

! src/share/classes/javax/sql/rowset/serial/SerialClob.java

Changeset: 9a6ef3391f32
Author:    naoto
Date:      2013-04-03 10:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9a6ef3391f32

7091601: Arabic Locale: can not set type of digit in application level
Reviewed-by: okutsu

! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

Changeset: 7b1189bf1d7b
Author:    dxu
Date:      2013-04-04 15:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7b1189bf1d7b

8000406: change files using @GenerateNativeHeader to use @Native
Summary: Use @Native annotation to mark constants interested by native codes
Reviewed-by: alanb, anthony, prr

! src/macosx/classes/apple/laf/JRSUIConstants.java
! src/macosx/classes/com/apple/eawt/FullScreenHandler.java
! src/macosx/classes/com/apple/eawt/event/GestureHandler.java
! src/macosx/classes/sun/java2d/OSXSurfaceData.java
! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java
! src/macosx/native/jobjc/src/core/native/Invoke.m
! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m
! src/macosx/native/sun/awt/PrinterView.m
! src/share/classes/java/awt/Adjustable.java
! src/share/classes/java/awt/AlphaComposite.java
! src/share/classes/java/awt/BasicStroke.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/DisplayMode.java
! src/share/classes/java/awt/Image.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/SystemColor.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/Transparency.java
! src/share/classes/java/awt/color/ColorSpace.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/datatransfer/StringSelection.java
! src/share/classes/java/awt/dnd/DnDConstants.java
! src/share/classes/java/awt/event/ActionEvent.java
! src/share/classes/java/awt/event/AdjustmentEvent.java
! src/share/classes/java/awt/event/ComponentEvent.java
! src/share/classes/java/awt/event/FocusEvent.java
! src/share/classes/java/awt/event/InputMethodEvent.java
! src/share/classes/java/awt/event/MouseWheelEvent.java
! src/share/classes/java/awt/event/WindowEvent.java
! src/share/classes/java/awt/geom/PathIterator.java
! src/share/classes/java/awt/image/AffineTransformOp.java
! src/share/classes/java/awt/image/ConvolveOp.java
! src/share/classes/java/awt/image/DataBuffer.java
! src/share/classes/java/awt/image/ImageConsumer.java
! src/share/classes/java/awt/image/ImageObserver.java
! src/share/classes/java/awt/peer/ComponentPeer.java
! src/share/classes/java/awt/print/PageFormat.java
! src/share/classes/java/awt/print/Pageable.java
! src/share/classes/java/awt/print/Printable.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/SunHints.java
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
! src/share/classes/sun/awt/image/BufImgSurfaceData.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLContext.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java
! src/share/classes/sun/java2d/pipe/BufferedPaints.java
! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java
! src/share/classes/sun/java2d/pipe/RenderBuffer.java
! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java
! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java
! src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java
! src/share/classes/sun/security/pkcs11/Secmod.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java
! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java
! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java
! src/solaris/native/sun/awt/awt_InputMethod.c
! src/solaris/native/sun/awt/fontpath.c
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/java2d/d3d/D3DContext.java
! src/windows/classes/sun/java2d/d3d/D3DPaints.java
! src/windows/native/sun/java2d/d3d/D3DContext.h
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_DnDDS.cpp
! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_List.h
! src/windows/native/sun/windows/awt_PopupMenu.cpp
! src/windows/native/sun/windows/awt_PopupMenu.h
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_Toolkit.cpp

Changeset: 7d4e30730f80
Author:    valeriep
Date:      2013-04-04 20:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7d4e30730f80

7155720: PKCS11 minor issues in native code
Summary: Added OOM handling to address the two issues found by parfait.
Reviewed-by: weijun

! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c

Changeset: b62a76763bf3
Author:    mchung
Date:      2013-04-05 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b62a76763bf3

8011380: FX dependency on PlatformLogger broken by 8010309
Reviewed-by: alanb

! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/sun/util/logging/LoggingProxy.java
! src/share/classes/sun/util/logging/LoggingSupport.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

Changeset: b702977e7212
Author:    khazra
Date:      2013-04-05 12:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b702977e7212

5001942: Missings SOCKS support for direct connections
Summary: Add support for socksNonProxyHosts
Reviewed-by: chegar, khazra
Contributed-by: Christos Zoulas <christos at zoulas.com>

! src/share/classes/sun/net/spi/DefaultProxySelector.java
! test/java/net/Socks/SocksProxyVersion.java

Changeset: ba231ac2890a
Author:    lana
Date:      2013-04-05 14:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ba231ac2890a

Merge


Changeset: 785f3a04ee05
Author:    dxu
Date:      2013-04-05 17:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/785f3a04ee05

8011602: jobjc build failure on Mac
Summary: Remove @Native annotation from macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
Reviewed-by: mchung, dholmes

! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/share/classes/sun/java2d/opengl/OGLContext.java

Changeset: 16f63a94c231
Author:    darcy
Date:      2013-04-05 18:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/16f63a94c231

8011590: More tests for core reflection modeling of default methods
Reviewed-by: mduigou

+ test/java/lang/reflect/Method/DefaultMethodModeling.java

Changeset: 04617e462512
Author:    lancea
Date:      2013-04-08 15:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/04617e462512

8006036: (process) cleanup code in java/lang/Runtime/exec/WinCommand.java
Reviewed-by: lancea
Contributed-by: Jim Gish <jim.gish at oracle.com>

! test/java/lang/Runtime/exec/WinCommand.java

Changeset: 3db793b080d8
Author:    martin
Date:      2013-04-08 16:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3db793b080d8

8010849: (str) Optimize StringBuilder.append(null)
Summary: Append 4 chars instead of the string "null"
Reviewed-by: mduigou, forax, jgish

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 3e5a18c3e599
Author:    darcy
Date:      2013-04-08 17:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3e5a18c3e599

6298888: Add toGenericString to j.l.Class and getTypeName to j.l.reflect.Type
6992705: Include modifiers in Class.toGenericString()
Summary: Class.toGenericString and supporting changes; additional reviews by Peter Levart
Reviewed-by: alanb

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/java/lang/reflect/Type.java
+ test/java/lang/Class/GenericStringTest.java

Changeset: 57e9eaeca323
Author:    alanb
Date:      2013-04-09 15:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/57e9eaeca323

8010393: Update JAX-WS RI to 2.2.9-b12941
Reviewed-by: mullan

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 50bc8e085a09
Author:    chegar
Date:      2013-04-09 17:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/50bc8e085a09

8005696: Add CompletableFuture
Reviewed-by: chegar, martin

! make/java/java/FILES_java.gmk
+ src/share/classes/java/util/concurrent/CompletableFuture.java
+ src/share/classes/java/util/concurrent/CompletionException.java
+ test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: f304311cfe9f
Author:    lana
Date:      2013-04-09 15:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f304311cfe9f

Merge

! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java

Changeset: 6e3763e737b0
Author:    lana
Date:      2013-04-16 08:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6e3763e737b0

Merge


Changeset: e5c5e369af6a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e5c5e369af6a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
! test/java/lang/reflect/Method/IsDefaultTest.java
! test/java/net/URLConnection/RequestProperties.java
! test/java/util/Optional/BasicDouble.java
! test/javax/swing/text/html/7189299/bug7189299.java
! test/sun/management/jdp/JdpTest.sh
! test/sun/misc/URLClassPath/JarLoaderTest.java
! test/sun/util/calendar/zi/ZoneInfoFile.java

Changeset: b45456703c65
Author:    katleman
Date:      2013-04-15 14:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b45456703c65

Merge


Changeset: 7989cd0cc3a9
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7989cd0cc3a9

Merge


Changeset: f4c62eecf7fa
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f4c62eecf7fa

Added tag jdk8-b86 for changeset 7989cd0cc3a9

! .hgtags



From john.coomes at oracle.com  Fri Apr 19 04:54:36 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:54:36 +0000
Subject: hg: hsx/hotspot-gc/langtools: 22 new changesets
Message-ID: <20130419045544.78EE64845F@hg.openjdk.java.net>

Changeset: 330b35b27e68
Author:    darcy
Date:      2013-03-26 17:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/330b35b27e68

7041251: Use j.u.Objects utility methods in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/javax/annotation/processing/AbstractProcessor.java

Changeset: 33b6a52f0037
Author:    darcy
Date:      2013-03-26 18:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/33b6a52f0037

7059170: Assume availablility of URLClassLoader.close
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java

Changeset: 7bebe17ff323
Author:    mcimadamore
Date:      2013-03-28 11:38 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/7bebe17ff323

8010469: Bad assertion in LambdaToMethod
Summary: Add assertion in LambdaToMethod.serializedLambdaName
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: a200d8ccfe47
Author:    mcimadamore
Date:      2013-03-28 11:39 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a200d8ccfe47

8010490: FindBugs: double assignments in LambdaToMethod.visitIdent
Summary: Remove dead code from LambdaToMethod
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: 991f11e13598
Author:    jjg
Date:      2013-03-28 10:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/991f11e13598

8006346: doclint should make allowance for headers generated by standard doclet
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Env.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
+ test/tools/javac/doclint/ImplicitHeadersTest.java
+ test/tools/javadoc/doclint/ImplicitHeadersTest.java

Changeset: d3648557391b
Author:    jjg
Date:      2013-03-28 10:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d3648557391b

8010511: Tests are creating files in /tmp
Reviewed-by: darcy

! test/tools/javac/T6558476.java
! test/tools/javac/T6900149.java
! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/RunExamples.java

Changeset: 29c6984a1673
Author:    vromero
Date:      2013-04-02 10:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/29c6984a1673

4965689: class literal code wastes a byte
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
+ test/tools/javac/T4965689/ClassLiteralWastesByteTest.java

Changeset: 46d2f144ebbd
Author:    lana
Date:      2013-04-02 12:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/46d2f144ebbd

Merge


Changeset: 0d47e6131490
Author:    darcy
Date:      2013-04-03 12:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0d47e6131490

8011052: Add DEFAULT to javax.lang.model.Modifier
Reviewed-by: abuckley, jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/javax/lang/model/element/Modifier.java
! test/tools/javac/processing/model/element/TestExecutableElement.java

Changeset: e06dc8345d9c
Author:    lana
Date:      2013-04-05 14:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e06dc8345d9c

Merge


Changeset: b71a61d39cf7
Author:    mcimadamore
Date:      2013-04-08 15:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b71a61d39cf7

8010922: Cleanup: add support for ad-hoc method check logic
Summary: Support pluggable method checkers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: b54122b9372d
Author:    mcimadamore
Date:      2013-04-08 15:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b54122b9372d

8010823: DefaultMethodTest.testReflectCall fails with new lambda VM
Summary: Fix lambda test
Reviewed-by: jjg

! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: e9d986381414
Author:    mcimadamore
Date:      2013-04-08 15:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e9d986381414

8010404: Lambda debugging: redundant LineNumberTable entry for lambda capture
Summary: Ignore indy entries in LineNumberTable
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! test/tools/javac/lambda/TestInvokeDynamic.java

Changeset: 94a202228ec2
Author:    mcimadamore
Date:      2013-04-08 15:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/94a202228ec2

8009131: Overload: javac should discard methods that lead to errors in lambdas with implicit parameter types
Summary: Lambdas that have errors in their bodies should make enclosing overload resolution fail
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/BadArgTypesInLambda.java
! test/tools/javac/lambda/BadRecovery.out
! test/tools/javac/lambda/TargetType01.java
- test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType43.out
+ test/tools/javac/lambda/TargetType66.java
+ test/tools/javac/lambda/TargetType66.out

Changeset: c635a966ce84
Author:    mcimadamore
Date:      2013-04-08 15:59 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c635a966ce84

8010822: Intersection type cast for functional expressions does not follow spec EDR
Summary: Remove support for marker interfaces; redefine intersection type casts to be order-independent
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/diags/examples/NotAnInterfaceComponent.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
! test/tools/javac/lambda/Intersection01.java
- test/tools/javac/lambda/Intersection01.out
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java

Changeset: b402b93cbe38
Author:    jjg
Date:      2013-04-08 11:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b402b93cbe38

8011676: Instances of Tokens.Comment should not be defined in inner classes
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java

Changeset: 3f3cc8d3f13c
Author:    jjg
Date:      2013-04-08 11:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3f3cc8d3f13c

8011677: EndPosTables should avoid hidden references to Parser
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java

Changeset: 1f19b84efa6d
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1f19b84efa6d

Merge

- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
- test/tools/javac/lambda/Intersection01.out
- test/tools/javac/lambda/TargetType01.out

Changeset: 2b585be0da7a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2b585be0da7a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java
! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java

Changeset: 717bcda533f2
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/717bcda533f2

Merge


Changeset: 6ab578e141df
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6ab578e141df

Merge


Changeset: 4f4509c2fe35
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4f4509c2fe35

Added tag jdk8-b86 for changeset 6ab578e141df

! .hgtags



From john.coomes at oracle.com  Fri Apr 19 04:55:51 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:55:51 +0000
Subject: hg: hsx/hotspot-gc/nashorn: 33 new changesets
Message-ID: <20130419045615.34C4948460@hg.openjdk.java.net>

Changeset: 41a212ea8c0c
Author:    sundar
Date:      2013-03-28 20:48 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/41a212ea8c0c

8010924: Dealing with undefined property gets you a fatal stack
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8010924.js

Changeset: e2ea7a29b9c1
Author:    lagergren
Date:      2013-03-29 08:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e2ea7a29b9c1

8010995: The bug ID 8010710 accidentally got two digits transposed in the checkin and unit test name
Reviewed-by: hannesw, sundar

+ test/script/basic/JDK-8010710.js
+ test/script/basic/JDK-8010710.js.EXPECTED
- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

Changeset: 704f3083af8a
Author:    sundar
Date:      2013-03-29 18:38 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/704f3083af8a

8011063: With older ant, we get the error "The <property> type doesn't support nested text data ("${run.te...jvmargs}")."
Reviewed-by: hannesw, ksrini

! make/build.xml

Changeset: a094fc010120
Author:    jlaskey
Date:      2013-03-31 08:19 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a094fc010120

8011095: PropertyHashMap.rehash() does not grow enough
Reviewed-by: hannesw, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/PropertyHashMap.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 3e4369fb810b
Author:    hannesw
Date:      2013-04-02 13:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/3e4369fb810b

8011219: Regression with recent PropertyMap history changes
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 5362d96d5915
Author:    sundar
Date:      2013-04-02 17:40 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5362d96d5915

8011209: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.length is not 0
Reviewed-by: lagergren, hannesw, jlaskey

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011209.js

Changeset: 9b845033c888
Author:    lana
Date:      2013-04-02 12:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9b845033c888

Merge


Changeset: d82bc6ba3981
Author:    lana
Date:      2013-04-05 14:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d82bc6ba3981

Merge


Changeset: af6fc67aa73d
Author:    jlaskey
Date:      2013-04-02 11:37 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/af6fc67aa73d

8011233: Create a Nashorn shell for JavaFX
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! make/build.xml
! make/project.properties
+ tools/fxshell/jdk/nashorn/tools/FXShell.java

Changeset: be5d2e472e22
Author:    jlaskey
Date:      2013-04-02 11:38 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/be5d2e472e22

Merge


Changeset: 159dbe2e02eb
Author:    sundar
Date:      2013-04-02 20:42 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/159dbe2e02eb

8011237: Object.isExtensible(Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get) should be false
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011237.js

Changeset: e9af5451d2d1
Author:    sundar
Date:      2013-04-02 23:01 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e9af5451d2d1

8011274: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.hasOwnProperty("prototype") should be false
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
+ test/script/basic/JDK-8011274.js

Changeset: e63b20d4f08a
Author:    sundar
Date:      2013-04-03 11:41 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e63b20d4f08a

8011357: Array.prototype.slice and Array.prototype.splice should not call user defined valueOf of start, end arguments more than once
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011357.js

Changeset: 51da1afbab26
Author:    attila
Date:      2013-04-03 11:13 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/51da1afbab26

8011362: Overloaded method resolution foiled by nulls
Reviewed-by: hannesw, sundar

! src/jdk/internal/dynalink/beans/ClassString.java
! src/jdk/internal/dynalink/beans/OverloadedMethod.java
+ test/script/basic/JDK-8011362.js
+ test/script/basic/JDK-8011362.js.EXPECTED
+ test/src/jdk/nashorn/test/models/Jdk8011362TestSubject.java

Changeset: b4191da366be
Author:    sundar
Date:      2013-04-03 15:27 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b4191da366be

8011365: Array.prototype.join and Array.prototype.toString do not throw TypeError on null, undefined
Reviewed-by: attila, hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
! test/script/basic/JDK-8011362.js.EXPECTED
+ test/script/basic/JDK-8011365.js

Changeset: 4f7d7576e8c4
Author:    hannesw
Date:      2013-04-03 12:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4f7d7576e8c4

8007774: Enable code cache again
Reviewed-by: lagergren, attila, sundar

! src/jdk/nashorn/internal/runtime/resources/Options.properties

Changeset: 82fed56d8dce
Author:    sundar
Date:      2013-04-03 20:17 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/82fed56d8dce

8011382: Data prototype methods and constructor do not call user defined toISOString, valueOf methods per spec.
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeDate.java
+ test/script/basic/JDK-8011382.js

Changeset: a5a8ddc2e028
Author:    sundar
Date:      2013-04-04 10:24 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a5a8ddc2e028

8011394: RegExp.prototype.test() does not call valueOf on lastIndex property as per the spec.
Reviewed-by: lagergren, jlaskey, hannesw

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8011394.js

Changeset: 0548c134b9ac
Author:    sundar
Date:      2013-04-04 13:54 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/0548c134b9ac

8011421: When using Object.defineProperty on arrays, PropertyDescriptor's property accessors are invoked multiple times
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011421.js

Changeset: f638f2f094f7
Author:    jlaskey
Date:      2013-04-04 09:05 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f638f2f094f7

8011540: PropertyMap histories should not begin with empty map
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 069923cc9de5
Author:    jlaskey
Date:      2013-04-04 09:06 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/069923cc9de5

Merge


Changeset: 18df6640e63f
Author:    sundar
Date:      2013-04-04 18:30 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/18df6640e63f

8011543: "".split(undefined,{valueOf:function(){throw 2}}) does not throw exception
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeString.java
+ test/script/basic/JDK-8011543.js

Changeset: 5eb1427b6a6d
Author:    attila
Date:      2013-04-04 15:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5eb1427b6a6d

8011544: Allow subclassing Java classes from script without creating instances
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/objects/NativeJava.java
+ src/jdk/nashorn/internal/runtime/linker/AdaptationException.java
+ src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java
+ src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/basic/javaclassoverrides.js
+ test/script/basic/javaclassoverrides.js.EXPECTED

Changeset: 73e1270b240c
Author:    attila
Date:      2013-04-04 15:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/73e1270b240c

Merge


Changeset: 349360cc1df5
Author:    sundar
Date:      2013-04-04 20:46 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/349360cc1df5

8011552: Arrays with missing elements are not properly sorted
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011552.js

Changeset: 050fd5696bcb
Author:    attila
Date:      2013-04-04 18:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/050fd5696bcb

8011555: Invalid class name in with block with JavaImporter causes MH type mismatch
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/WithObject.java
+ test/script/basic/JDK-8011555.js
+ test/script/basic/JDK-8011555.js.EXPECTED

Changeset: 1c29dc809de2
Author:    hannesw
Date:      2013-04-05 19:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1c29dc809de2

8009230: Nashorn rejects extended RegExp syntax accepted by all major JS engines
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8009230.js
+ test/script/basic/JDK-8009230.js.EXPECTED

Changeset: 437861485ffa
Author:    jlaskey
Date:      2013-04-09 08:36 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/437861485ffa

Merge


Changeset: 35881a9d0fc2
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/35881a9d0fc2

Merge

- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

Changeset: e7e82c1e9aed
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e7e82c1e9aed

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! docs/JavaScriptingProgrammersGuide.html
! src/jdk/nashorn/api/scripting/Formatter.java

Changeset: 399a4b8e4607
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/399a4b8e4607

Merge


Changeset: 002ad9d6735f
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/002ad9d6735f

Merge


Changeset: 899cbeee7253
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/899cbeee7253

Added tag jdk8-b86 for changeset 002ad9d6735f

! .hgtags



From jon.masamitsu at oracle.com  Fri Apr 19 05:03:30 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 18 Apr 2013 22:03:30 -0700
Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter
	functions cause large young GC regressions
In-Reply-To: <516892E5.9030105@oracle.com>
References: <515271FB.9090203@oracle.com> <51562FB7.9010609@oracle.com>
	<516892E5.9030105@oracle.com>
Message-ID: <5170D022.5060102@oracle.com>

This is the webrev for the complete set of  changes
(updated to the latest gc_baseline).

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

Thanks.

Jon

On 4/12/2013 4:04 PM, Jon Masamitsu wrote:
> This is the promised semantic changes for the code review.  Whereas
> the original set of changes only maintained a running sum for the
> capacity of all the space for metadata, this added a running sum
> for the used space allocated and holding metadata.
>
> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00_2/
>
> This is an incremental webrev based on the name change webrev
> (webrev.00_1) below.  A complete webrev with all changes will
> be published after comments for this have been digested.
>
> Thanks.
>
> Jon
>
> On 3/29/2013 5:20 PM, Jon Masamitsu wrote:
>> Ths webrev has mostly name changes suggested by the code
>> review comments.  There are additional changes coming that
>> relate to semantic changes suggested by the code review.
>>
>> This was created by deleting some of the suggested semantic
>> changes so will not compile.  The next webrev will be relative
>> to this one so you won't have to look at the name changes when
>> looking and the semantic changes.
>>
>> Ignore the block comment about chunk accounting at the
>> beginning of metaspace.cpp.  That will be updated or deleted
>> in the next webrev.
>>
>> The deletion of some dead code is included in this webrev
>> (limited number of lines).
>>
>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00_1/
>>
>> Thanks.
>>
>> Jon
>>
>> On 3/26/2013 9:13 PM, Jon Masamitsu wrote:
>>>
>>> Replace the use of a method that calculated the total capacity of
>>> the Metaspaces by iterating over all the Metaspaces by maintaining
>>> the sum of Metaspace capacities as the Metachunks are
>>> allocated to each Metaspace.  Also maintain a sum for each
>>> Metaspace as the Metachunks are allocated to that Metaspace.
>>>
>>> Change should_expand() and compute_new_space() to
>>> calculate quantities in bytes.
>>>
>>> Remove calls to methods that calculated totals for
>>> "used" and "free" by iterating over the Metaspaces
>>> in product mode.  In some cases substitute the use
>>> of capacity for used.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/
>>>
>>> Thanks.
>>>
>>> Jon
>>
>



From yumin.qi at oracle.com  Fri Apr 19 05:21:28 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 18 Apr 2013 22:21:28 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5170A77A.6080006@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F5FD5.8020406@oracle.com>
	<516FA67B.20308@oracle.com> <5170A77A.6080006@oracle.com>
Message-ID: <5170D458.5090102@oracle.com>


On 4/18/2013 7:10 PM, David Holmes wrote:
> On 18/04/2013 5:53 PM, Yumin Qi wrote:
>> Thanks Coleen and David, I update the webrev (same URL) for
>> HandleMark(handles.hpp) and also several files' Copyright year.
>
> Thanks for that.
>
> One thing that just occurred to me is that NEW_C_HEAP_OBJ can only be 
> used for classes that have no virtual methods - as there is nothing to 
> initialize the vtable pointer. I think we got lucky with HandleMark in 
> that regard, but there should be a warning attached to it as well.
>
Thanks! I tried, it will segment fault!

+// allocate type in heap without calling ctor
+// WARNING: type must not have virtual functions!!! There is no way to 
initialize vtable.
  #define NEW_C_HEAP_OBJ(type, memflags)\
    NEW_C_HEAP_ARRAY(type, 1, memflags)

Same link update.

Thanks
Yumin
> Thanks,
> David
>
>> Thanks
>> Yumin
>>
>> On 4/17/2013 7:52 PM, David Holmes wrote:
>>> Hi Yumin,
>>>
>>> Only thing missing - as discussed - is that HandleMark should now
>>> extend StackObj, with a comment about the special CHeap HandleMark in
>>> thread.
>>>
>>> Thanks for your perseverance on this.
>>>
>>> David
>>>
>>> On 18/04/2013 3:54 AM, Yumin Qi wrote:
>>>> Hi,  This version Change back the HandleMark creating in Thread 
>>>> creation
>>>> back to previous version and add more comments to allocation.hpp for
>>>> documenting the usage of newly introduced macros.
>>>>
>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>>>> Hi, all
>>>>>
>>>>>   new webrev at
>>>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>>
>>>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>>>                     quickSort.cpp, remove conditional includes.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>>>> Adding back compiler and gc teams
>>>>>>>>
>>>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>>>> Zhenyu,
>>>>>>>>>
>>>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>>>
>>>>>>>>> i can just do
>>>>>>>>>
>>>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>>>
>>>>>>>>> so the destructor will be called, is this right?
>>>>>>>>
>>>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>>>> delete (which is what I think Zhengyu was referring to) that 
>>>>>>>> doesn't
>>>>>>>> actually deallocate the memory.
>>>>>>>>
>>>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>>>
>>>>>> But you can only call that explicitly as a function. The delete
>>>>>> expression will never use it, so I don't see how it applies. We need
>>>>>> to call the destructor without de-allocating and the only way I can
>>>>>> see to do that is to call the destructor explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>>>> should simply have a custom operator new[] and operator 
>>>>>>>> delete[] and
>>>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is 
>>>>>>>> simple
>>>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY 
>>>>>>>> that
>>>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>>>> destructs and then de-allocates.
>>>>>>>>
>>>>>>>> I have no issue with calling destructors explicitly.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>>>> memflags)                  \
>>>>>>>>>>>   624 { \
>>>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>>>> { \
>>>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>>>> {                                 \
>>>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>>>> */                                        \
>>>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>>>   629 } \
>>>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>>>> memflags);                                \
>>>>>>>>>>>   631 } \
>>>>>>>>>>>   632   }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>>>> new webrev at:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>>>
>>>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit 
>>>>>>>>>>>>> of a
>>>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to
>>>>>>>>>>>>> leak
>>>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>>>> to it!
>>>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>>>> element
>>>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the
>>>>>>>>>>>>> dtor's
>>>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why does only Solaris need the allocation headers included 
>>>>>>>>>>>>> ?? I
>>>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is default constructor does, here just copy that 
>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>>>> should not call new, but I think we can use 
>>>>>>>>>>>>>>>> NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator
>>>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global 
>>>>>>>>>>>>>>>>>> operator
>>>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we
>>>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from
>>>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values 
>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they
>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>



From kevin.walls at oracle.com  Fri Apr 19 05:33:43 2013
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Fri, 19 Apr 2013 05:33:43 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets
Message-ID: <20130419053350.4C64A4846A@hg.openjdk.java.net>

Changeset: bfe3be9ebd6c
Author:    kevinw
Date:      2013-04-18 17:02 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bfe3be9ebd6c

7109087: gc/7072527/TestFullGCCount.java fails when GC is set in command-line
Reviewed-by: mgerdin

! test/gc/7072527/TestFullGCCount.java

Changeset: 12927badda81
Author:    kevinw
Date:      2013-04-19 05:14 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/12927badda81

Merge




From david.holmes at oracle.com  Fri Apr 19 05:46:59 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 15:46:59 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5170D458.5090102@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F5FD5.8020406@oracle.com>
	<516FA67B.20308@oracle.com> <5170A77A.6080006@oracle.com>
	<5170D458.5090102@oracle.com>
Message-ID: <5170DA53.8090505@oracle.com>

Ship it! :)

TGIF I need a break :)

Thanks,
David

On 19/04/2013 3:21 PM, Yumin Qi wrote:
>
> On 4/18/2013 7:10 PM, David Holmes wrote:
>> On 18/04/2013 5:53 PM, Yumin Qi wrote:
>>> Thanks Coleen and David, I update the webrev (same URL) for
>>> HandleMark(handles.hpp) and also several files' Copyright year.
>>
>> Thanks for that.
>>
>> One thing that just occurred to me is that NEW_C_HEAP_OBJ can only be
>> used for classes that have no virtual methods - as there is nothing to
>> initialize the vtable pointer. I think we got lucky with HandleMark in
>> that regard, but there should be a warning attached to it as well.
>>
> Thanks! I tried, it will segment fault!
>
> +// allocate type in heap without calling ctor
> +// WARNING: type must not have virtual functions!!! There is no way to
> initialize vtable.
>   #define NEW_C_HEAP_OBJ(type, memflags)\
>     NEW_C_HEAP_ARRAY(type, 1, memflags)
>
> Same link update.
>
> Thanks
> Yumin
>> Thanks,
>> David
>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/17/2013 7:52 PM, David Holmes wrote:
>>>> Hi Yumin,
>>>>
>>>> Only thing missing - as discussed - is that HandleMark should now
>>>> extend StackObj, with a comment about the special CHeap HandleMark in
>>>> thread.
>>>>
>>>> Thanks for your perseverance on this.
>>>>
>>>> David
>>>>
>>>> On 18/04/2013 3:54 AM, Yumin Qi wrote:
>>>>> Hi,  This version Change back the HandleMark creating in Thread
>>>>> creation
>>>>> back to previous version and add more comments to allocation.hpp for
>>>>> documenting the usage of newly introduced macros.
>>>>>
>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>>>>> Hi, all
>>>>>>
>>>>>>   new webrev at
>>>>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>>>
>>>>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>>>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>>>>                     quickSort.cpp, remove conditional includes.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>>>>> Adding back compiler and gc teams
>>>>>>>>>
>>>>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>>>>> Zhenyu,
>>>>>>>>>>
>>>>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>>>>
>>>>>>>>>> i can just do
>>>>>>>>>>
>>>>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>>>>
>>>>>>>>>> so the destructor will be called, is this right?
>>>>>>>>>
>>>>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>>>>> delete (which is what I think Zhengyu was referring to) that
>>>>>>>>> doesn't
>>>>>>>>> actually deallocate the memory.
>>>>>>>>>
>>>>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>>>>
>>>>>>> But you can only call that explicitly as a function. The delete
>>>>>>> expression will never use it, so I don't see how it applies. We need
>>>>>>> to call the destructor without de-allocating and the only way I can
>>>>>>> see to do that is to call the destructor explicitly.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>>>>> should simply have a custom operator new[] and operator
>>>>>>>>> delete[] and
>>>>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is
>>>>>>>>> simple
>>>>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY
>>>>>>>>> that
>>>>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>>>>> destructs and then de-allocates.
>>>>>>>>>
>>>>>>>>> I have no issue with calling destructors explicitly.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>>>>> memflags)                  \
>>>>>>>>>>>>   624 { \
>>>>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>>>>> { \
>>>>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>>>>> {                                 \
>>>>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>>>>> */                                        \
>>>>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>>>>   629 } \
>>>>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>>>>> memflags);                                \
>>>>>>>>>>>>   631 } \
>>>>>>>>>>>>   632   }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>>>>> new webrev at:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev1>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit
>>>>>>>>>>>>>> of a
>>>>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to
>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>>>>> to it!
>>>>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>>>>> element
>>>>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the
>>>>>>>>>>>>>> dtor's
>>>>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why does only Solaris need the allocation headers included
>>>>>>>>>>>>>> ?? I
>>>>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is default constructor does, here just copy that
>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>>>>> should not call new, but I think we can use
>>>>>>>>>>>>>>>>> NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is
>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>>>>> <http://cr.openjdk.java.net/%7Eminqi/8010992/webrev/>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator
>>>>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global
>>>>>>>>>>>>>>>>>>> operator
>>>>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we
>>>>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from
>>>>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they
>>>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>


From bengt.rutisson at oracle.com  Fri Apr 19 06:53:04 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 19 Apr 2013 08:53:04 +0200
Subject: Request for review: 8010518 Move deprecating CMSIncrementalMode
	from Arguments::check_deprecated_gcs() to
	Arguments::check_deprecated_gc_flags()
In-Reply-To: <51708595.9010708@oracle.com>
References: <514B966E.4060706@oracle.com> <514CC577.209@oracle.com>
	<514D26D2.1030705@oracle.com> <514F5F16.9080909@oracle.com>
	<51509C17.6080808@oracle.com> <51512A97.2030600@oracle.com>
	<51537686.1030601@oracle.com> <5153E3D1.2040002@oracle.com>
	<515482F1.5070002@oracle.com> <5154873F.60002@oracle.com>
	<51708595.9010708@oracle.com>
Message-ID: <5170E9D0.8040502@oracle.com>


Hi Tao,

On 4/19/13 1:45 AM, Tao Mao wrote:
> Hi all,
>
> After reading JEP documentation, I don't feel like moving 
> CMSIncrementalMode to check_deprecated_gc_flags() because it's 
> essentially Incremental CMS collector. It's more expected to live in 
> check_deprecated_gcs() (at least to me). What are your opinions? If no 
> one opposes, I will close this CR.

I'm fine with this.

Bengt

>
> Thanks.
> Tao
>
> On 3/28/13 11:09 AM, Bengt Rutisson wrote:
>> On 3/28/13 6:50 PM, Tao Mao wrote:
>>> Hi Bengt,
>>>
>>> On 3/27/2013 11:31 PM, Bengt Rutisson wrote:
>>>>
>>>> Hi Tao,
>>>>
>>>> On 3/27/13 11:45 PM, Tao Mao wrote:
>>>>> Please see inline.
>>>>> Tao
>>>>>
>>>>> On 3/25/13 9:56 PM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Tao,
>>>>>>
>>>>>> Thanks for updating the tests. Looks good to me.
>>>>>>
>>>>>> Have you tried running the tests? It is a very small change so it 
>>>>>> should be ok. But our testing process is very strange and it may 
>>>>>> be that these tests are not run until PIT testing, so running 
>>>>>> them once before pushing is a good idea to avoid unnecessary 
>>>>>> issues later on.
>>>>> They have passed the jtreg tests. I'm going to push it.
>>>>>
>>>>> script:
>>>>> jtreg -jdk:/Users/tamao/home/jdk1.8.0_b74_macosx/ \
>>>>> -vmoption:-tamao \
>>>>> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestCMSIncrementalMode.java 
>>>>> \
>>>>> ./src/8010518MoveDeprecatingCMSIncrementalMode/test/gc/startup_warnings/TestIncGC.java
>>>>>
>>>>> results:
>>>>> Test results: passed: 2
>>>>> Report written to 
>>>>> /Users/tamao/Dropbox/Oracle/JTreport/html/report.html
>>>>> Results written to /Users/tamao/Dropbox/Oracle/JTwork
>>>>
>>>> Great! Thanks!
>>>>
>>>>>>
>>>>>> Also, I see that you decided not to remove "likely" from the 
>>>>>> other messages in Arguments::check_deprecated_gcs(). Would you 
>>>>>> like to do that as a separate change or do you think we should 
>>>>>> leave those messages unchanged?
>>>>> So what was the decision for deprecating these gc's? To me, there 
>>>>> hasn't seemed to be any definitive decision, yet.
>>>>
>>>> It is the same decision as for CMSIncrementalMode, where you 
>>>> removed the "likely".
>>>>
>>>> Bengt
>>> Where is the latest update regarding this issue? Any mail thread, or 
>>> web?
>>
>> I think the JEP is pretty clear about it:
>>
>> http://openjdk.java.net/jeps/173
>>
>> " The DefNew + CMS and ParNew + SerialOld combinations and the 
>> Incremental Mode of CMS will be deprecated (logging a warning 
>> message). This is to be interpreted as that these GC combinations 
>> will be removed in some upcoming major release."
>>
>> Bengt
>>>
>>> Thank you.
>>> Tao
>>>
>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>> On 3/25/13 7:48 PM, Tao Mao wrote:
>>>>>>> Thank you for pointing it out, Bengt. A new webrev is updated.
>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.02/
>>>>>>>
>>>>>>> Please see inline.
>>>>>>> Tao
>>>>>>>
>>>>>>> On 3/24/13 1:16 PM, Bengt Rutisson wrote:
>>>>>>>>
>>>>>>>> Hi Tao,
>>>>>>>>
>>>>>>>> On 3/23/13 4:51 AM, Tao Mao wrote:
>>>>>>>>> Thank you for review and suggestion. A new webrev is updated.
>>>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.01/
>>>>>>>>
>>>>>>>> I like Jon's suggestion about removing the word "likely" but 
>>>>>>>> that means that you need to update these tests:
>>>>>>>>
>>>>>>>> test/gc/startup_warnings/TestCMSIncrementalMode.java
>>>>>>>> test/gc/startup_warnings/TestIncGC.java
>>>>>>> Test files modified.
>>>>>>>>
>>>>>>>> Also, would it make sense to remove the word "likely" from the 
>>>>>>>> warning messages in Arguments::check_deprecated_gcs() too? In 
>>>>>>>> that case you need to update these tests as well:
>>>>>>>>
>>>>>>>> test/gc/startup_warnings/TestDefNewCMS.java
>>>>>>>> test/gc/startup_warnings/TestParNewSerialOld.java
>>>>>>> Have we made a decision to certainly remove these gc comb's in 
>>>>>>> future? If so, it's OK to state so. Anyway, it would be better 
>>>>>>> to resolve it with a separate CR.
>>>>>>>>
>>>>>>>> Bengt
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tao
>>>>>>>>>
>>>>>>>>> On 3/22/13 1:56 PM, Jon Masamitsu wrote:
>>>>>>>>>> Tao,
>>>>>>>>>>
>>>>>>>>>> Changes look fine.  I would remove the "likely" so that 
>>>>>>>>>> messages read like
>>>>>>>>>>
>>>>>>>>>> "and will be removed in a future release"
>>>>>>>>>>
>>>>>>>>>> Fewer words are better and the intent is still clear.
>>>>>>>>>>
>>>>>>>>>> Jon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/21/2013 4:23 PM, Tao Mao wrote:
>>>>>>>>>>> A simple changeset. Need a reviewer!
>>>>>>>>>>>
>>>>>>>>>>> 8010518 Move deprecating CMSIncrementalMode from 
>>>>>>>>>>> Arguments::check_deprecated_gcs() to 
>>>>>>>>>>> Arguments::check_deprecated_gc_flags()
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010518
>>>>>>>>>>>
>>>>>>>>>>> webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~tamao/8010518/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> changeset:
>>>>>>>>>>> Cleanup suggested by Bengt.
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>

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

From sirinath at sakrio.com  Fri Apr 19 08:06:22 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Fri, 19 Apr 2013 13:36:22 +0530
Subject: javax GC API
Message-ID: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>

Hi,

Any thoughts plans to add API accessibility to the GC subsystems and the
ability to add our own GC.

Looking for the comments from the community and Oracle.

In addition I like to propose introducing the following annotations for
more predictable GC overheads:

   - GCAtBlockEnd
   - GCAtBlockExit - for loops the GC happens when the
   - GCAtLastReference
   - GCAtEndOfScope
   - GCOnAssignment
   - GCOnReturn
   - GCOnGCOfContainingObject - GC on GC of aggregate / composing object
   - GCOnStatementCompletion - GC parameters and return value (if not
   assigned) of a call when the function returns. Need to support statement
   level annotations.
   - GCOnLastResort - Only GC at last resort before outofmemory exception -
   class level
   - ExcludeFinalising - prevent finalizers running on the object - class
   level
   - GCUsingCurrentThread
   - GCUsingDefaultThread
   - GCUsingNewThread(Priority = n)

To do this annotations need to be extended to local variables and for some
application at the statement / block level.

At each point the objects pointed by the handle are GCed if there is
a possibility (reference count becomes 0). If a reference to an object is
specified to be

Suminda
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130419/4ed25cca/attachment.htm>

From sirinath at sakrio.com  Fri Apr 19 08:39:21 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Fri, 19 Apr 2013 14:09:21 +0530
Subject: javax GC API
In-Reply-To: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
Message-ID: <CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>

Another potential annotations is:

   - GCUsing(GCSystem) - all objects created in the specified scope will be
   GCed using specified GC - annotations need to support static references

I like to know if there are others thinking in  the same line.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130419/29708921/attachment.htm>

From sirinath at sakrio.com  Fri Apr 19 09:10:40 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Fri, 19 Apr 2013 14:40:40 +0530
Subject: javax GC API
In-Reply-To: <CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
Message-ID: <CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>

Another potential tag to ensure GC does not happen during the execution of
a code block:

   - GCSuspend - a synchronous object can be used so that the GC threads do
   not run while the code block is executing

Of course some revision to current annotations will be needed
to accommodate this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130419/6cda7abb/attachment.htm>

From sirinath at sakrio.com  Fri Apr 19 09:43:29 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Fri, 19 Apr 2013 15:13:29 +0530
Subject: javax GC API
In-Reply-To: <CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
	<CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
Message-ID: <CAAfFNYFQU-EmUy68WzGcmhYohYLdQD2foumBFuC+MbtS-xCuxQ@mail.gmail.com>

Also an annotation to GC immediately when reference count reaches 0:

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

From kirk at kodewerk.com  Fri Apr 19 09:50:11 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 19 Apr 2013 11:50:11 +0200
Subject: javax GC API
In-Reply-To: <CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
	<CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
Message-ID: <31A020B9-F7F2-4DC4-9EE8-E8ABF1D25A69@kodewerk.com>

Hi Suminda,

With all due respect, I'm not sure that it's a great idea to pass control of the garbage collectors over to the programmer. In this case, if you were to ensure that GC did not happen during the execution of a block you are in danger of filling heap. A better way to prevent GC is to not create objects.

Regards,
Kirk
On 2013-04-19, at 11:10 AM, Suminda Dharmasena <sirinath at sakrio.com> wrote:

> Another potential tag to ensure GC does not happen during the execution of a code block:
> GCSuspend - a synchronous object can be used so that the GC threads do not run while the code block is executing
> Of course some revision to current annotations will be needed to accommodate this.

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

From sirinath at sakrio.com  Fri Apr 19 09:59:32 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Fri, 19 Apr 2013 15:29:32 +0530
Subject: javax GC API
In-Reply-To: <31A020B9-F7F2-4DC4-9EE8-E8ABF1D25A69@kodewerk.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
	<CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
	<31A020B9-F7F2-4DC4-9EE8-E8ABF1D25A69@kodewerk.com>
Message-ID: <CAAfFNYFXh7CdRqAq_UYyJpZG+yXBPeitF-UO7u8QFNCsBVTzdQ@mail.gmail.com>

Hi,

Not creating an object will not help. Objects created before can be GCed.
The block will suspend GC block until the block exists or until just before
OutOfMemory exception is raised.

Also this can allow API based GC and processing of GC related annotations.

There are times where you cannot afford to have a sizable GC pause.

S
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--


On 19 April 2013 15:20, Kirk Pepperdine <kirk at kodewerk.com> wrote:

> Hi Suminda,
>
> With all due respect, I'm not sure that it's a great idea to pass control
> of the garbage collectors over to the programmer. In this case, if you were
> to ensure that GC did not happen during the execution of a block you are in
> danger of filling heap. A better way to prevent GC is to not create objects.
>
> Regards,
> Kirk
>
> On 2013-04-19, at 11:10 AM, Suminda Dharmasena <sirinath at sakrio.com>
> wrote:
>
> Another potential tag to ensure GC does not happen during the execution of
> a code block:
>
>    - GCSuspend - a synchronous object can be used so that the GC threads
>    do not run while the code block is executing
>
> Of course some revision to current annotations will be needed
> to accommodate this.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130419/a26258ab/attachment.htm>

From sirinath at sakrio.com  Fri Apr 19 10:04:50 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Fri, 19 Apr 2013 15:34:50 +0530
Subject: javax GC API
In-Reply-To: <CAAfFNYFXh7CdRqAq_UYyJpZG+yXBPeitF-UO7u8QFNCsBVTzdQ@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
	<CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
	<31A020B9-F7F2-4DC4-9EE8-E8ABF1D25A69@kodewerk.com>
	<CAAfFNYFXh7CdRqAq_UYyJpZG+yXBPeitF-UO7u8QFNCsBVTzdQ@mail.gmail.com>
Message-ID: <CAAfFNYGBA3JdFk2CMSiE4ruB7jFSwUHQOMquBMRDf2F=GtumFA@mail.gmail.com>

Also if the programmer fails to wisely GC using API / Annotations then
the fallback is the default GC mechanism. This way there will be no memory
leaks. Also objects which are GCed will be objects that can be GCed. Live /
referenced objects which escape the explicit GC context will not be GCed.

The objective is that:

   - The GC check happens at define points in code
   - GC happens at define points if possible, else fall back to the system
   GC mechanism
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130419/1d87061a/attachment.htm>

From stefan.karlsson at oracle.com  Fri Apr 19 11:46:20 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 19 Apr 2013 13:46:20 +0200
Subject: Review request: 8012687: Remove unused is_root checks and closures
Message-ID: <51712E8C.90506@oracle.com>

http://cr.openjdk.java.net/~stefank/8012687/webrev.00/

 From bug description:
There's an unused parameter named is_root that is passed down to a 
number of MarkSweep/ParOld closures. This enhancement suggests that we 
remove it and cleanup the trails after it.

thanks,
StefanK


From thomas.schatzl at oracle.com  Fri Apr 19 12:24:03 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 19 Apr 2013 14:24:03 +0200
Subject: Review request: 8012687: Remove unused is_root checks and closures
In-Reply-To: <51712E8C.90506@oracle.com>
References: <51712E8C.90506@oracle.com>
Message-ID: <1366374243.3702.2.camel@cirrus>

Hi,

On Fri, 2013-04-19 at 13:46 +0200, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8012687/webrev.00/
> 
>  From bug description:
> There's an unused parameter named is_root that is passed down to a 
> number of MarkSweep/ParOld closures. This enhancement suggests that we 
> remove it and cleanup the trails after it.

  looks fine.

Thomas



From thomas.schatzl at oracle.com  Fri Apr 19 12:28:09 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 19 Apr 2013 14:28:09 +0200
Subject: RFR (S): 7057939 : jmap shows MaxNewSize=4GB when Java is using
	parallel collector
In-Reply-To: <2c47440e-e423-48ed-9c76-b9530a895764@default>
References: <2c47440e-e423-48ed-9c76-b9530a895764@default>
Message-ID: <1366374489.3702.5.camel@cirrus>

Hi all,

On Wed, 2013-04-17 at 10:53 -0700, Thomas Schatzl wrote:
> Hi all,
> 
>   could I have some reviews for the change for CR 7057939?

This fix does not update the MaxNewSize global at the correct position
for parallel GC.

I found out while looking at CR 8012591 which is about fixing the same
issues for other globals shown by jmap.

So I'd like to retract this review request until I found a better
solution.

Sorry for the inconvenience.

Thomas




From jon.masamitsu at oracle.com  Fri Apr 19 17:02:57 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 19 Apr 2013 10:02:57 -0700
Subject: javax GC API
In-Reply-To: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
Message-ID: <517178C1.4010306@oracle.com>


On 4/19/2013 1:06 AM, Suminda Dharmasena wrote:
> Hi,
>
> Any thoughts plans to add API accessibility to the GC subsystems and the
> ability to add our own GC.

I don't recall being in any meeting where this was discussed.  Do
you mean providing control to the applications to start some phase
of GC?  Could you give an example?

>
> Looking for the comments from the community and Oracle.
>
> In addition I like to propose introducing the following annotations for
> more predictable GC overheads:
>
>     - GCAtBlockEnd

What does this mean to you?

Jon

>     - GCAtBlockExit - for loops the GC happens when the
>     - GCAtLastReference
>     - GCAtEndOfScope
>     - GCOnAssignment
>     - GCOnReturn
>     - GCOnGCOfContainingObject - GC on GC of aggregate / composing object
>     - GCOnStatementCompletion - GC parameters and return value (if not
>     assigned) of a call when the function returns. Need to support statement
>     level annotations.
>     - GCOnLastResort - Only GC at last resort before outofmemory exception -
>     class level
>     - ExcludeFinalising - prevent finalizers running on the object - class
>     level
>     - GCUsingCurrentThread
>     - GCUsingDefaultThread
>     - GCUsingNewThread(Priority = n)
>
> To do this annotations need to be extended to local variables and for some
> application at the statement / block level.
>
> At each point the objects pointed by the handle are GCed if there is
> a possibility (reference count becomes 0). If a reference to an object is
> specified to be
>
> Suminda
> --
> Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
> P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
> Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
> 864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?
>
> This email is subjected to the email Terms of Use and Disclaimer:
> http://www.sakrio.com/email-legal. Please read this first.
> --
>



From tao.mao at oracle.com  Fri Apr 19 17:27:10 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Fri, 19 Apr 2013 10:27:10 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <516BBC64.6060509@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com>
Message-ID: <51717E6E.4020806@oracle.com>

1. check overflow routine is wrapped up.

2. The reduction of code duplication is adopted.

3. Develop a way to intake 0~multiple external vm options in jtreg 
main(). Hope it helps others implement similar functionality.

webrev:
http://cr.openjdk.java.net/~tamao/6761744/webrev.02/

test:
JTREG: passed.
jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao <GC_OPTION>" 
/home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java

where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
-XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC


Thanks.
Tao

On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>
> Hi Tao,
>
> I agree with John. The changes look fine and I'm ok with them. But it 
> would look nicer to add the 
> CollectedHeap::add_and_verify_no_overflow() method.
>
> Also, regarding the test, a couple of minor things.
>
> First, with the new naming convention I think the test should be 
> called something like:
>
> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>
> Then I think you can reduce the code duplication a bit. You create the 
> same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit cases. So 
> maybe it could look like this instead:
>
> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>   public static void main(String args[]) throws Exception {
>     ProcessBuilder pb =
>       
> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>                                               "-Xmx3072m",
>                                               "-XX:MaxPermSize=1024m",
>                                               "-version");
>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>
>     String dataModel = System.getProperty("sun.arch.data.model");
>     if (dataModel.equals("32")) {
>       output.shouldContain("The size of the object heap + perm gen 
> exceeds the maximum representable size");
>       if (output.getExitValue() == 0) {
>         throw new RuntimeException("Not expected to get exit value 0");
>       }
>     } else if (dataModel.equals("64")) {
>       output.shouldHaveExitValue(0);
>     }
>   }
> }
>
> There is also a small bug in the test. If you run JTreg without 
> passing any vmoptions the test will fail. The reason is that 
> System.getProperty("test.vm.opts") will evaluate to the empty string. 
> This will be passed as the first argument to the Java process, which 
> will assume that this is the class name. So, it fails to start because 
> it can't load the class <empty string>.
>
> To reproduce the problem use this command line:
>
> java  -jar <path_to_jtreg>/lib/jtreg.jar 
> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>
> I guess the fix is to check that System.getProperty("test.vm.opts") is 
> not empty before passing it on to createJavaProcessBuilder().
>
> Thanks,
> Bengt
>
> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>> Hi Tao,
>>
>> This looks OK to me.
>>
>> I can see what Thomas is saying though. All of the checks involve 
>> something like:
>>
>> total += some_value;
>> if (total < some_value) {
>>   // We must have overflowed
>>   vm_exit(...);
>> }
>>
>> So a function in CollectedHeap (the base class of SharedHeap and 
>> ParallelScavengeHeap) might make sense. For example:
>>
>> total_reserved = 0;
>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>> max_heap_size);
>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>> max_perm_size);
>>
>> Where the function is:
>>
>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>   const char* msg = "...";
>>   x += y;
>>   if (x < y) {
>>     vm_exit(msg);
>>   }
>>   return x;
>> }
>>
>> But I can live with your current changes.
>>
>> JohnC
>>
>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>> Hi Bengt,
>>>
>>> Thank you for reviewing. A new webrev is updated.
>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>
>>> Cheers,
>>> Tao
>>>
>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Tao,
>>>>
>>>> This change looks good. Thanks for adding the JTReg test, it looks 
>>>> good!
>>>>
>>>> One minor nit:
>>>>
>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>> duplicating the calculation.
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>
>>>>> changeset:
>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>
>>>>> It provides for 32-bit builds a preventive check of the size of 
>>>>> "the object heap + perm gen" before reserving VM memory. The total 
>>>>> size should not exceed 4096MB (i.e. 4GB) for 32-bit builds; 
>>>>> otherwise, the total doesn't make sense and, what's worse, 
>>>>> overflow occurs. It will consequentially trigger anther error of 
>>>>> memory access violation, which was not protected.
>>>>>
>>>>> jtreg testing java code is also written, checking both 32-bit and 
>>>>> (trivially) 64-bit builds.
>>>>>
>>>>> testing:
>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>>> builds of 32-bit and 64-bit. All passed.
>>>>>
>>>>> Needs JPRT test when pushing.
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130419/e13561a7/attachment.htm>

From jon.masamitsu at oracle.com  Fri Apr 19 18:41:16 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 19 Apr 2013 11:41:16 -0700
Subject: Request for review(s) - 8012111: Remove warning about CMS generation
	shrinking.
Message-ID: <51718FCC.9070207@oracle.com>

8012111: Remove warning about CMS generation shrinking.

The warning message

"Java HotSpot(TM) Server VM warning: Shrinking of CMS not yet implemented"

should not generally be emitted.  Guard it with PrintGCDetails and Verbose.

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


From bernd-2013 at eckenfels.net  Fri Apr 19 18:53:52 2013
From: bernd-2013 at eckenfels.net (Bernd Eckenfels)
Date: Fri, 19 Apr 2013 20:53:52 +0200
Subject: javax GC API
In-Reply-To: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
Message-ID: <op.wvsxf2betc8ri4@eckenfels02.seeburger.de>

Am 19.04.2013, 10:06 Uhr, schrieb Suminda Dharmasena <sirinath at sakrio.com>:
>    - GCAtBlockEnd
>    - GCAtBlockExit - for loops the GC happens when the
>    - GCAtLastReference
>    - GCAtEndOfScope
>    - GCOnAssignment
>    - GCOnReturn
...
> At each point the objects pointed by the handle are GCed if there is
> a possibility (reference count becomes 0). If a reference to an object is
> specified to be

I think most of those annotations are not possible with modern GCs. You  
need to be aware that there is no reference counting and there is already  
Escape Analysis, Nursery and Thread Local allocations dealing with most of  
the scopes you listed above anyway.

Greetings
Bernd
-- 
http://bernd.eckenfels.net


From jon.masamitsu at oracle.com  Sat Apr 20 00:18:14 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 19 Apr 2013 17:18:14 -0700
Subject: Review request: 8012687: Remove unused is_root checks and closures
In-Reply-To: <51712E8C.90506@oracle.com>
References: <51712E8C.90506@oracle.com>
Message-ID: <5171DEC6.1020001@oracle.com>

Looks good.

Jon

On 4/19/2013 4:46 AM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8012687/webrev.00/
>
> From bug description:
> There's an unused parameter named is_root that is passed down to a 
> number of MarkSweep/ParOld closures. This enhancement suggests that we 
> remove it and cleanup the trails after it.
>
> thanks,
> StefanK



From sirinath at sakrio.com  Sat Apr 20 03:33:37 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Sat, 20 Apr 2013 09:03:37 +0530
Subject: javax GC API
In-Reply-To: <1366398741847.567994183@boxbe>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<1366398741847.567994183@boxbe>
Message-ID: <CAAfFNYETmf=M49oxBTkL8NFO5Bb8iC4sFERVEeYeXK3FkGXyzg@mail.gmail.com>

Hi,

Many objects created locally and final static /
constructor initialized composition objects in the locally created object
can be allocated in the stack thus with proper compile time escape analysis
in a language like java which does not have pointer aliasing can eliminate
the need of a GC for about 90 % of the cases.

Introducing these semantics will ensure this as current java model defaults
to heap allocation. Also giving control at what point to adjust the stack
frame thus the memory allocated to the objects are claimed. This will
increase Java's appeal for small memory embedded RT systems as GC will
become the last resort fall back and many objects will not need to be GCed.

IMO, the runtime overhead of complicated GC mechanisms are not warranted as
the objects that really needed to be allocated on the heap are static
fields and fields that not final and cannot be declared final. Many fixed
size non final objects also can be stack allocated. When they get updated
the object needs to be replaced in the relevant stack frame. Also analysis
could check if an object that escapes the current stack frame makes its way
to a parent stack frame. This way provisions can be made to allocate in the
parent frame.

Also many of the stack allocated objects need not be finalised unless the
object's finalizer method is overridden. This will reduce memory reclaim
overhead.

With regard to heap allocated objects the GC can also happen at defined
intervals. E.g. if an object is marked GCOnReturn if the return object is
not utilised after return it is GCed. Also GCOnBlockExit will ensure all
objects in a loop be GCed.

Suminda
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--


On 20 April 2013 00:23, Bernd Eckenfels <bernd-2013 at eckenfels.net> wrote:

>  [image: Boxbe] <https://www.boxbe.com/overview> Bernd Eckenfels (
> bernd-2013 at eckenfels.net) is not on your Guest List<https://www.boxbe.com/approved-list?tc_serial=13987150962&tc_rand=1830316824&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=ERETQw2iSwWyZqUVy76d2X7D%2F%2F1UN2fq1vBQ3U05A610e9%2BPq6fzfA1%2BIWsiZ6IC&key=tCvAXRTXiRsJgeiodBg7x4xQ4kT9uFWND969c4eXeK8%3D>| Approve
> sender<https://www.boxbe.com/anno?tc_serial=13987150962&tc_rand=1830316824&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=ERETQw2iSwWyZqUVy76d2X7D%2F%2F1UN2fq1vBQ3U05A610e9%2BPq6fzfA1%2BIWsiZ6IC&key=tCvAXRTXiRsJgeiodBg7x4xQ4kT9uFWND969c4eXeK8%3D>| Approve
> domain<https://www.boxbe.com/anno?tc_serial=13987150962&tc_rand=1830316824&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&dom&token=ERETQw2iSwWyZqUVy76d2X7D%2F%2F1UN2fq1vBQ3U05A610e9%2BPq6fzfA1%2BIWsiZ6IC&key=tCvAXRTXiRsJgeiodBg7x4xQ4kT9uFWND969c4eXeK8%3D>
>
> Am 19.04.2013, 10:06 Uhr, schrieb Suminda Dharmasena <sirinath at sakrio.com
> >:
>
>>    - GCAtBlockEnd
>>    - GCAtBlockExit - for loops the GC happens when the
>>    - GCAtLastReference
>>    - GCAtEndOfScope
>>    - GCOnAssignment
>>    - GCOnReturn
>>
> ...
>
>> At each point the objects pointed by the handle are GCed if there is
>> a possibility (reference count becomes 0). If a reference to an object is
>> specified to be
>>
>
> I think most of those annotations are not possible with modern GCs. You
> need to be aware that there is no reference counting and there is already
> Escape Analysis, Nursery and Thread Local allocations dealing with most of
> the scopes you listed above anyway.
>
> Greetings
> Bernd
> --
> http://bernd.eckenfels.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130420/fffc3e58/attachment.htm>

From bengt.rutisson at oracle.com  Mon Apr 22 05:33:48 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 22 Apr 2013 07:33:48 +0200
Subject: Request for review(s) - 8012111: Remove warning about CMS
	generation shrinking.
In-Reply-To: <51718FCC.9070207@oracle.com>
References: <51718FCC.9070207@oracle.com>
Message-ID: <5174CBBC.5030101@oracle.com>


Hi Jon,

Looks good!

A few minor nits in the JTreg test:

- I think the "@test" line should have the test name in it. So, "@test 
GuardShrinkWarning".

- I don't think you need the "Go" parameter on line 45.

- Why do you need the loop in SystemGCCaller to do 50 System.gc() calls? 
I think the warning is printed for every GC, so one System.gc() call 
should be enough, right?

- Do you need the "garbage" that you create in SystemGCCaller? I also 
think you can drop the System.println(".") call.

Thanks,
Bengt


On 4/19/13 8:41 PM, Jon Masamitsu wrote:
> 8012111: Remove warning about CMS generation shrinking.
>
> The warning message
>
> "Java HotSpot(TM) Server VM warning: Shrinking of CMS not yet 
> implemented"
>
> should not generally be emitted.  Guard it with PrintGCDetails and 
> Verbose.
>
> http://cr.openjdk.java.net/~jmasa/8012111/webrev.00/

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

From bengt.rutisson at oracle.com  Mon Apr 22 07:58:27 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 22 Apr 2013 09:58:27 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <51717E6E.4020806@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
Message-ID: <5174EDA3.9000605@oracle.com>


Hi Tao,

On 4/19/13 7:27 PM, Tao Mao wrote:
> 1. check overflow routine is wrapped up.

I would prefer that the method 
CollectedHeap::add_to_total_reserved_and_check_overflow() did not return 
a bool. Since you do vm_exit_during_initialization() when you overflow 
there is no need to return different results. This would also simplify 
the code where you use it. No need to use if statements.

Also, I think you should remove the naming references to 
"total_reserved" and "reserved". This method is general enough to just 
add two size_t arguments together and check for overflow. Especially if 
it would take the message as a parameter. Instead of returning a bool 
you can return the result of the addition if there was no overflow.

I'm not sure we need round_up_total_reserved_and_check_overflow() since 
it is only being used in one place.

>
> 2. The reduction of code duplication is adopted.

Good.

>
> 3. Develop a way to intake 0~multiple external vm options in jtreg main().

Yes, this looks like it should work. However, based on John 
Cuthbertson's discussion with Leonid I think you need to do the same 
thing for test.java.opts too.

Bengt



> Hope it helps others implement similar functionality.
> webrev:
> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>
> test:
> JTREG: passed.
> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
> <GC_OPTION>" 
> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>
> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>
>
> Thanks.
> Tao
>
> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>
>> Hi Tao,
>>
>> I agree with John. The changes look fine and I'm ok with them. But it 
>> would look nicer to add the 
>> CollectedHeap::add_and_verify_no_overflow() method.
>>
>> Also, regarding the test, a couple of minor things.
>>
>> First, with the new naming convention I think the test should be 
>> called something like:
>>
>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>
>> Then I think you can reduce the code duplication a bit. You create 
>> the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit 
>> cases. So maybe it could look like this instead:
>>
>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>   public static void main(String args[]) throws Exception {
>>     ProcessBuilder pb =
>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>> "-Xmx3072m",
>> "-XX:MaxPermSize=1024m",
>> "-version");
>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>
>>     String dataModel = System.getProperty("sun.arch.data.model");
>>     if (dataModel.equals("32")) {
>>       output.shouldContain("The size of the object heap + perm gen 
>> exceeds the maximum representable size");
>>       if (output.getExitValue() == 0) {
>>         throw new RuntimeException("Not expected to get exit value 0");
>>       }
>>     } else if (dataModel.equals("64")) {
>>       output.shouldHaveExitValue(0);
>>     }
>>   }
>> }
>>
>> There is also a small bug in the test. If you run JTreg without 
>> passing any vmoptions the test will fail. The reason is that 
>> System.getProperty("test.vm.opts") will evaluate to the empty string. 
>> This will be passed as the first argument to the Java process, which 
>> will assume that this is the class name. So, it fails to start 
>> because it can't load the class <empty string>.
>>
>> To reproduce the problem use this command line:
>>
>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>
>> I guess the fix is to check that System.getProperty("test.vm.opts") 
>> is not empty before passing it on to createJavaProcessBuilder().
>>
>> Thanks,
>> Bengt
>>
>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>> Hi Tao,
>>>
>>> This looks OK to me.
>>>
>>> I can see what Thomas is saying though. All of the checks involve 
>>> something like:
>>>
>>> total += some_value;
>>> if (total < some_value) {
>>>   // We must have overflowed
>>>   vm_exit(...);
>>> }
>>>
>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>> ParallelScavengeHeap) might make sense. For example:
>>>
>>> total_reserved = 0;
>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>> max_heap_size);
>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>> max_perm_size);
>>>
>>> Where the function is:
>>>
>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>   const char* msg = "...";
>>>   x += y;
>>>   if (x < y) {
>>>     vm_exit(msg);
>>>   }
>>>   return x;
>>> }
>>>
>>> But I can live with your current changes.
>>>
>>> JohnC
>>>
>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>> Hi Bengt,
>>>>
>>>> Thank you for reviewing. A new webrev is updated.
>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>
>>>> Cheers,
>>>> Tao
>>>>
>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>
>>>>> Hi Tao,
>>>>>
>>>>> This change looks good. Thanks for adding the JTReg test, it looks 
>>>>> good!
>>>>>
>>>>> One minor nit:
>>>>>
>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>>> duplicating the calculation.
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>
>>>>>> changeset:
>>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>
>>>>>> It provides for 32-bit builds a preventive check of the size of 
>>>>>> "the object heap + perm gen" before reserving VM memory. The 
>>>>>> total size should not exceed 4096MB (i.e. 4GB) for 32-bit builds; 
>>>>>> otherwise, the total doesn't make sense and, what's worse, 
>>>>>> overflow occurs. It will consequentially trigger anther error of 
>>>>>> memory access violation, which was not protected.
>>>>>>
>>>>>> jtreg testing java code is also written, checking both 32-bit and 
>>>>>> (trivially) 64-bit builds.
>>>>>>
>>>>>> testing:
>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>>>> builds of 32-bit and 64-bit. All passed.
>>>>>>
>>>>>> Needs JPRT test when pushing.
>>>>>
>>>
>>

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

From leonid.mesnik at oracle.com  Mon Apr 22 09:46:22 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Mon, 22 Apr 2013 13:46:22 +0400
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <51717E6E.4020806@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
Message-ID: <517506EE.5030000@oracle.com>

Tao

This is not review, just question.

Should you test pass on hosts with 512M-1GB memory and no swap?

Leonid
On 04/19/2013 09:27 PM, Tao Mao wrote:
> 1. check overflow routine is wrapped up.
>
> 2. The reduction of code duplication is adopted.
>
> 3. Develop a way to intake 0~multiple external vm options in jtreg 
> main(). Hope it helps others implement similar functionality.
>
> webrev:
> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>
> test:
> JTREG: passed.
> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
> <GC_OPTION>" 
> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>
> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>
>
> Thanks.
> Tao
>
> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>
>> Hi Tao,
>>
>> I agree with John. The changes look fine and I'm ok with them. But it 
>> would look nicer to add the 
>> CollectedHeap::add_and_verify_no_overflow() method.
>>
>> Also, regarding the test, a couple of minor things.
>>
>> First, with the new naming convention I think the test should be 
>> called something like:
>>
>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>
>> Then I think you can reduce the code duplication a bit. You create 
>> the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit 
>> cases. So maybe it could look like this instead:
>>
>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>   public static void main(String args[]) throws Exception {
>>     ProcessBuilder pb =
>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>> "-Xmx3072m",
>> "-XX:MaxPermSize=1024m",
>> "-version");
>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>
>>     String dataModel = System.getProperty("sun.arch.data.model");
>>     if (dataModel.equals("32")) {
>>       output.shouldContain("The size of the object heap + perm gen 
>> exceeds the maximum representable size");
>>       if (output.getExitValue() == 0) {
>>         throw new RuntimeException("Not expected to get exit value 0");
>>       }
>>     } else if (dataModel.equals("64")) {
>>       output.shouldHaveExitValue(0);
>>     }
>>   }
>> }
>>
>> There is also a small bug in the test. If you run JTreg without 
>> passing any vmoptions the test will fail. The reason is that 
>> System.getProperty("test.vm.opts") will evaluate to the empty string. 
>> This will be passed as the first argument to the Java process, which 
>> will assume that this is the class name. So, it fails to start 
>> because it can't load the class <empty string>.
>>
>> To reproduce the problem use this command line:
>>
>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>
>> I guess the fix is to check that System.getProperty("test.vm.opts") 
>> is not empty before passing it on to createJavaProcessBuilder().
>>
>> Thanks,
>> Bengt
>>
>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>> Hi Tao,
>>>
>>> This looks OK to me.
>>>
>>> I can see what Thomas is saying though. All of the checks involve 
>>> something like:
>>>
>>> total += some_value;
>>> if (total < some_value) {
>>>   // We must have overflowed
>>>   vm_exit(...);
>>> }
>>>
>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>> ParallelScavengeHeap) might make sense. For example:
>>>
>>> total_reserved = 0;
>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>> max_heap_size);
>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>> max_perm_size);
>>>
>>> Where the function is:
>>>
>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>   const char* msg = "...";
>>>   x += y;
>>>   if (x < y) {
>>>     vm_exit(msg);
>>>   }
>>>   return x;
>>> }
>>>
>>> But I can live with your current changes.
>>>
>>> JohnC
>>>
>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>> Hi Bengt,
>>>>
>>>> Thank you for reviewing. A new webrev is updated.
>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>
>>>> Cheers,
>>>> Tao
>>>>
>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>
>>>>> Hi Tao,
>>>>>
>>>>> This change looks good. Thanks for adding the JTReg test, it looks 
>>>>> good!
>>>>>
>>>>> One minor nit:
>>>>>
>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>>> duplicating the calculation.
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>
>>>>>> changeset:
>>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>
>>>>>> It provides for 32-bit builds a preventive check of the size of 
>>>>>> "the object heap + perm gen" before reserving VM memory. The 
>>>>>> total size should not exceed 4096MB (i.e. 4GB) for 32-bit builds; 
>>>>>> otherwise, the total doesn't make sense and, what's worse, 
>>>>>> overflow occurs. It will consequentially trigger anther error of 
>>>>>> memory access violation, which was not protected.
>>>>>>
>>>>>> jtreg testing java code is also written, checking both 32-bit and 
>>>>>> (trivially) 64-bit builds.
>>>>>>
>>>>>> testing:
>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>>>> builds of 32-bit and 64-bit. All passed.
>>>>>>
>>>>>> Needs JPRT test when pushing.
>>>>>
>>>
>>


-- 
Leonid Mesnik
JVM SQE

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

From thomas.schatzl at oracle.com  Mon Apr 22 09:56:52 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 22 Apr 2013 11:56:52 +0200
Subject: Request for review: 6761744 Hotspot crashes if process size
	limit is exceeded
In-Reply-To: <5174EDA3.9000605@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<5174EDA3.9000605@oracle.com>
Message-ID: <1366624612.2774.12.camel@cirrus>

Hi,

On Mon, 2013-04-22 at 09:58 +0200, Bengt Rutisson wrote:
> 
> Hi Tao,
>
> On 4/19/13 7:27 PM, Tao Mao wrote:
>
> > 1. check overflow routine is wrapped up.
>
>I'm not sure we need round_up_total_reserved_and_check_overflow() since
>it is only being used in one place. 

Actually it is an interesting question why only the total of
GenCollectedHeaps is rounded up to large page size and the others are
not.

It seems that in parallel old, at these heap sizes, some code that
calculates internal alignment would result in an alignment > large page
size, so it would be okay, i.e. overflow already when adding together
the components.

At least with G1 with a 1 MB region size there might be an issue as e.g.
the perm gen size is rounded to heap region size. Or there is not an
issue at all, but why then do the rounding only for GenCollectedHeaps?

(I think the rounding can at most make the total overflow into a
resulting zero. I am not sure if the heap reserve functions give an
error if you pass a requested virtual space size of zero anyway...)

Hth,
Thomas




From mikael.gerdin at oracle.com  Mon Apr 22 10:58:57 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Mon, 22 Apr 2013 10:58:57 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 30 new changesets
Message-ID: <20130422110000.E11B1484D3@hg.openjdk.java.net>

Changeset: 35f8765422b9
Author:    zgu
Date:      2013-04-10 08:55 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/35f8765422b9

8010151: nsk/regression/b6653214 fails "assert(snapshot != NULL) failed: Worker should not be started"
Summary: Fixed a racing condition when shutting down NMT while worker thread is being started, also fixed a few mis-declared volatile pointers.
Reviewed-by: dholmes, dlong

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

Changeset: f2c0ccccc6b6
Author:    rdurbin
Date:      2013-04-16 08:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f2c0ccccc6b6

Merge


Changeset: cbf8c8c25bbe
Author:    mgerdin
Date:      2013-04-18 14:38 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cbf8c8c25bbe

Merge


Changeset: aeaca88565e6
Author:    jiangli
Date:      2013-04-09 17:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aeaca88565e6

8010862: The Method counter fields used for profiling can be allocated lazily.
Summary: Allocate the method's profiling related metadata until they are needed.
Reviewed-by: coleenp, roland

! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/invocationCounter.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
+ src/share/vm/oops/methodCounters.cpp
+ src/share/vm/oops/methodCounters.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 42a42da29fd7
Author:    jiangli
Date:      2013-04-11 23:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/42a42da29fd7

8012052: java/lang/invoke/6987555/Test6987555.java crashes with assert(mcs != NULL) failed: MethodCounters cannot be NULL.
Summary: Skip counter decay if the MethodCounters is NULL in NonTieredCompPolicy::delay_compilation().
Reviewed-by: kvn, dholmes

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

Changeset: 8df6ddda8090
Author:    jiangli
Date:      2013-04-15 21:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8df6ddda8090

Merge

! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 9500809ceead
Author:    jiangli
Date:      2013-04-18 17:00 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9500809ceead

Merge

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: b8b081e53312
Author:    twisti
Date:      2013-04-12 12:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b8b081e53312

8011933: add number of classes, methods and time spent to CompileTheWorld
Reviewed-by: jrose, kvn

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp

Changeset: 393fd4ef89c4
Author:    twisti
Date:      2013-04-12 15:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/393fd4ef89c4

8011678: test/Makefile should pick up JT_HOME environment variable
Reviewed-by: kvn

! test/Makefile

Changeset: f36e073d56a4
Author:    drchase
Date:      2013-04-12 15:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f36e073d56a4

7104565: trim jprt build targets
Summary: remove JPRT debug builds, remove -DDEBUG -DFASTDEBUG and use ASSERT instead in sources
Reviewed-by: dholmes, kvn, coleenp

! make/Makefile
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/debug.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/fastdebug.make
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
! make/jprt.properties
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/debug.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/fastdebug.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/debug.make
! make/solaris/makefiles/defs.make
! make/solaris/makefiles/fastdebug.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
! make/windows/build.make
! make/windows/makefiles/defs.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/compiler2/ADLCompiler.dsp
! make/windows/projectfiles/tiered/ADLCompiler.dsp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/os/bsd/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/tools/hsdis/Makefile
! src/share/vm/classfile/stackMapFrame.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/vmThread.cpp

Changeset: bc63dd2539a4
Author:    kvn
Date:      2013-04-12 20:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bc63dd2539a4

Merge

! make/bsd/makefiles/debug.make
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
! make/linux/makefiles/debug.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
! make/solaris/makefiles/debug.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make

Changeset: 886d1fd67dc3
Author:    drchase
Date:      2013-04-12 19:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/886d1fd67dc3

6443505: Ideal() function for CmpLTMask
Summary: Repair wrong code generation, added new matching rule
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/cfgnode.cpp
+ test/compiler/6443505/Test6443505.java

Changeset: bb4a966cc68f
Author:    roland
Date:      2013-04-15 09:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bb4a966cc68f

8011582: assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range
Summary: c1 runtime's predicate_failed_trap should use jump_to on sparc
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp

Changeset: 1c6887c9afaa
Author:    twisti
Date:      2013-04-15 16:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1c6887c9afaa

7172922: export_ makefile targets do not work unless all supported variants are built
Reviewed-by: dholmes, kvn

! make/Makefile

Changeset: acadb114c818
Author:    roland
Date:      2013-04-15 17:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/acadb114c818

8011648: C1: optimized build is broken after 7153771
Summary: missing #ifdef ASSERT
Reviewed-by: kvn

! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_RangeCheckElimination.hpp
! src/share/vm/c1/c1_ValueMap.hpp

Changeset: b105029fdbfd
Author:    roland
Date:      2013-04-15 18:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b105029fdbfd

Merge


Changeset: 8373c19be854
Author:    neliasso
Date:      2013-04-16 10:08 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8373c19be854

8011621: live_ranges_in_separate_class.patch
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! make/bsd/makefiles/vm.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! make/windows/create_obj_files.sh
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/coalesce.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/regalloc.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: c89eab0b6b30
Author:    neliasso
Date:      2013-04-16 10:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c89eab0b6b30

Merge

- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp

Changeset: 4b2eebe03f93
Author:    iignatyev
Date:      2013-04-16 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4b2eebe03f93

8011971: WB API doesn't accept j.l.reflect.Constructor
Reviewed-by: kvn, vlivanov

! src/share/vm/prims/whitebox.cpp
! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: a7fb14888912
Author:    neliasso
Date:      2013-04-11 13:57 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a7fb14888912

8006952: Slow VM due to excessive code cache freelist iteration
Summary: Remove continous free block requirement
Reviewed-by: kvn

! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heap.hpp
! src/share/vm/opto/output.cpp

Changeset: dedc8563e33d
Author:    bharadwaj
Date:      2013-04-18 16:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dedc8563e33d

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp

Changeset: 2a9d97b57920
Author:    bharadwaj
Date:      2013-04-19 03:13 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2a9d97b57920

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b0301c02f38e
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b0301c02f38e

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! make/bsd/makefiles/fastdebug.make
! src/share/vm/services/diagnosticArgument.cpp
! test/sanity/WBApi.java
! test/serviceability/ParserTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
! test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java

Changeset: c9eb0ec1c792
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c9eb0ec1c792

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 86db4847f195
Author:    katleman
Date:      2013-04-17 12:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/86db4847f195

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 2e657354f6bc
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2e657354f6bc

Added tag jdk8-b86 for changeset 86db4847f195

! .hgtags

Changeset: 01d5f04e64dc
Author:    amurillo
Date:      2013-04-19 09:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/01d5f04e64dc

Merge

! make/bsd/makefiles/fastdebug.make
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 0491c26b1f1d
Author:    amurillo
Date:      2013-04-19 09:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0491c26b1f1d

Added tag hs25-b29 for changeset 01d5f04e64dc

! .hgtags

Changeset: f78763f49817
Author:    amurillo
Date:      2013-04-19 10:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f78763f49817

8012559: new hotspot build - hs25-b30
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: d391427ddc29
Author:    mgerdin
Date:      2013-04-22 10:10 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d391427ddc29

Merge




From mikael.gerdin at oracle.com  Mon Apr 22 11:21:38 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 22 Apr 2013 13:21:38 +0200
Subject: Request for review (m) 8008966: NPG: Inefficient Metaspace counter
	functions cause large young GC regressions
In-Reply-To: <5170D022.5060102@oracle.com>
References: <515271FB.9090203@oracle.com> <51562FB7.9010609@oracle.com>
	<516892E5.9030105@oracle.com> <5170D022.5060102@oracle.com>
Message-ID: <51751D42.30706@oracle.com>

Jon,

On 2013-04-19 07:03, Jon Masamitsu wrote:
> This is the webrev for the complete set of  changes
> (updated to the latest gc_baseline).
>
> http://cr.openjdk.java.net/~jmasa/8008966/webrev.01/

It looks like you've changed the value of 
MetaspaceGC::_capacity_until_GC to be in bytes.
In that case you should remove MetaspaceGC::capacity_until_GC_in_bytes() 
and change Metaspace::expand_and_allocate which still seems to call 
inc_capacity_until_GC with a size in words.

I'm curious about
1930   if (vs_list() != NULL) {
1931     vs_list()->chunk_manager()->locked_print_free_chunks(st);
1932     vs_list()->chunk_manager()->locked_print_sum_free_chunks(st);
1933   }

I'm having trouble understanding how _vs_list can be null since it's 
initialized in the SpaceManager constructor. Did you see a SpaceManager 
with an uninitialized _vs_list?


2657              capacity_bytes / K);
2658   assert(used_and_free == capacity_bytes, "Accounting is wrong");

2659 }
You removed the safepoint case here, the reason for that code is that
Metaspace::allocate calls MetaspaceAux::dump() when not at safepoint if 
+Verbose && +TraceMetadataChunkAllocation before throwing OOME.
If another thread is allocating metadata and not failing while this 
function is being executed we can get inconsistent accounting, right?

If you don't want the !SafepointSychronize::is_at_safepoint() condition 
in the assert then please remove the call to MetasapceAux::dump from the 
allocate path.

The rest looks good.

/Mikael


>
> Thanks.
>
> Jon
>
> On 4/12/2013 4:04 PM, Jon Masamitsu wrote:
>> This is the promised semantic changes for the code review.  Whereas
>> the original set of changes only maintained a running sum for the
>> capacity of all the space for metadata, this added a running sum
>> for the used space allocated and holding metadata.
>>
>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00_2/
>>
>> This is an incremental webrev based on the name change webrev
>> (webrev.00_1) below.  A complete webrev with all changes will
>> be published after comments for this have been digested.
>>
>> Thanks.
>>
>> Jon
>>
>> On 3/29/2013 5:20 PM, Jon Masamitsu wrote:
>>> Ths webrev has mostly name changes suggested by the code
>>> review comments.  There are additional changes coming that
>>> relate to semantic changes suggested by the code review.
>>>
>>> This was created by deleting some of the suggested semantic
>>> changes so will not compile.  The next webrev will be relative
>>> to this one so you won't have to look at the name changes when
>>> looking and the semantic changes.
>>>
>>> Ignore the block comment about chunk accounting at the
>>> beginning of metaspace.cpp.  That will be updated or deleted
>>> in the next webrev.
>>>
>>> The deletion of some dead code is included in this webrev
>>> (limited number of lines).
>>>
>>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00_1/
>>>
>>> Thanks.
>>>
>>> Jon
>>>
>>> On 3/26/2013 9:13 PM, Jon Masamitsu wrote:
>>>>
>>>> Replace the use of a method that calculated the total capacity of
>>>> the Metaspaces by iterating over all the Metaspaces by maintaining
>>>> the sum of Metaspace capacities as the Metachunks are
>>>> allocated to each Metaspace.  Also maintain a sum for each
>>>> Metaspace as the Metachunks are allocated to that Metaspace.
>>>>
>>>> Change should_expand() and compute_new_space() to
>>>> calculate quantities in bytes.
>>>>
>>>> Remove calls to methods that calculated totals for
>>>> "used" and "free" by iterating over the Metaspaces
>>>> in product mode.  In some cases substitute the use
>>>> of capacity for used.
>>>>
>>>> http://cr.openjdk.java.net/~jmasa/8008966/webrev.00/
>>>>
>>>> Thanks.
>>>>
>>>> Jon
>>>
>>
>


From mikael.gerdin at oracle.com  Mon Apr 22 12:38:07 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 22 Apr 2013 14:38:07 +0200
Subject: RFR (s): JDK-8011802 NPG: init_dependencies in class loader data
	graph can cause invalid CLD
Message-ID: <51752F2F.3050800@oracle.com>

Hi,

here is my suggested fix for the ClassLoaderData initialization issue 
that David brought up in the review thread for JDK-8010196.

The problem:
Upon initialization of a ClassLoaderData (from 
ClassLoaderDataGraph::add) the newly created CLD is added to the 
ClassLoderData linked list and to the hidden field in the 
java/lang/ClassLoader object before we call init_dependencies to create 
the Java object array.
Since the creation of the object array can throw a Java Exception (OOME) 
we need to be able to clean up if that happens.


The fix:
Instead of trying to undo what we did when adding the CLD I suggest that 
we first try to init_dependencies and if that succeeds we proceed to try 
to add the CLD to the ClassLoader and the list.
If two threads are simultaneously trying to create a CLD for a loader we 
will now allocate a few unnecessary object arrays since we allocate them 
optimistically but since we don't hang on to them they should not cause 
any memory overhead.

I also took the liberty to change the way we signal that a CLD is for an 
anonymous class to use a boolean instead of passing a null value to the 
CLD** and moved all the code to write the CLD* into the ClassLoader to 
ClassLoaderDataGraph::add. The code motion is necessary since 
init_dependencies may trigger a GC and the CLD** which was passed in was 
in fact a raw pointer into the ClassLoader in the Java heap.

Unfortunately I can't use CHECK_NULL when calling init_dependencies 
since I need to delete the cld before returning.

Webrev: http://cr.openjdk.java.net/~mgerdin/8011802/webrev.0/

bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011802
jbs: https://jbs.oracle.com/bugs/browse/JDK-8011802

/Mikael


From sirinath at sakrio.com  Mon Apr 22 16:27:42 2013
From: sirinath at sakrio.com (Suminda Dharmasena)
Date: Mon, 22 Apr 2013 21:57:42 +0530
Subject: javax GC API
In-Reply-To: <CAEAKNo_=Ymn8b5ruXNqe+S2a5EUQ7DVn2Gbi8kiZZ1j7u_eB6w@mail.gmail.com>
References: <CAAfFNYER+UK61rE8SKnQBb3C+wdp59yC2zapUKz64ZxkTgcOeQ@mail.gmail.com>
	<CAAfFNYEDRyheA6xkr=xaEXpcS=-cXO7A_bci0r+w9CGE2fhEng@mail.gmail.com>
	<CAAfFNYENNpef6iNyrsn2hp2ULbhhXZvgTNEHjKX49qG4JSm06A@mail.gmail.com>
	<31A020B9-F7F2-4DC4-9EE8-E8ABF1D25A69@kodewerk.com>
	<CAAfFNYFXh7CdRqAq_UYyJpZG+yXBPeitF-UO7u8QFNCsBVTzdQ@mail.gmail.com>
	<CAAfFNYGBA3JdFk2CMSiE4ruB7jFSwUHQOMquBMRDf2F=GtumFA@mail.gmail.com>
	<CAEAKNo_=Ymn8b5ruXNqe+S2a5EUQ7DVn2Gbi8kiZZ1j7u_eB6w@mail.gmail.com>
Message-ID: <CAAfFNYFuFWri2tZnnYVLebtuW5J8y+541eF8i5rsxPhKtBEhUg@mail.gmail.com>

Hi,

Proper escape analysis can eliminate the need of GC. I
cannot understand why Oracle (Sun before oracle) choose to carry the burden
of the GC. This creates:

   - Memory footprint
   - Processing footprint
   - GC pause

With proper escape analysis and allocating in the stack GC can
be eliminated in most cases. Also finalising can be eliminated.

Annotations can be used what point exactly the resource is released. This
will take only fraction of nanoseconds but this also will be known.

Also collection can happen in a deferred mode as this is what needs to be
GCed. Ideally this should be reserved for IO pause applications which can
run the GC thread on pause.

Suminda
--
Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond.,
P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakr??! ? *Address*: 6G ? 1st
Lane ? Pagoda Road ? Nugegoda 10250 ? Sri Lanka. ? *Tele*: +94-(0)11-5
864614 / 5 875614 / 2 825908 ? *Web*: http://www.sakrio.com ?

This email is subjected to the email Terms of Use and Disclaimer:
http://www.sakrio.com/email-legal. Please read this first.
--


On 22 April 2013 19:45, Ryan Gardner <ryebrye at gmail.com> wrote:

> On Fri, Apr 19, 2013 at 6:04 AM, Suminda Dharmasena <sirinath at sakrio.com>wrote:
>
>> Also if the programmer fails to wisely GC using API / Annotations then
>> the fallback is the default GC mechanism. This way there will be no memory
>> leaks. Also objects which are GCed will be objects that can be GCed. Live /
>> referenced objects which escape the explicit GC context will not be GCed.
>>
>> The objective is that:
>>
>>    - The GC check happens at define points in code
>>    - GC happens at define points if possible, else fall back to the
>>    system GC mechanism
>>
>> How will this work with multithreaded environments like a web server?
>
> The stop-the-world phases of GC by definition stop more than just one
> thread?
>
> Also this seems very JVM vendor specific - I can't imagine the Azul guys
> (who market their JVM as if GC pauses don't exist at all on their VM) would
> care about this, nor would the IBM guys likely care.
>
> The specific annotations proposed also do not follow the best practice for
> naming annotations - they explicitly define a specific behavior to take as
> a result of the annotation being applied.
>
> I'm just a community member, and not a hotspot engineer or contributor -
> but I can wholeheartedly say that I would never use these annotations and I
> would never use code from any open source project that littered their
> project with these annotations.
>
>
>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130422/efc5812f/attachment.htm>

From jon.masamitsu at oracle.com  Mon Apr 22 16:39:30 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 22 Apr 2013 09:39:30 -0700
Subject: Request for review(s) - 8012111: Remove warning about CMS
	generation shrinking.
In-Reply-To: <5174CBBC.5030101@oracle.com>
References: <51718FCC.9070207@oracle.com> <5174CBBC.5030101@oracle.com>
Message-ID: <517567C2.4020206@oracle.com>


On 4/21/13 10:33 PM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Looks good!
>
> A few minor nits in the JTreg test:
>
> - I think the "@test" line should have the test name in it. So, "@test 
> GuardShrinkWarning".
Fixed.
>
> - I don't think you need the "Go" parameter on line 45.

Deleted.

>
> - Why do you need the loop in SystemGCCaller to do 50 System.gc() 
> calls? I think the warning is printed for every GC, so one System.gc() 
> call should be enough, right?

I had thought that the call to System.gc() would return before the 
concurrent
collection finished but that's not the case.  I've removed the loop



>
> - Do you need the "garbage" that you create in SystemGCCaller? I also 
> think you can drop the System.println(".") call.

and I've removed the allocation of the array.

Thanks.

Jon
>
> Thanks,
> Bengt
>
>
> On 4/19/13 8:41 PM, Jon Masamitsu wrote:
>> 8012111: Remove warning about CMS generation shrinking.
>>
>> The warning message
>>
>> "Java HotSpot(TM) Server VM warning: Shrinking of CMS not yet 
>> implemented"
>>
>> should not generally be emitted.  Guard it with PrintGCDetails and 
>> Verbose.
>>
>> http://cr.openjdk.java.net/~jmasa/8012111/webrev.00/
>

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

From stefan.karlsson at oracle.com  Mon Apr 22 18:07:28 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 22 Apr 2013 20:07:28 +0200
Subject: RFR (s): JDK-8011802 NPG: init_dependencies in class loader data
	graph can cause invalid CLD
In-Reply-To: <51752F2F.3050800@oracle.com>
References: <51752F2F.3050800@oracle.com>
Message-ID: <51757C60.3050201@oracle.com>

Looks good.

StefanK

On 2013-04-22 14:38, Mikael Gerdin wrote:
> Hi,
>
> here is my suggested fix for the ClassLoaderData initialization issue 
> that David brought up in the review thread for JDK-8010196.
>
> The problem:
> Upon initialization of a ClassLoaderData (from 
> ClassLoaderDataGraph::add) the newly created CLD is added to the 
> ClassLoderData linked list and to the hidden field in the 
> java/lang/ClassLoader object before we call init_dependencies to 
> create the Java object array.
> Since the creation of the object array can throw a Java Exception 
> (OOME) we need to be able to clean up if that happens.
>
>
> The fix:
> Instead of trying to undo what we did when adding the CLD I suggest 
> that we first try to init_dependencies and if that succeeds we proceed 
> to try to add the CLD to the ClassLoader and the list.
> If two threads are simultaneously trying to create a CLD for a loader 
> we will now allocate a few unnecessary object arrays since we allocate 
> them optimistically but since we don't hang on to them they should not 
> cause any memory overhead.
>
> I also took the liberty to change the way we signal that a CLD is for 
> an anonymous class to use a boolean instead of passing a null value to 
> the CLD** and moved all the code to write the CLD* into the 
> ClassLoader to ClassLoaderDataGraph::add. The code motion is necessary 
> since init_dependencies may trigger a GC and the CLD** which was 
> passed in was in fact a raw pointer into the ClassLoader in the Java 
> heap.
>
> Unfortunately I can't use CHECK_NULL when calling init_dependencies 
> since I need to delete the cld before returning.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8011802/webrev.0/
>
> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011802
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011802
>
> /Mikael



From tao.mao at oracle.com  Mon Apr 22 18:07:48 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Mon, 22 Apr 2013 11:07:48 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <517506EE.5030000@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com>
Message-ID: <51757C74.9000605@oracle.com>

This should be handled by a separate CR (probably by this CR 
https://jbs.oracle.com/bugs/browse/JDK-7112912)

Thanks.
Tao

On 4/22/13 2:46 AM, Leonid Mesnik wrote:
> Tao
>
> This is not review, just question.
>
> Should you test pass on hosts with 512M-1GB memory and no swap?
>
> Leonid
> On 04/19/2013 09:27 PM, Tao Mao wrote:
>> 1. check overflow routine is wrapped up.
>>
>> 2. The reduction of code duplication is adopted.
>>
>> 3. Develop a way to intake 0~multiple external vm options in jtreg 
>> main(). Hope it helps others implement similar functionality.
>>
>> webrev:
>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>
>> test:
>> JTREG: passed.
>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>> <GC_OPTION>" 
>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>
>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>
>>
>> Thanks.
>> Tao
>>
>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>
>>> Hi Tao,
>>>
>>> I agree with John. The changes look fine and I'm ok with them. But 
>>> it would look nicer to add the 
>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>
>>> Also, regarding the test, a couple of minor things.
>>>
>>> First, with the new naming convention I think the test should be 
>>> called something like:
>>>
>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>
>>> Then I think you can reduce the code duplication a bit. You create 
>>> the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit 
>>> cases. So maybe it could look like this instead:
>>>
>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>   public static void main(String args[]) throws Exception {
>>>     ProcessBuilder pb =
>>>       
>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>                                               "-Xmx3072m",
>>>                                               "-XX:MaxPermSize=1024m",
>>>                                               "-version");
>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>
>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>     if (dataModel.equals("32")) {
>>>       output.shouldContain("The size of the object heap + perm gen 
>>> exceeds the maximum representable size");
>>>       if (output.getExitValue() == 0) {
>>>         throw new RuntimeException("Not expected to get exit value 0");
>>>       }
>>>     } else if (dataModel.equals("64")) {
>>>       output.shouldHaveExitValue(0);
>>>     }
>>>   }
>>> }
>>>
>>> There is also a small bug in the test. If you run JTreg without 
>>> passing any vmoptions the test will fail. The reason is that 
>>> System.getProperty("test.vm.opts") will evaluate to the empty 
>>> string. This will be passed as the first argument to the Java 
>>> process, which will assume that this is the class name. So, it fails 
>>> to start because it can't load the class <empty string>.
>>>
>>> To reproduce the problem use this command line:
>>>
>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>
>>> I guess the fix is to check that System.getProperty("test.vm.opts") 
>>> is not empty before passing it on to createJavaProcessBuilder().
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>> Hi Tao,
>>>>
>>>> This looks OK to me.
>>>>
>>>> I can see what Thomas is saying though. All of the checks involve 
>>>> something like:
>>>>
>>>> total += some_value;
>>>> if (total < some_value) {
>>>>   // We must have overflowed
>>>>   vm_exit(...);
>>>> }
>>>>
>>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>>> ParallelScavengeHeap) might make sense. For example:
>>>>
>>>> total_reserved = 0;
>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>> max_heap_size);
>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>> max_perm_size);
>>>>
>>>> Where the function is:
>>>>
>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>   const char* msg = "...";
>>>>   x += y;
>>>>   if (x < y) {
>>>>     vm_exit(msg);
>>>>   }
>>>>   return x;
>>>> }
>>>>
>>>> But I can live with your current changes.
>>>>
>>>> JohnC
>>>>
>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>> Hi Bengt,
>>>>>
>>>>> Thank you for reviewing. A new webrev is updated.
>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>
>>>>> Cheers,
>>>>> Tao
>>>>>
>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Tao,
>>>>>>
>>>>>> This change looks good. Thanks for adding the JTReg test, it 
>>>>>> looks good!
>>>>>>
>>>>>> One minor nit:
>>>>>>
>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>>>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>>>> duplicating the calculation.
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>
>>>>>>> changeset:
>>>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>
>>>>>>> It provides for 32-bit builds a preventive check of the size of 
>>>>>>> "the object heap + perm gen" before reserving VM memory. The 
>>>>>>> total size should not exceed 4096MB (i.e. 4GB) for 32-bit 
>>>>>>> builds; otherwise, the total doesn't make sense and, what's 
>>>>>>> worse, overflow occurs. It will consequentially trigger anther 
>>>>>>> error of memory access violation, which was not protected.
>>>>>>>
>>>>>>> jtreg testing java code is also written, checking both 32-bit 
>>>>>>> and (trivially) 64-bit builds.
>>>>>>>
>>>>>>> testing:
>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>>>>> builds of 32-bit and 64-bit. All passed.
>>>>>>>
>>>>>>> Needs JPRT test when pushing.
>>>>>>
>>>>
>>>
>
>
> -- 
> Leonid Mesnik
> JVM SQE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130422/d4f313b9/attachment.htm>

From coleen.phillimore at oracle.com  Mon Apr 22 18:11:31 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 22 Apr 2013 14:11:31 -0400
Subject: RFR (s): JDK-8011802 NPG: init_dependencies in class loader data
	graph can cause invalid CLD
In-Reply-To: <51757C60.3050201@oracle.com>
References: <51752F2F.3050800@oracle.com> <51757C60.3050201@oracle.com>
Message-ID: <51757D53.5020502@oracle.com>


I agree.  This does look good.
Thanks,
Coleen

On 04/22/2013 02:07 PM, Stefan Karlsson wrote:
> Looks good.
>
> StefanK
>
> On 2013-04-22 14:38, Mikael Gerdin wrote:
>> Hi,
>>
>> here is my suggested fix for the ClassLoaderData initialization issue 
>> that David brought up in the review thread for JDK-8010196.
>>
>> The problem:
>> Upon initialization of a ClassLoaderData (from 
>> ClassLoaderDataGraph::add) the newly created CLD is added to the 
>> ClassLoderData linked list and to the hidden field in the 
>> java/lang/ClassLoader object before we call init_dependencies to 
>> create the Java object array.
>> Since the creation of the object array can throw a Java Exception 
>> (OOME) we need to be able to clean up if that happens.
>>
>>
>> The fix:
>> Instead of trying to undo what we did when adding the CLD I suggest 
>> that we first try to init_dependencies and if that succeeds we 
>> proceed to try to add the CLD to the ClassLoader and the list.
>> If two threads are simultaneously trying to create a CLD for a loader 
>> we will now allocate a few unnecessary object arrays since we 
>> allocate them optimistically but since we don't hang on to them they 
>> should not cause any memory overhead.
>>
>> I also took the liberty to change the way we signal that a CLD is for 
>> an anonymous class to use a boolean instead of passing a null value 
>> to the CLD** and moved all the code to write the CLD* into the 
>> ClassLoader to ClassLoaderDataGraph::add. The code motion is 
>> necessary since init_dependencies may trigger a GC and the CLD** 
>> which was passed in was in fact a raw pointer into the ClassLoader in 
>> the Java heap.
>>
>> Unfortunately I can't use CHECK_NULL when calling init_dependencies 
>> since I need to delete the cld before returning.
>>
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8011802/webrev.0/
>>
>> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011802
>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011802
>>
>> /Mikael
>



From stefan.karlsson at oracle.com  Mon Apr 22 18:19:36 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 22 Apr 2013 20:19:36 +0200
Subject: Review request: 8012687: Remove unused is_root checks and closures
In-Reply-To: <1366374243.3702.2.camel@cirrus>
References: <51712E8C.90506@oracle.com> <1366374243.3702.2.camel@cirrus>
Message-ID: <51757F38.508@oracle.com>

On 2013-04-19 14:24, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2013-04-19 at 13:46 +0200, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8012687/webrev.00/
>>
>>   From bug description:
>> There's an unused parameter named is_root that is passed down to a
>> number of MarkSweep/ParOld closures. This enhancement suggests that we
>> remove it and cleanup the trails after it.
>    looks fine.

Thanks.

StefanK
>
> Thomas
>



From stefan.karlsson at oracle.com  Mon Apr 22 18:20:11 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 22 Apr 2013 20:20:11 +0200
Subject: Review request: 8012687: Remove unused is_root checks and closures
In-Reply-To: <5171DEC6.1020001@oracle.com>
References: <51712E8C.90506@oracle.com> <5171DEC6.1020001@oracle.com>
Message-ID: <51757F5B.7040806@oracle.com>

On 2013-04-20 02:18, Jon Masamitsu wrote:
> Looks good.

Thanks. All set to push.

StefanK
>
> Jon
>
> On 4/19/2013 4:46 AM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8012687/webrev.00/
>>
>> From bug description:
>> There's an unused parameter named is_root that is passed down to a 
>> number of MarkSweep/ParOld closures. This enhancement suggests that 
>> we remove it and cleanup the trails after it.
>>
>> thanks,
>> StefanK
>



From bengt.rutisson at oracle.com  Mon Apr 22 19:18:50 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 22 Apr 2013 21:18:50 +0200
Subject: Request for review(s) - 8012111: Remove warning about CMS
	generation shrinking.
In-Reply-To: <517567C2.4020206@oracle.com>
References: <51718FCC.9070207@oracle.com> <5174CBBC.5030101@oracle.com>
	<517567C2.4020206@oracle.com>
Message-ID: <51758D1A.8020502@oracle.com>


Hi Jon,

Sounds like you fixed it all. Thanks!

Ship it!
Bengt


On 4/22/13 6:39 PM, Jon Masamitsu wrote:
>
> On 4/21/13 10:33 PM, Bengt Rutisson wrote:
>>
>> Hi Jon,
>>
>> Looks good!
>>
>> A few minor nits in the JTreg test:
>>
>> - I think the "@test" line should have the test name in it. So, 
>> "@test GuardShrinkWarning".
> Fixed.
>>
>> - I don't think you need the "Go" parameter on line 45.
>
> Deleted.
>
>>
>> - Why do you need the loop in SystemGCCaller to do 50 System.gc() 
>> calls? I think the warning is printed for every GC, so one 
>> System.gc() call should be enough, right?
>
> I had thought that the call to System.gc() would return before the 
> concurrent
> collection finished but that's not the case.  I've removed the loop
>
>
>
>>
>> - Do you need the "garbage" that you create in SystemGCCaller? I also 
>> think you can drop the System.println(".") call.
>
> and I've removed the allocation of the array.
>
> Thanks.
>
> Jon
>>
>> Thanks,
>> Bengt
>>
>>
>> On 4/19/13 8:41 PM, Jon Masamitsu wrote:
>>> 8012111: Remove warning about CMS generation shrinking.
>>>
>>> The warning message
>>>
>>> "Java HotSpot(TM) Server VM warning: Shrinking of CMS not yet 
>>> implemented"
>>>
>>> should not generally be emitted.  Guard it with PrintGCDetails and 
>>> Verbose.
>>>
>>> http://cr.openjdk.java.net/~jmasa/8012111/webrev.00/
>>
>

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

From stefan.karlsson at oracle.com  Mon Apr 22 20:26:14 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Mon, 22 Apr 2013 20:26:14 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8012687: Remove unused is_root checks and
	closures
Message-ID: <20130422202618.9E803484F9@hg.openjdk.java.net>

Changeset: a08c80e9e1e5
Author:    stefank
Date:      2013-04-22 20:27 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a08c80e9e1e5

8012687: Remove unused is_root checks and closures
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_implementation/shared/markSweep.inline.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp



From mikael.gerdin at oracle.com  Tue Apr 23 06:31:16 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 23 Apr 2013 08:31:16 +0200
Subject: RFR (s): JDK-8011802 NPG: init_dependencies in class loader data
	graph can cause invalid CLD
In-Reply-To: <51757D53.5020502@oracle.com>
References: <51752F2F.3050800@oracle.com> <51757C60.3050201@oracle.com>
	<51757D53.5020502@oracle.com>
Message-ID: <51762AB4.90701@oracle.com>

Thanks Stefan and Coleen.

I'll go ahead and push this change.
Also, I forgot to mention that I tested this change with Nashorn's 
test262parallel.

/Mikael

On 2013-04-22 20:11, Coleen Phillimore wrote:
>
> I agree.  This does look good.
> Thanks,
> Coleen
>
> On 04/22/2013 02:07 PM, Stefan Karlsson wrote:
>> Looks good.
>>
>> StefanK
>>
>> On 2013-04-22 14:38, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> here is my suggested fix for the ClassLoaderData initialization issue
>>> that David brought up in the review thread for JDK-8010196.
>>>
>>> The problem:
>>> Upon initialization of a ClassLoaderData (from
>>> ClassLoaderDataGraph::add) the newly created CLD is added to the
>>> ClassLoderData linked list and to the hidden field in the
>>> java/lang/ClassLoader object before we call init_dependencies to
>>> create the Java object array.
>>> Since the creation of the object array can throw a Java Exception
>>> (OOME) we need to be able to clean up if that happens.
>>>
>>>
>>> The fix:
>>> Instead of trying to undo what we did when adding the CLD I suggest
>>> that we first try to init_dependencies and if that succeeds we
>>> proceed to try to add the CLD to the ClassLoader and the list.
>>> If two threads are simultaneously trying to create a CLD for a loader
>>> we will now allocate a few unnecessary object arrays since we
>>> allocate them optimistically but since we don't hang on to them they
>>> should not cause any memory overhead.
>>>
>>> I also took the liberty to change the way we signal that a CLD is for
>>> an anonymous class to use a boolean instead of passing a null value
>>> to the CLD** and moved all the code to write the CLD* into the
>>> ClassLoader to ClassLoaderDataGraph::add. The code motion is
>>> necessary since init_dependencies may trigger a GC and the CLD**
>>> which was passed in was in fact a raw pointer into the ClassLoader in
>>> the Java heap.
>>>
>>> Unfortunately I can't use CHECK_NULL when calling init_dependencies
>>> since I need to delete the cld before returning.
>>>
>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8011802/webrev.0/
>>>
>>> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011802
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011802
>>>
>>> /Mikael
>>
>


From jon.masamitsu at oracle.com  Tue Apr 23 08:02:07 2013
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Tue, 23 Apr 2013 08:02:07 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8012111: Remove warning about CMS
	generation shrinking.
Message-ID: <20130423080211.AF96F4850D@hg.openjdk.java.net>

Changeset: ebded0261dfc
Author:    jmasa
Date:      2013-04-22 22:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ebded0261dfc

8012111: Remove warning about CMS generation shrinking.
Reviewed-by: johnc, brutisso, stefank

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
+ test/gc/concurrentMarkSweep/GuardShrinkWarning.java



From lokesh.gidra at yahoo.com  Tue Apr 23 11:59:45 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Tue, 23 Apr 2013 19:59:45 +0800 (SGT)
Subject: Deadlock while running SPECjbb2013
Message-ID: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>

Hello,

I am trying to experiment SPECjbb2013 on a 48-core AMD machine with the following command line options on OpenJDK7 build 147:

-XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops

The execution hangs sometimes. When I attached the process to gdb, found that the GC threads are stuck in the marking phase of Old generation collection. The bug also hits with lesser GC threads. I am wondering if this is a known issue.

Regards,
Lokesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130423/7b41ce3e/attachment.htm>

From mikael.gerdin at oracle.com  Tue Apr 23 12:21:01 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Tue, 23 Apr 2013 12:21:01 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011802: NPG: init_dependencies in class
	loader data graph can cause invalid CLD
Message-ID: <20130423122119.F19C848513@hg.openjdk.java.net>

Changeset: 1cb4795305b9
Author:    mgerdin
Date:      2013-04-23 08:39 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cb4795305b9

8011802: NPG: init_dependencies in class loader data graph can cause invalid CLD
Summary: Restructure initialization of ClassLoaderData to not add a new instance if init_dependencies fail
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/classfile/classLoaderData.inline.hpp



From john.cuthbertson at oracle.com  Tue Apr 23 21:09:13 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Tue, 23 Apr 2013 21:09:13 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011724: G1: Stack allocate instances of
	HeapRegionRemSetIterator
Message-ID: <20130423210919.81AAD48536@hg.openjdk.java.net>

Changeset: 5c93c1f61226
Author:    johnc
Date:      2013-04-18 10:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5c93c1f61226

8011724: G1: Stack allocate instances of HeapRegionRemSetIterator
Summary: Stack allocate instances of HeapRegionRemSetIterator during RSet scanning.
Reviewed-by: brutisso, jwilhelm

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp



From tao.mao at oracle.com  Tue Apr 23 23:49:19 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 23 Apr 2013 16:49:19 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <1366624612.2774.12.camel@cirrus>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<5174EDA3.9000605@oracle.com> <1366624612.2774.12.camel@cirrus>
Message-ID: <51771DFF.5010507@oracle.com>

I think alignment is handled slightly differently in the two/three classes.

Tao

On 4/22/13 2:56 AM, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2013-04-22 at 09:58 +0200, Bengt Rutisson wrote:
>> Hi Tao,
>>
>> On 4/19/13 7:27 PM, Tao Mao wrote:
>>
>>> 1. check overflow routine is wrapped up.
>> I'm not sure we need round_up_total_reserved_and_check_overflow() since
>> it is only being used in one place.
> Actually it is an interesting question why only the total of
> GenCollectedHeaps is rounded up to large page size and the others are
> not.
>
> It seems that in parallel old, at these heap sizes, some code that
> calculates internal alignment would result in an alignment>  large page
> size, so it would be okay, i.e. overflow already when adding together
> the components.
>
> At least with G1 with a 1 MB region size there might be an issue as e.g.
> the perm gen size is rounded to heap region size. Or there is not an
> issue at all, but why then do the rounding only for GenCollectedHeaps?
>
> (I think the rounding can at most make the total overflow into a
> resulting zero. I am not sure if the heap reserve functions give an
> error if you pass a requested virtual space size of zero anyway...)
>
> Hth,
> Thomas
>
>


From tao.mao at oracle.com  Tue Apr 23 23:55:43 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 23 Apr 2013 16:55:43 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <5174EDA3.9000605@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<5174EDA3.9000605@oracle.com>
Message-ID: <51771F7F.9040307@oracle.com>

New webrev:
http://cr.openjdk.java.net/~tamao/6761744/webrev.03/

jtreg test passed.

See inline.

Thanks.
Tao

On 4/22/13 12:58 AM, Bengt Rutisson wrote:
>
> Hi Tao,
>
> On 4/19/13 7:27 PM, Tao Mao wrote:
>> 1. check overflow routine is wrapped up.
>
> I would prefer that the method 
> CollectedHeap::add_to_total_reserved_and_check_overflow() did not 
> return a bool. Since you do vm_exit_during_initialization() when you 
> overflow there is no need to return different results. This would also 
> simplify the code where you use it. No need to use if statements.
It's fine to remove the bool return type. Done.
>
> Also, I think you should remove the naming references to 
> "total_reserved" and "reserved". This method is general enough to just 
> add two size_t arguments together and check for overflow. Especially 
> if it would take the message as a parameter. Instead of returning a 
> bool you can return the result of the addition if there was no overflow.
I'd like not to make the method generic for (1) it's not an appropriate 
place to host such a generic add_to_and_check_overflow method; (2) 
Remember, the refactoring was originally suggested to reduce duplication 
of error message. Passing the error message gets back the flaw.
>
> I'm not sure we need round_up_total_reserved_and_check_overflow() 
> since it is only being used in one place.
The same reason: avoid a duplication of string definition of error message.
>
>>
>> 2. The reduction of code duplication is adopted.
>
> Good.
>
>>
>> 3. Develop a way to intake 0~multiple external vm options in jtreg 
>> main().
>
> Yes, this looks like it should work. However, based on John 
> Cuthbertson's discussion with Leonid I think you need to do the same 
> thing for test.java.opts too.
Followed the Leonid's latest suggestion.
>
> Bengt
>
>
>
>> Hope it helps others implement similar functionality.
>> webrev:
>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>
>> test:
>> JTREG: passed.
>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>> <GC_OPTION>" 
>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>
>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>
>>
>> Thanks.
>> Tao
>>
>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>
>>> Hi Tao,
>>>
>>> I agree with John. The changes look fine and I'm ok with them. But 
>>> it would look nicer to add the 
>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>
>>> Also, regarding the test, a couple of minor things.
>>>
>>> First, with the new naming convention I think the test should be 
>>> called something like:
>>>
>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>
>>> Then I think you can reduce the code duplication a bit. You create 
>>> the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit 
>>> cases. So maybe it could look like this instead:
>>>
>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>   public static void main(String args[]) throws Exception {
>>>     ProcessBuilder pb =
>>>       
>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>                                               "-Xmx3072m",
>>>                                               "-XX:MaxPermSize=1024m",
>>>                                               "-version");
>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>
>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>     if (dataModel.equals("32")) {
>>>       output.shouldContain("The size of the object heap + perm gen 
>>> exceeds the maximum representable size");
>>>       if (output.getExitValue() == 0) {
>>>         throw new RuntimeException("Not expected to get exit value 0");
>>>       }
>>>     } else if (dataModel.equals("64")) {
>>>       output.shouldHaveExitValue(0);
>>>     }
>>>   }
>>> }
>>>
>>> There is also a small bug in the test. If you run JTreg without 
>>> passing any vmoptions the test will fail. The reason is that 
>>> System.getProperty("test.vm.opts") will evaluate to the empty 
>>> string. This will be passed as the first argument to the Java 
>>> process, which will assume that this is the class name. So, it fails 
>>> to start because it can't load the class <empty string>.
>>>
>>> To reproduce the problem use this command line:
>>>
>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>
>>> I guess the fix is to check that System.getProperty("test.vm.opts") 
>>> is not empty before passing it on to createJavaProcessBuilder().
>>>
>>> Thanks,
>>> Bengt
>>>
>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>> Hi Tao,
>>>>
>>>> This looks OK to me.
>>>>
>>>> I can see what Thomas is saying though. All of the checks involve 
>>>> something like:
>>>>
>>>> total += some_value;
>>>> if (total < some_value) {
>>>>   // We must have overflowed
>>>>   vm_exit(...);
>>>> }
>>>>
>>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>>> ParallelScavengeHeap) might make sense. For example:
>>>>
>>>> total_reserved = 0;
>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>> max_heap_size);
>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>> max_perm_size);
>>>>
>>>> Where the function is:
>>>>
>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>   const char* msg = "...";
>>>>   x += y;
>>>>   if (x < y) {
>>>>     vm_exit(msg);
>>>>   }
>>>>   return x;
>>>> }
>>>>
>>>> But I can live with your current changes.
>>>>
>>>> JohnC
>>>>
>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>> Hi Bengt,
>>>>>
>>>>> Thank you for reviewing. A new webrev is updated.
>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>
>>>>> Cheers,
>>>>> Tao
>>>>>
>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Tao,
>>>>>>
>>>>>> This change looks good. Thanks for adding the JTReg test, it 
>>>>>> looks good!
>>>>>>
>>>>>> One minor nit:
>>>>>>
>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>>>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>>>> duplicating the calculation.
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>
>>>>>>> changeset:
>>>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>
>>>>>>> It provides for 32-bit builds a preventive check of the size of 
>>>>>>> "the object heap + perm gen" before reserving VM memory. The 
>>>>>>> total size should not exceed 4096MB (i.e. 4GB) for 32-bit 
>>>>>>> builds; otherwise, the total doesn't make sense and, what's 
>>>>>>> worse, overflow occurs. It will consequentially trigger anther 
>>>>>>> error of memory access violation, which was not protected.
>>>>>>>
>>>>>>> jtreg testing java code is also written, checking both 32-bit 
>>>>>>> and (trivially) 64-bit builds.
>>>>>>>
>>>>>>> testing:
>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>>>>> builds of 32-bit and 64-bit. All passed.
>>>>>>>
>>>>>>> Needs JPRT test when pushing.
>>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130423/4d86a87e/attachment.htm>

From john.cuthbertson at oracle.com  Wed Apr 24 00:15:57 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 23 Apr 2013 17:15:57 -0700
Subject: RFR(S): 8011898: gc/TestVerifyBeforeGCDuringStartup.java:
	java.lang.RuntimeException
Message-ID: <5177243D.9030006@oracle.com>

Hi Everyone,

Can I have a couple of volunteers review these changes to the regression 
test I added for 8010463 and changed for 8011343? The webrev can found 
at: http://cr.openjdk.java.net/~johnc/8011898/webrev.0/

Summary:
The call to System.getProperty("test.vm.opts") will return null if no 
additional vm or java options are passed into jtreg. Hence the first 
entry in the String array, that is passed to createJavaProcessBuilder(), 
is null. When the null is converted to options, the first option will be 
the empty string which the java launcher interprets as the name of the 
main class.

Many thanks to Bengt for his diagnosis.

Notes:

In this test I'm using the same mechanism as in Tao's test for 6761744. 
His is much nicer than what I came up with. Many tanks to Tao.

The test now reads the test.java.opts instead of test.vm.opts after 
feedback from SQE.

Also I added a couple of prints to test to make it easier to see what 
the command line of the child java process actually is and it's 
resulting output. In the .jtr file you see something like:

> ----------messages:(3/144)----------
> command: main TestVerifyDuringStartup
> reason: Assumed action based on file name: run main 
> TestVerifyDuringStartup
> elapsed time (seconds): 0.32
> ----------System.out:(8/408)----------
> Testing:
> /export/jdk8-1/solaris-x64/bin/java -XX:+UseG1GC -XX:-UseTLAB 
> -XX:+UnlockDiagnosticVMOptions -XX:+VerifyDuringStartup -version
> Output:
> [Verifying threads Roots HeapRegionSets HeapRegions RemSet syms strs 
> zone dict metaspace chunks hand C-heap code cache ]
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b58)
> Java HotSpot(TM) Server VM (build 25.0-b29-internal, mixed mode)
>
> ----------System.err:(1/15)----------
> STATUS:Passed.
> result: Passed. Execution successful

Thanks,

JohnC


From john.cuthbertson at oracle.com  Wed Apr 24 00:29:27 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 23 Apr 2013 17:29:27 -0700
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added to
	last mixed GC
Message-ID: <51772767.3040709@oracle.com>

Hi Everyone,

Can I have review of the backport of the fix for 800007036 to hsx24? One 
of the changes to g1CollectorPolicy.cpp did not apply cleanly because of 
the additional parameter to finalize_cset. There was actually no 
conflict in the change but importing the changeset rejected that 
particular chunk.

The webrev can be found at: 
http://cr.openjdk.java.net/~johnc/8007036-hsx24-backport/webrev.0/

Thanks,

JohnC


From jon.masamitsu at oracle.com  Wed Apr 24 05:10:18 2013
From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com)
Date: Wed, 24 Apr 2013 05:10:18 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8008966: NPG: Inefficient Metaspace
	counter functions cause large young GC regressions
Message-ID: <20130424051022.DA31548561@hg.openjdk.java.net>

Changeset: 868d87ed63c8
Author:    jmasa
Date:      2013-02-12 14:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/868d87ed63c8

8008966: NPG: Inefficient Metaspace counter functions cause large young GC regressions
Reviewed-by: mgerdin, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp
! src/share/vm/memory/metaspaceShared.cpp



From bengt.rutisson at oracle.com  Wed Apr 24 05:49:03 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 24 Apr 2013 07:49:03 +0200
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added
	to last mixed GC
In-Reply-To: <51772767.3040709@oracle.com>
References: <51772767.3040709@oracle.com>
Message-ID: <5177724F.7030804@oracle.com>


Hi John,

Looks good!

Since I reviewed the original change I only looked at the diff of the 
patches this time. As you said the only difference is that 
finalize_cset() now takes the evacuation_info parameter. I guess once 
the event tracing is integrated into 8 this code will look the same 
again in hsx24 and hsx25.

Bengt

On 4/24/13 2:29 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have review of the backport of the fix for 800007036 to hsx24? 
> One of the changes to g1CollectorPolicy.cpp did not apply cleanly 
> because of the additional parameter to finalize_cset. There was 
> actually no conflict in the change but importing the changeset 
> rejected that particular chunk.
>
> The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/8007036-hsx24-backport/webrev.0/
>
> Thanks,
>
> JohnC



From thomas.schatzl at oracle.com  Wed Apr 24 07:53:08 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 24 Apr 2013 09:53:08 +0200
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added
	to last mixed GC
In-Reply-To: <51772767.3040709@oracle.com>
References: <51772767.3040709@oracle.com>
Message-ID: <1366789988.2731.3.camel@cirrus>

Hi,

On Tue, 2013-04-23 at 17:29 -0700, John Cuthbertson wrote:
> Hi Everyone,
> 
> Can I have review of the backport of the fix for 800007036 to hsx24? One 
> of the changes to g1CollectorPolicy.cpp did not apply cleanly because of 
> the additional parameter to finalize_cset. There was actually no 
> conflict in the change but importing the changeset rejected that 
> particular chunk.
> 
> The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/8007036-hsx24-backport/webrev.0/

Looks good.

Thomas




From leonid.mesnik at oracle.com  Wed Apr 24 10:36:09 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Wed, 24 Apr 2013 14:36:09 +0400
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <51757C74.9000605@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com> <51757C74.9000605@oracle.com>
Message-ID: <5177B599.3050604@oracle.com>

On 04/22/2013 10:07 PM, Tao Mao wrote:
> This should be handled by a separate CR (probably by this CR 
> https://jbs.oracle.com/bugs/browse/JDK-7112912)
>
Why this? I mean should your test pass on hosts with *small* amount of 
memory.

Leonid
> Thanks.
> Tao
>
> On 4/22/13 2:46 AM, Leonid Mesnik wrote:
>> Tao
>>
>> This is not review, just question.
>>
>> Should you test pass on hosts with 512M-1GB memory and no swap?
>>
>> Leonid
>> On 04/19/2013 09:27 PM, Tao Mao wrote:
>>> 1. check overflow routine is wrapped up.
>>>
>>> 2. The reduction of code duplication is adopted.
>>>
>>> 3. Develop a way to intake 0~multiple external vm options in jtreg 
>>> main(). Hope it helps others implement similar functionality.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>>
>>> test:
>>> JTREG: passed.
>>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>>> <GC_OPTION>" 
>>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>
>>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>
>>>
>>> Thanks.
>>> Tao
>>>
>>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Tao,
>>>>
>>>> I agree with John. The changes look fine and I'm ok with them. But 
>>>> it would look nicer to add the 
>>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>>
>>>> Also, regarding the test, a couple of minor things.
>>>>
>>>> First, with the new naming convention I think the test should be 
>>>> called something like:
>>>>
>>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>
>>>> Then I think you can reduce the code duplication a bit. You create 
>>>> the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit 
>>>> cases. So maybe it could look like this instead:
>>>>
>>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>>   public static void main(String args[]) throws Exception {
>>>>     ProcessBuilder pb =
>>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>> "-Xmx3072m",
>>>> "-XX:MaxPermSize=1024m",
>>>> "-version");
>>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>
>>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>>     if (dataModel.equals("32")) {
>>>>       output.shouldContain("The size of the object heap + perm gen 
>>>> exceeds the maximum representable size");
>>>>       if (output.getExitValue() == 0) {
>>>>         throw new RuntimeException("Not expected to get exit value 0");
>>>>       }
>>>>     } else if (dataModel.equals("64")) {
>>>>       output.shouldHaveExitValue(0);
>>>>     }
>>>>   }
>>>> }
>>>>
>>>> There is also a small bug in the test. If you run JTreg without 
>>>> passing any vmoptions the test will fail. The reason is that 
>>>> System.getProperty("test.vm.opts") will evaluate to the empty 
>>>> string. This will be passed as the first argument to the Java 
>>>> process, which will assume that this is the class name. So, it 
>>>> fails to start because it can't load the class <empty string>.
>>>>
>>>> To reproduce the problem use this command line:
>>>>
>>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>
>>>> I guess the fix is to check that System.getProperty("test.vm.opts") 
>>>> is not empty before passing it on to createJavaProcessBuilder().
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>>> Hi Tao,
>>>>>
>>>>> This looks OK to me.
>>>>>
>>>>> I can see what Thomas is saying though. All of the checks involve 
>>>>> something like:
>>>>>
>>>>> total += some_value;
>>>>> if (total < some_value) {
>>>>>   // We must have overflowed
>>>>>   vm_exit(...);
>>>>> }
>>>>>
>>>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>>>> ParallelScavengeHeap) might make sense. For example:
>>>>>
>>>>> total_reserved = 0;
>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>> max_heap_size);
>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>> max_perm_size);
>>>>>
>>>>> Where the function is:
>>>>>
>>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>>   const char* msg = "...";
>>>>>   x += y;
>>>>>   if (x < y) {
>>>>>     vm_exit(msg);
>>>>>   }
>>>>>   return x;
>>>>> }
>>>>>
>>>>> But I can live with your current changes.
>>>>>
>>>>> JohnC
>>>>>
>>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>>> Hi Bengt,
>>>>>>
>>>>>> Thank you for reviewing. A new webrev is updated.
>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>>
>>>>>> Cheers,
>>>>>> Tao
>>>>>>
>>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>>
>>>>>>> Hi Tao,
>>>>>>>
>>>>>>> This change looks good. Thanks for adding the JTReg test, it 
>>>>>>> looks good!
>>>>>>>
>>>>>>> One minor nit:
>>>>>>>
>>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would 
>>>>>>> suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>>>>> duplicating the calculation.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bengt
>>>>>>>
>>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>>
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>>
>>>>>>>> changeset:
>>>>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>>
>>>>>>>> It provides for 32-bit builds a preventive check of the size of 
>>>>>>>> "the object heap + perm gen" before reserving VM memory. The 
>>>>>>>> total size should not exceed 4096MB (i.e. 4GB) for 32-bit 
>>>>>>>> builds; otherwise, the total doesn't make sense and, what's 
>>>>>>>> worse, overflow occurs. It will consequentially trigger anther 
>>>>>>>> error of memory access violation, which was not protected.
>>>>>>>>
>>>>>>>> jtreg testing java code is also written, checking both 32-bit 
>>>>>>>> and (trivially) 64-bit builds.
>>>>>>>>
>>>>>>>> testing:
>>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and 
>>>>>>>> builds of 32-bit and 64-bit. All passed.
>>>>>>>>
>>>>>>>> Needs JPRT test when pushing.
>>>>>>>
>>>>>
>>>>
>>
>>
>> -- 
>> Leonid Mesnik
>> JVM SQE


-- 
Leonid Mesnik
JVM SQE

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

From jon.masamitsu at oracle.com  Wed Apr 24 14:16:00 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 24 Apr 2013 07:16:00 -0700
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
Message-ID: <5177E920.2010207@oracle.com>

I don't think we've seen this.  What OS?

I can create a bug report for this.  Please send the info needed to
reproduce it.

Thanks.

Jon

On 4/23/13 4:59 AM, Lokesh Gidra wrote:
> Hello,
>
> I am trying to experiment SPECjbb2013 on a 48-core AMD machine with 
> the following command line options on OpenJDK7 build 147:
>
> -XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC 
> -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>
> The execution hangs sometimes. When I attached the process to gdb, 
> found that the GC threads are stuck in the marking phase of Old 
> generation collection. The bug also hits with lesser GC threads. I am 
> wondering if this is a known issue.
>
> Regards,
> Lokesh

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

From jon.masamitsu at oracle.com  Wed Apr 24 14:26:10 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 24 Apr 2013 07:26:10 -0700
Subject: RFR(S): 8011898: gc/TestVerifyBeforeGCDuringStartup.java:
	java.lang.RuntimeException
In-Reply-To: <5177243D.9030006@oracle.com>
References: <5177243D.9030006@oracle.com>
Message-ID: <5177EB82.3060406@oracle.com>

Looks good.

Jon

On 4/23/13 5:15 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review these changes to the 
> regression test I added for 8010463 and changed for 8011343? The 
> webrev can found at: http://cr.openjdk.java.net/~johnc/8011898/webrev.0/
>
> Summary:
> The call to System.getProperty("test.vm.opts") will return null if no 
> additional vm or java options are passed into jtreg. Hence the first 
> entry in the String array, that is passed to 
> createJavaProcessBuilder(), is null. When the null is converted to 
> options, the first option will be the empty string which the java 
> launcher interprets as the name of the main class.
>
> Many thanks to Bengt for his diagnosis.
>
> Notes:
>
> In this test I'm using the same mechanism as in Tao's test for 
> 6761744. His is much nicer than what I came up with. Many tanks to Tao.
>
> The test now reads the test.java.opts instead of test.vm.opts after 
> feedback from SQE.
>
> Also I added a couple of prints to test to make it easier to see what 
> the command line of the child java process actually is and it's 
> resulting output. In the .jtr file you see something like:
>
>> ----------messages:(3/144)----------
>> command: main TestVerifyDuringStartup
>> reason: Assumed action based on file name: run main 
>> TestVerifyDuringStartup
>> elapsed time (seconds): 0.32
>> ----------System.out:(8/408)----------
>> Testing:
>> /export/jdk8-1/solaris-x64/bin/java -XX:+UseG1GC -XX:-UseTLAB 
>> -XX:+UnlockDiagnosticVMOptions -XX:+VerifyDuringStartup -version
>> Output:
>> [Verifying threads Roots HeapRegionSets HeapRegions RemSet syms strs 
>> zone dict metaspace chunks hand C-heap code cache ]
>> java version "1.8.0-ea"
>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b58)
>> Java HotSpot(TM) Server VM (build 25.0-b29-internal, mixed mode)
>>
>> ----------System.err:(1/15)----------
>> STATUS:Passed.
>> result: Passed. Execution successful
>
> Thanks,
>
> JohnC



From jon.masamitsu at oracle.com  Wed Apr 24 14:43:06 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 24 Apr 2013 07:43:06 -0700
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added
	to last mixed GC
In-Reply-To: <51772767.3040709@oracle.com>
References: <51772767.3040709@oracle.com>
Message-ID: <5177EF7A.6050202@oracle.com>

Looks good.

Jon

On 4/23/13 5:29 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have review of the backport of the fix for 800007036 to hsx24? 
> One of the changes to g1CollectorPolicy.cpp did not apply cleanly 
> because of the additional parameter to finalize_cset. There was 
> actually no conflict in the change but importing the changeset 
> rejected that particular chunk.
>
> The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/8007036-hsx24-backport/webrev.0/
>
> Thanks,
>
> JohnC



From mikael.gerdin at oracle.com  Wed Apr 24 15:03:07 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 24 Apr 2013 17:03:07 +0200
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <5177E920.2010207@oracle.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
	<5177E920.2010207@oracle.com>
Message-ID: <5177F42B.9050405@oracle.com>

It would also be a good idea to try with a more recent version of he 
JDK. A lot of bugs have been fixed since JDK7 GA (which is b147).

/Mikael

On 04/24/2013 04:16 PM, Jon Masamitsu wrote:
> I don't think we've seen this.  What OS?
>
> I can create a bug report for this.  Please send the info needed to
> reproduce it.
>
> Thanks.
>
> Jon
>
> On 4/23/13 4:59 AM, Lokesh Gidra wrote:
>> Hello,
>>
>> I am trying to experiment SPECjbb2013 on a 48-core AMD machine with
>> the following command line options on OpenJDK7 build 147:
>>
>> -XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC
>> -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>>
>> The execution hangs sometimes. When I attached the process to gdb,
>> found that the GC threads are stuck in the marking phase of Old
>> generation collection. The bug also hits with lesser GC threads. I am
>> wondering if this is a known issue.
>>
>> Regards,
>> Lokesh
>



From lokesh.gidra at yahoo.com  Wed Apr 24 15:07:46 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Wed, 24 Apr 2013 23:07:46 +0800 (SGT)
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <5177E920.2010207@oracle.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
	<5177E920.2010207@oracle.com>
Message-ID: <1366816066.41796.YahooMailNeo@web190903.mail.sg3.yahoo.com>

Its on Linux 3.0.0

It also causes out of memory at the given configuration, whereas I have successfully managed to complete the test with 4G heap. So not really sure what is causing these deadlocks/OOMs.

Lokesh


>________________________________
> From: Jon Masamitsu <jon.masamitsu at oracle.com>
>To: hotspot-gc-dev at openjdk.java.net 
>Sent: Wednesday, 24 April 2013 4:16 PM
>Subject: Re: Deadlock while running SPECjbb2013
> 
>
>
>I don't think we've seen this.? What OS?
>
>I can create a bug report for this.? Please send the info needed to
>reproduce it.
>
>Thanks.
>
>Jon
>
>
>On 4/23/13 4:59 AM, Lokesh Gidra wrote:
>
>Hello,
>>
>>
>>I am trying to experiment SPECjbb2013 on a 48-core AMD machine with the following command line options on OpenJDK7 build 147:
>>
>>
>>-XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>>
>>
>>The execution hangs sometimes. When I attached the process to gdb, found that the GC threads are stuck in the marking phase of Old generation collection. The bug also hits with lesser GC threads. I am wondering if this is a known issue.
>>
>>
>>Regards,
>>Lokesh
>
>
>


From lokesh.gidra at yahoo.com  Wed Apr 24 15:31:57 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Wed, 24 Apr 2013 23:31:57 +0800 (SGT)
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <5177F42B.9050405@oracle.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
	<5177E920.2010207@oracle.com> <5177F42B.9050405@oracle.com>
Message-ID: <1366817517.22254.YahooMailNeo@web190901.mail.sg3.yahoo.com>

I have tried it with the murcurial head of OpenJDK7u as well. Its the same.

Lokesh




----- Original Message -----
> From: Mikael Gerdin <mikael.gerdin at oracle.com>
> To: Jon Masamitsu <jon.masamitsu at oracle.com>
> Cc: hotspot-gc-dev at openjdk.java.net
> Sent: Wednesday, 24 April 2013 5:03 PM
> Subject: Re: Deadlock while running SPECjbb2013
> 
> It would also be a good idea to try with a more recent version of he 
> JDK. A lot of bugs have been fixed since JDK7 GA (which is b147).
> 
> /Mikael
> 
> On 04/24/2013 04:16 PM, Jon Masamitsu wrote:
>>  I don't think we've seen this.? What OS?
>> 
>>  I can create a bug report for this.? Please send the info needed to
>>  reproduce it.
>> 
>>  Thanks.
>> 
>>  Jon
>> 
>>  On 4/23/13 4:59 AM, Lokesh Gidra wrote:
>>>  Hello,
>>> 
>>>  I am trying to experiment SPECjbb2013 on a 48-core AMD machine with
>>>  the following command line options on OpenJDK7 build 147:
>>> 
>>>  -XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC
>>>  -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>>> 
>>>  The execution hangs sometimes. When I attached the process to gdb,
>>>  found that the GC threads are stuck in the marking phase of Old
>>>  generation collection. The bug also hits with lesser GC threads. I am
>>>  wondering if this is a known issue.
>>> 
>>>  Regards,
>>>  Lokesh
>> 
> 


From mikael.gerdin at oracle.com  Wed Apr 24 16:01:28 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 24 Apr 2013 18:01:28 +0200
Subject: RFR (s): JDK-8013136 NPG: Parallel class loading tests fail after
	fix for JDK-8011802
Message-ID: <517801D8.7000603@oracle.com>

Hi,
here we go again...

Problem:
My attempt at fixing JDK-8011802 was flawed since the ClassLoaderData 
constructor saves the raw class loader oop.
Since my fix called init_dependencies() after constructing the 
ClassLoaderData the j.l.ClassLoader may have moved and we would crash 
later on when trying to look at the _class_loader field.

Suggested fix:
I suggest that we move the initialization of the Dependencies object to 
before we create the ClassLoaderData and pass the Dependencies object by 
value to the ClassLoaderData constructor (it only contains one pointer 
so there should be no additional overhead in this copy).

This way we also get rid of the need to delete the CLD if we got an 
exception allocating the Dependencies.

I moved the No_Safepoint_Verifier to before we allocate the 
ClassLoaderData so that it protects the _class_loader oop as well.

Since we no longer need an explicit initialization of dependencies in 
the general case I added some assertions to init_dependencies() since 
it's only needed for the boot class loader now.

I also took the liberty to remove the left-over
"if (cld_addr != NULL)" check since that was used to determine if we 
were dealing with a CLD for an anonymous class. Since the check for 
is_anonymous is right before this and we only read the cld_addr we are 
dealing with a normal class loader the check is unnecessary.

Webrev: http://cr.openjdk.java.net/~mgerdin/8013136/webrev.0/
jbs: https://jbs.oracle.com/bugs/browse/JDK-8013136
bugs.sun.com (bug not visible yet): 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013136

Testing:
nashorn test262parallel and parallel class loading tests

/Mikael


From stefan.karlsson at oracle.com  Wed Apr 24 16:12:00 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 24 Apr 2013 18:12:00 +0200
Subject: RFR (s): JDK-8013136 NPG: Parallel class loading tests fail after
	fix for JDK-8011802
In-Reply-To: <517801D8.7000603@oracle.com>
References: <517801D8.7000603@oracle.com>
Message-ID: <51780450.4090600@oracle.com>

On 4/24/13 6:01 PM, Mikael Gerdin wrote:
> Hi,
> here we go again...
>
> Problem:
> My attempt at fixing JDK-8011802 was flawed since the ClassLoaderData 
> constructor saves the raw class loader oop.
> Since my fix called init_dependencies() after constructing the 
> ClassLoaderData the j.l.ClassLoader may have moved and we would crash 
> later on when trying to look at the _class_loader field.
>
> Suggested fix:
> I suggest that we move the initialization of the Dependencies object 
> to before we create the ClassLoaderData and pass the Dependencies 
> object by value to the ClassLoaderData constructor (it only contains 
> one pointer so there should be no additional overhead in this copy).
>
> This way we also get rid of the need to delete the CLD if we got an 
> exception allocating the Dependencies.
>
> I moved the No_Safepoint_Verifier to before we allocate the 
> ClassLoaderData so that it protects the _class_loader oop as well.
>
> Since we no longer need an explicit initialization of dependencies in 
> the general case I added some assertions to init_dependencies() since 
> it's only needed for the boot class loader now.
>
> I also took the liberty to remove the left-over
> "if (cld_addr != NULL)" check since that was used to determine if we 
> were dealing with a CLD for an anonymous class. Since the check for 
> is_anonymous is right before this and we only read the cld_addr we are 
> dealing with a normal class loader the check is unnecessary.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8013136/webrev.0/

Looks good to me.

StefanK

>
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8013136
> bugs.sun.com (bug not visible yet): 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013136
>
> Testing:
> nashorn test262parallel and parallel class loading tests
>
> /Mikael



From jon.masamitsu at oracle.com  Wed Apr 24 16:28:04 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 24 Apr 2013 09:28:04 -0700
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <1366816066.41796.YahooMailNeo@web190903.mail.sg3.yahoo.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
	<5177E920.2010207@oracle.com>
	<1366816066.41796.YahooMailNeo@web190903.mail.sg3.yahoo.com>
Message-ID: <51780814.2020704@oracle.com>


On 4/24/13 8:07 AM, Lokesh Gidra wrote:
> Its on Linux 3.0.0
>
> It also causes out of memory at the given configuration, whereas I have successfully managed to complete the test with 4G heap. So not really sure what is causing these deadlocks/OOMs.

Can you send stacktraces of all the threads?

Jon
>
> Lokesh
>
>
>> ________________________________
>> From: Jon Masamitsu <jon.masamitsu at oracle.com>
>> To: hotspot-gc-dev at openjdk.java.net
>> Sent: Wednesday, 24 April 2013 4:16 PM
>> Subject: Re: Deadlock while running SPECjbb2013
>>
>>
>>
>> I don't think we've seen this.  What OS?
>>
>> I can create a bug report for this.  Please send the info needed to
>> reproduce it.
>>
>> Thanks.
>>
>> Jon
>>
>>
>> On 4/23/13 4:59 AM, Lokesh Gidra wrote:
>>
>> Hello,
>>>
>>> I am trying to experiment SPECjbb2013 on a 48-core AMD machine with the following command line options on OpenJDK7 build 147:
>>>
>>>
>>> -XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>>>
>>>
>>> The execution hangs sometimes. When I attached the process to gdb, found that the GC threads are stuck in the marking phase of Old generation collection. The bug also hits with lesser GC threads. I am wondering if this is a known issue.
>>>
>>>
>>> Regards,
>>> Lokesh
>>
>>



From coleen.phillimore at oracle.com  Wed Apr 24 16:38:01 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 24 Apr 2013 12:38:01 -0400
Subject: RFR (s): JDK-8013136 NPG: Parallel class loading tests fail after
	fix for JDK-8011802
In-Reply-To: <517801D8.7000603@oracle.com>
References: <517801D8.7000603@oracle.com>
Message-ID: <51780A69.1020309@oracle.com>


The copy constructor of dependencies into the ClassLoaderData 
constructor looks odd to me but it's correct.  I did review this better 
this time and it looks good.

Thanks,
Coleen

On 4/24/2013 12:01 PM, Mikael Gerdin wrote:
> Hi,
> here we go again...
>
> Problem:
> My attempt at fixing JDK-8011802 was flawed since the ClassLoaderData 
> constructor saves the raw class loader oop.
> Since my fix called init_dependencies() after constructing the 
> ClassLoaderData the j.l.ClassLoader may have moved and we would crash 
> later on when trying to look at the _class_loader field.
>
> Suggested fix:
> I suggest that we move the initialization of the Dependencies object 
> to before we create the ClassLoaderData and pass the Dependencies 
> object by value to the ClassLoaderData constructor (it only contains 
> one pointer so there should be no additional overhead in this copy).
>
> This way we also get rid of the need to delete the CLD if we got an 
> exception allocating the Dependencies.
>
> I moved the No_Safepoint_Verifier to before we allocate the 
> ClassLoaderData so that it protects the _class_loader oop as well.
>
> Since we no longer need an explicit initialization of dependencies in 
> the general case I added some assertions to init_dependencies() since 
> it's only needed for the boot class loader now.
>
> I also took the liberty to remove the left-over
> "if (cld_addr != NULL)" check since that was used to determine if we 
> were dealing with a CLD for an anonymous class. Since the check for 
> is_anonymous is right before this and we only read the cld_addr we are 
> dealing with a normal class loader the check is unnecessary.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8013136/webrev.0/
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8013136
> bugs.sun.com (bug not visible yet): 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013136
>
> Testing:
> nashorn test262parallel and parallel class loading tests
>
> /Mikael



From jon.masamitsu at oracle.com  Wed Apr 24 16:55:16 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 24 Apr 2013 09:55:16 -0700
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <1366816066.41796.YahooMailNeo@web190903.mail.sg3.yahoo.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
	<5177E920.2010207@oracle.com>
	<1366816066.41796.YahooMailNeo@web190903.mail.sg3.yahoo.com>
Message-ID: <51780E74.6020300@oracle.com>


On 4/24/13 8:07 AM, Lokesh Gidra wrote:
> Its on Linux 3.0.0
>
> It also causes out of memory at the given configuration, whereas I have successfully managed to complete the test with 4G heap. So not really sure what is causing these deadlocks/OOMs.

What cause is given for the OOM?  And when you say deadlock,
are all the threads waiting?  Or are there threads that are
working but never finish their task?

Jon
>
> Lokesh
>
>
>> ________________________________
>> From: Jon Masamitsu <jon.masamitsu at oracle.com>
>> To: hotspot-gc-dev at openjdk.java.net
>> Sent: Wednesday, 24 April 2013 4:16 PM
>> Subject: Re: Deadlock while running SPECjbb2013
>>
>>
>>
>> I don't think we've seen this.  What OS?
>>
>> I can create a bug report for this.  Please send the info needed to
>> reproduce it.
>>
>> Thanks.
>>
>> Jon
>>
>>
>> On 4/23/13 4:59 AM, Lokesh Gidra wrote:
>>
>> Hello,
>>>
>>> I am trying to experiment SPECjbb2013 on a 48-core AMD machine with the following command line options on OpenJDK7 build 147:
>>>
>>>
>>> -XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>>>
>>>
>>> The execution hangs sometimes. When I attached the process to gdb, found that the GC threads are stuck in the marking phase of Old generation collection. The bug also hits with lesser GC threads. I am wondering if this is a known issue.
>>>
>>>
>>> Regards,
>>> Lokesh
>>
>>



From mikael.gerdin at oracle.com  Wed Apr 24 18:00:55 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 24 Apr 2013 20:00:55 +0200
Subject: RFR (s): JDK-8013136 NPG: Parallel class loading tests fail after
	fix for JDK-8011802
In-Reply-To: <51780A69.1020309@oracle.com>
References: <517801D8.7000603@oracle.com> <51780A69.1020309@oracle.com>
Message-ID: <51781DD7.6000900@oracle.com>

Thanks Stefan and Coleen for reviewing.

I'm going to push this right away to fix all the failures in the nightly 
testing.

/Mikael

On 04/24/2013 06:38 PM, Coleen Phillimore wrote:
>
> The copy constructor of dependencies into the ClassLoaderData
> constructor looks odd to me but it's correct.  I did review this better
> this time and it looks good.
>
> Thanks,
> Coleen
>
> On 4/24/2013 12:01 PM, Mikael Gerdin wrote:
>> Hi,
>> here we go again...
>>
>> Problem:
>> My attempt at fixing JDK-8011802 was flawed since the ClassLoaderData
>> constructor saves the raw class loader oop.
>> Since my fix called init_dependencies() after constructing the
>> ClassLoaderData the j.l.ClassLoader may have moved and we would crash
>> later on when trying to look at the _class_loader field.
>>
>> Suggested fix:
>> I suggest that we move the initialization of the Dependencies object
>> to before we create the ClassLoaderData and pass the Dependencies
>> object by value to the ClassLoaderData constructor (it only contains
>> one pointer so there should be no additional overhead in this copy).
>>
>> This way we also get rid of the need to delete the CLD if we got an
>> exception allocating the Dependencies.
>>
>> I moved the No_Safepoint_Verifier to before we allocate the
>> ClassLoaderData so that it protects the _class_loader oop as well.
>>
>> Since we no longer need an explicit initialization of dependencies in
>> the general case I added some assertions to init_dependencies() since
>> it's only needed for the boot class loader now.
>>
>> I also took the liberty to remove the left-over
>> "if (cld_addr != NULL)" check since that was used to determine if we
>> were dealing with a CLD for an anonymous class. Since the check for
>> is_anonymous is right before this and we only read the cld_addr we are
>> dealing with a normal class loader the check is unnecessary.
>>
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013136/webrev.0/
>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8013136
>> bugs.sun.com (bug not visible yet):
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013136
>>
>> Testing:
>> nashorn test262parallel and parallel class loading tests
>>
>> /Mikael
>



From stefan.karlsson at oracle.com  Wed Apr 24 18:12:14 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 24 Apr 2013 20:12:14 +0200
Subject: Review request: 8013132: Add a flag to turn off the output of the
	verbose verification code
Message-ID: <5178207E.1080209@oracle.com>

http://cr.openjdk.java.net/~stefank/8013132/webrev.00/

This RFE adds a new flag named VerifySilently, which can be used to turn 
off the verbose output that the verification code produces. The proposed 
name has been chosen to match other Verify flags.

 From the Bug description:
---
The HotSpot verification code is rather verbose and intrusive. I propose 
that we add a flag that can be used to turn this output off.

An example of the verification output:
$ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions -XX:+VerifyBeforeExit 
-XX:+VerifyAfterGC -XX:+VerifyBeforeGC -XX:+UseConcMarkSweepGC 
-XX:+ExplicitGCInvokesConcurrent -cp /localhome/tests/ HelloSystemGC
  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
generation par new generation remset syms strs zone dict cldg metaspace 
chunks hand C-heap code cache ]
[GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep generation 
par new generation remset syms strs zone dict cldg metaspace chunks hand 
C-heap code cache ]
[Verifying threads heap concurrent mark-sweep generation par new 
generation remset syms strs zone dict cldg metaspace chunks hand C-heap 
code cache ]
[GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
[Verifying threads heap concurrent mark-sweep generation par new 
generation remset syms strs zone dict cldg metaspace chunks hand C-heap 
code cache ]
[Verifying threads heap concurrent mark-sweep generation par new 
generation remset syms strs zone dict cldg metaspace chunks hand C-heap 
code cache ]
[GC (CMS Final Remark) [Verifying CMS Marking... done] 1604K(121600K), 
0.1008210 secs]
[Verifying threads heap concurrent mark-sweep generation par new 
generation remset syms strs zone dict cldg metaspace chunks hand C-heap 
code cache ]

And with the proposed flag turned on:
[GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
[GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
[GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
---

thanks,
StefanK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130424/96b72860/attachment.htm>

From tao.mao at oracle.com  Wed Apr 24 18:35:00 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Wed, 24 Apr 2013 11:35:00 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <5177B599.3050604@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com> <51757C74.9000605@oracle.com>
	<5177B599.3050604@oracle.com>
Message-ID: <517825D4.4020505@oracle.com>

For 32-bit builds: The current changeset provides the first "protection" 
of heap size handling. Then comes handling whether we can allocate a 
certain amount of a heap.

For 64-bit builds: a machine with 512M-1GB memory should fail in many 
other tests as well, due to inability to lauch jvm.

Anyway, I ran the test and it passed.

--------------------------------------------------
Simply,

-bash-4.1$ ulimit -v 134217728 (128m for human reading)
-bash-4.1$ ulimit -m 134217728 (128m FHR)

(cannot limit virtual memory to zero or set vm.swappiness=0, in which 
case the server would hang immediately w/o even launching jvm. But, the 
setting should satisfy your question.)

Then, run jtreg. Then, pass.
--------------------------------------------------

BTW, since you've jumped in this thread ^_^ can you check the way I get 
system property through "test.java.opts" to set inside jvm process? It's 
in test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java

Thank you.
Tao

On 4/24/13 3:36 AM, Leonid Mesnik wrote:
> On 04/22/2013 10:07 PM, Tao Mao wrote:
>> This should be handled by a separate CR (probably by this CR 
>> https://jbs.oracle.com/bugs/browse/JDK-7112912)
>>
> Why this? I mean should your test pass on hosts with *small* amount of 
> memory.
>
> Leonid
>> Thanks.
>> Tao
>>
>> On 4/22/13 2:46 AM, Leonid Mesnik wrote:
>>> Tao
>>>
>>> This is not review, just question.
>>>
>>> Should you test pass on hosts with 512M-1GB memory and no swap?
>>>
>>> Leonid
>>> On 04/19/2013 09:27 PM, Tao Mao wrote:
>>>> 1. check overflow routine is wrapped up.
>>>>
>>>> 2. The reduction of code duplication is adopted.
>>>>
>>>> 3. Develop a way to intake 0~multiple external vm options in jtreg 
>>>> main(). Hope it helps others implement similar functionality.
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>>>
>>>> test:
>>>> JTREG: passed.
>>>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>>>> <GC_OPTION>" 
>>>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>>
>>>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>>>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>
>>>>
>>>> Thanks.
>>>> Tao
>>>>
>>>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>>>
>>>>> Hi Tao,
>>>>>
>>>>> I agree with John. The changes look fine and I'm ok with them. But 
>>>>> it would look nicer to add the 
>>>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>>>
>>>>> Also, regarding the test, a couple of minor things.
>>>>>
>>>>> First, with the new naming convention I think the test should be 
>>>>> called something like:
>>>>>
>>>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>
>>>>> Then I think you can reduce the code duplication a bit. You create 
>>>>> the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit 
>>>>> cases. So maybe it could look like this instead:
>>>>>
>>>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>>>   public static void main(String args[]) throws Exception {
>>>>>     ProcessBuilder pb =
>>>>>       
>>>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>>>                                               "-Xmx3072m",
>>>>>                                               "-XX:MaxPermSize=1024m",
>>>>>                                               "-version");
>>>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>>
>>>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>>>     if (dataModel.equals("32")) {
>>>>>       output.shouldContain("The size of the object heap + perm gen 
>>>>> exceeds the maximum representable size");
>>>>>       if (output.getExitValue() == 0) {
>>>>>         throw new RuntimeException("Not expected to get exit value 
>>>>> 0");
>>>>>       }
>>>>>     } else if (dataModel.equals("64")) {
>>>>>       output.shouldHaveExitValue(0);
>>>>>     }
>>>>>   }
>>>>> }
>>>>>
>>>>> There is also a small bug in the test. If you run JTreg without 
>>>>> passing any vmoptions the test will fail. The reason is that 
>>>>> System.getProperty("test.vm.opts") will evaluate to the empty 
>>>>> string. This will be passed as the first argument to the Java 
>>>>> process, which will assume that this is the class name. So, it 
>>>>> fails to start because it can't load the class <empty string>.
>>>>>
>>>>> To reproduce the problem use this command line:
>>>>>
>>>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>
>>>>> I guess the fix is to check that 
>>>>> System.getProperty("test.vm.opts") is not empty before passing it 
>>>>> on to createJavaProcessBuilder().
>>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>>>> Hi Tao,
>>>>>>
>>>>>> This looks OK to me.
>>>>>>
>>>>>> I can see what Thomas is saying though. All of the checks involve 
>>>>>> something like:
>>>>>>
>>>>>> total += some_value;
>>>>>> if (total < some_value) {
>>>>>>   // We must have overflowed
>>>>>>   vm_exit(...);
>>>>>> }
>>>>>>
>>>>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>>>>> ParallelScavengeHeap) might make sense. For example:
>>>>>>
>>>>>> total_reserved = 0;
>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>> max_heap_size);
>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>> max_perm_size);
>>>>>>
>>>>>> Where the function is:
>>>>>>
>>>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>>>   const char* msg = "...";
>>>>>>   x += y;
>>>>>>   if (x < y) {
>>>>>>     vm_exit(msg);
>>>>>>   }
>>>>>>   return x;
>>>>>> }
>>>>>>
>>>>>> But I can live with your current changes.
>>>>>>
>>>>>> JohnC
>>>>>>
>>>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>>>> Hi Bengt,
>>>>>>>
>>>>>>> Thank you for reviewing. A new webrev is updated.
>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Tao
>>>>>>>
>>>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>>>
>>>>>>>> Hi Tao,
>>>>>>>>
>>>>>>>> This change looks good. Thanks for adding the JTReg test, it 
>>>>>>>> looks good!
>>>>>>>>
>>>>>>>> One minor nit:
>>>>>>>>
>>>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I 
>>>>>>>> would suggest to store "(size_t) align_size_up(pgs->max_size(), 
>>>>>>>> HeapRegion::GrainBytes)" in a local variable rather than 
>>>>>>>> duplicating the calculation.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Bengt
>>>>>>>>
>>>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>>>
>>>>>>>>> webrev:
>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>>>
>>>>>>>>> changeset:
>>>>>>>>> The fix only needs to go to hsx24 since there's no perm gen in 
>>>>>>>>> hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>>>
>>>>>>>>> It provides for 32-bit builds a preventive check of the size 
>>>>>>>>> of "the object heap + perm gen" before reserving VM memory. 
>>>>>>>>> The total size should not exceed 4096MB (i.e. 4GB) for 32-bit 
>>>>>>>>> builds; otherwise, the total doesn't make sense and, what's 
>>>>>>>>> worse, overflow occurs. It will consequentially trigger anther 
>>>>>>>>> error of memory access violation, which was not protected.
>>>>>>>>>
>>>>>>>>> jtreg testing java code is also written, checking both 32-bit 
>>>>>>>>> and (trivially) 64-bit builds.
>>>>>>>>>
>>>>>>>>> testing:
>>>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, 
>>>>>>>>> -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC 
>>>>>>>>> and builds of 32-bit and 64-bit. All passed.
>>>>>>>>>
>>>>>>>>> Needs JPRT test when pushing.
>>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>> -- 
>>> Leonid Mesnik
>>> JVM SQE
>
>
> -- 
> Leonid Mesnik
> JVM SQE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130424/79a3bca3/attachment.htm>

From mikael.gerdin at oracle.com  Wed Apr 24 19:37:02 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Wed, 24 Apr 2013 19:37:02 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8013136: NPG: Parallel class loading
	tests fail after fix for JDK-8011802
Message-ID: <20130424193708.5096148592@hg.openjdk.java.net>

Changeset: 9d75bcd7c890
Author:    mgerdin
Date:      2013-04-24 19:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9d75bcd7c890

8013136: NPG: Parallel class loading tests fail after fix for JDK-8011802
Summary: Move initialization of dependencies to before allocation of CLD
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp



From stefan.karlsson at oracle.com  Wed Apr 24 20:18:21 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 24 Apr 2013 22:18:21 +0200
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack draining
	after CodeCache::do_unloading
Message-ID: <51783E0D.5080408@oracle.com>

http://cr.openjdk.java.net/~stefank/8013160/webrev.00/

There's some remnants from the PermGen that's confusing in the class 
unloading code. This patch removes the unnecessary code, cleans up some 
comments and unifies the code structure over different GCs.

 From the Bug report:
---
The PermGen Removal changed CompiledICHolders from being Java objects to 
C++ objects.

CodeCache::do_unloading(...) used to take a keep_alive closure that was 
applied to CompiledICHolders deep down in nmethod::do_unloading. Since 
CompileICHolders don't move anymore, and we have other ways to keep them 
alive, we don't use the keep_alive closures in these functions anymore.

Because of this, CodeCache::do_unloading will not populate the marking 
stacks, and we can remove the call to drain the stacks after the calls 
to CodeCache::do_unloading.

This also has the neat effect that we now can verify that the marking 
has really completed before we start unloading classes, which makes the 
code easier to maintain/understand.
---

thanks,
StefanK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130424/e2870026/attachment.htm>

From coleen.phillimore at oracle.com  Wed Apr 24 20:32:12 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 24 Apr 2013 16:32:12 -0400
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <51783E0D.5080408@oracle.com>
References: <51783E0D.5080408@oracle.com>
Message-ID: <5178414C.7090607@oracle.com>


Stefan,

Is there a common place for this code?  It's 4 copies of the similar 
code, which takes me a while to find when I set out looking for it.  In 
the future, I think StringTable::unlink() could be moved after 
CLDG::purge() which I thought should be around here too (but it's 
not).   The only reason StringTable::unlink() used to be here was 
because it used to have Oops in it.   Can you unite this duplicated code?

Thanks,
Coleen

On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>
> There's some remnants from the PermGen that's confusing in the class 
> unloading code. This patch removes the unnecessary code, cleans up 
> some comments and unifies the code structure over different GCs.
>
> From the Bug report:
> ---
> The PermGen Removal changed CompiledICHolders from being Java objects 
> to C++ objects.
>
> CodeCache::do_unloading(...) used to take a keep_alive closure that 
> was applied to CompiledICHolders deep down in nmethod::do_unloading. 
> Since CompileICHolders don't move anymore, and we have other ways to 
> keep them alive, we don't use the keep_alive closures in these 
> functions anymore.
>
> Because of this, CodeCache::do_unloading will not populate the marking 
> stacks, and we can remove the call to drain the stacks after the calls 
> to CodeCache::do_unloading.
>
> This also has the neat effect that we now can verify that the marking 
> has really completed before we start unloading classes, which makes 
> the code easier to maintain/understand.
> ---
>
> thanks,
> StefanK

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

From stefan.karlsson at oracle.com  Wed Apr 24 20:49:30 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 24 Apr 2013 22:49:30 +0200
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <5178414C.7090607@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
Message-ID: <5178455A.9000206@oracle.com>

On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>
> Stefan,
>
> Is there a common place for this code?

I don't think there's any common place in the GCs for this. I'm open for 
suggestions if you know a good place in the runtime code.

> It's 4 copies of the similar code, which takes me a while to find when 
> I set out looking for it.

Yes, I tried to make them look alike so that we/I have an opportunity to 
extract it out to one function. The fact that CMS does this differently 
made me hesitant to combine them.

> In the future, I think StringTable::unlink() could be moved after 
> CLDG::purge() which I thought should be around here too (but it's 
> not).   The only reason StringTable::unlink() used to be here was 
> because it used to have Oops in it.

Don't you mean the SymbolTable? I'm OK with moving the SymbolTable, but 
not the StringTable ...

>    Can you unite this duplicated code?

It's easy to unit the code for psMarkSweep, genMarkSweep, g1MarkSweep 
and psParallelCompact but it's a bit more work to also unify the CMS 
code. Would it be good enough for this patch if I united the former GCs? 
And maybe handle CMS when G1 also starts doing class unloading?

thanks,
StefanK
>
> Thanks,
> Coleen
>
> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>
>> There's some remnants from the PermGen that's confusing in the class 
>> unloading code. This patch removes the unnecessary code, cleans up 
>> some comments and unifies the code structure over different GCs.
>>
>> From the Bug report:
>> ---
>> The PermGen Removal changed CompiledICHolders from being Java objects 
>> to C++ objects.
>>
>> CodeCache::do_unloading(...) used to take a keep_alive closure that 
>> was applied to CompiledICHolders deep down in nmethod::do_unloading. 
>> Since CompileICHolders don't move anymore, and we have other ways to 
>> keep them alive, we don't use the keep_alive closures in these 
>> functions anymore.
>>
>> Because of this, CodeCache::do_unloading will not populate the 
>> marking stacks, and we can remove the call to drain the stacks after 
>> the calls to CodeCache::do_unloading.
>>
>> This also has the neat effect that we now can verify that the marking 
>> has really completed before we start unloading classes, which makes 
>> the code easier to maintain/understand.
>> ---
>>
>> thanks,
>> StefanK
>

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

From john.cuthbertson at oracle.com  Wed Apr 24 21:05:43 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 14:05:43 -0700
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added
	to last mixed GC
In-Reply-To: <5177724F.7030804@oracle.com>
References: <51772767.3040709@oracle.com> <5177724F.7030804@oracle.com>
Message-ID: <51784927.3090102@oracle.com>

Hi Bengt,

Thanks for looking over the backport. I was a little surprised the 
import didn't apply cleanly.


On 4/23/2013 10:49 PM, Bengt Rutisson wrote:
>
> Hi John,
>
> Looks good!
>
> Since I reviewed the original change I only looked at the diff of the 
> patches this time. As you said the only difference is that 
> finalize_cset() now takes the evacuation_info parameter. I guess once 
> the event tracing is integrated into 8 this code will look the same 
> again in hsx24 and hsx25.

That's my expectation. One of the ways I sanity checked myself was to 
diff hs24 and hs25 versions of g1CollectorPolicy.hpp.

Thanks again,

JohnC



From john.cuthbertson at oracle.com  Wed Apr 24 21:06:15 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 14:06:15 -0700
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added
	to last mixed GC
In-Reply-To: <1366789988.2731.3.camel@cirrus>
References: <51772767.3040709@oracle.com> <1366789988.2731.3.camel@cirrus>
Message-ID: <51784947.6020604@oracle.com>

Hi Thomas,

Thank you!

JohnC

On 4/24/2013 12:53 AM, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2013-04-23 at 17:29 -0700, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have review of the backport of the fix for 800007036 to hsx24? One
>> of the changes to g1CollectorPolicy.cpp did not apply cleanly because of
>> the additional parameter to finalize_cset. There was actually no
>> conflict in the change but importing the changeset rejected that
>> particular chunk.
>>
>> The webrev can be found at:
>> http://cr.openjdk.java.net/~johnc/8007036-hsx24-backport/webrev.0/
> Looks good.
>
> Thomas
>
>



From john.cuthbertson at oracle.com  Wed Apr 24 21:07:04 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 14:07:04 -0700
Subject: RFR(M): [Backport of] 8007036: G1: Too many old regions added
	to last mixed GC
In-Reply-To: <5177EF7A.6050202@oracle.com>
References: <51772767.3040709@oracle.com> <5177EF7A.6050202@oracle.com>
Message-ID: <51784978.3030002@oracle.com>

Hi Jon,

Thanks for sanity checking me.

JohnC

On 4/24/2013 7:43 AM, Jon Masamitsu wrote:
> Looks good.
>
> Jon
>
> On 4/23/13 5:29 PM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have review of the backport of the fix for 800007036 to hsx24? 
>> One of the changes to g1CollectorPolicy.cpp did not apply cleanly 
>> because of the additional parameter to finalize_cset. There was 
>> actually no conflict in the change but importing the changeset 
>> rejected that particular chunk.
>>
>> The webrev can be found at: 
>> http://cr.openjdk.java.net/~johnc/8007036-hsx24-backport/webrev.0/
>>
>> Thanks,
>>
>> JohnC
>



From coleen.phillimore at oracle.com  Wed Apr 24 21:42:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 24 Apr 2013 17:42:32 -0400
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <5178455A.9000206@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com>
Message-ID: <517851C8.50802@oracle.com>

On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>
>> Stefan,
>>
>> Is there a common place for this code?
>
> I don't think there's any common place in the GCs for this. I'm open 
> for suggestions if you know a good place in the runtime code.

memory/genCollectedHeap?   I have no idea...
>
>> It's 4 copies of the similar code, which takes me a while to find 
>> when I set out looking for it.
>
> Yes, I tried to make them look alike so that we/I have an opportunity 
> to extract it out to one function. The fact that CMS does this 
> differently made me hesitant to combine them.
>
>> In the future, I think StringTable::unlink() could be moved after 
>> CLDG::purge() which I thought should be around here too (but it's 
>> not).   The only reason StringTable::unlink() used to be here was 
>> because it used to have Oops in it.
>
> Don't you mean the SymbolTable? I'm OK with moving the SymbolTable, 
> but not the StringTable ...

I did mean SymbolTable.

>
>>    Can you unite this duplicated code?
>
> It's easy to unit the code for psMarkSweep, genMarkSweep, g1MarkSweep 
> and psParallelCompact but it's a bit more work to also unify the CMS 
> code. Would it be good enough for this patch if I united the former 
> GCs? And maybe handle CMS when G1 also starts doing class unloading?

Ok, keep it in mind for future work.  It would be nice to have the 
runtime GC things be called in one place or easy to find.

I semi-reviewed the code and except for the GC part (which is most of 
the change).   We don't pass the keep_alive closure anymore for 
compiledICHolders so I guess this makes sense if this is what the 
keep_alive closure did.   So this is a partial review.

Thanks,
Coleen
>
> thanks,
> StefanK
>>
>> Thanks,
>> Coleen
>>
>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>
>>> There's some remnants from the PermGen that's confusing in the class 
>>> unloading code. This patch removes the unnecessary code, cleans up 
>>> some comments and unifies the code structure over different GCs.
>>>
>>> From the Bug report:
>>> ---
>>> The PermGen Removal changed CompiledICHolders from being Java 
>>> objects to C++ objects.
>>>
>>> CodeCache::do_unloading(...) used to take a keep_alive closure that 
>>> was applied to CompiledICHolders deep down in nmethod::do_unloading. 
>>> Since CompileICHolders don't move anymore, and we have other ways to 
>>> keep them alive, we don't use the keep_alive closures in these 
>>> functions anymore.
>>>
>>> Because of this, CodeCache::do_unloading will not populate the 
>>> marking stacks, and we can remove the call to drain the stacks after 
>>> the calls to CodeCache::do_unloading.
>>>
>>> This also has the neat effect that we now can verify that the 
>>> marking has really completed before we start unloading classes, 
>>> which makes the code easier to maintain/understand.
>>> ---
>>>
>>> thanks,
>>> StefanK
>>
>

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

From john.cuthbertson at oracle.com  Thu Apr 25 00:59:39 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 17:59:39 -0700
Subject: Review request: 8013132: Add a flag to turn off the output of
	the verbose verification code
In-Reply-To: <5178207E.1080209@oracle.com>
References: <5178207E.1080209@oracle.com>
Message-ID: <51787FFB.3000103@oracle.com>

Hi Stefan,

Looks fine to me.

One minor point - this will affect the reg test I sent out for review 
yesterday which explicitly looks for "[Verifying..."

JohnC

On 4/24/2013 11:12 AM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8013132/webrev.00/
>
> This RFE adds a new flag named VerifySilently, which can be used to 
> turn off the verbose output that the verification code produces. The 
> proposed name has been chosen to match other Verify flags.
>
> From the Bug description:
> ---
> The HotSpot verification code is rather verbose and intrusive. I 
> propose that we add a flag that can be used to turn this output off.
>
> An example of the verification output:
> $ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions 
> -XX:+VerifyBeforeExit -XX:+VerifyAfterGC -XX:+VerifyBeforeGC 
> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -cp 
> /localhome/tests/ HelloSystemGC
>  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
> generation par new generation remset syms strs zone dict cldg 
> metaspace chunks hand C-heap code cache ]
> [GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
>  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep 
> generation par new generation remset syms strs zone dict cldg 
> metaspace chunks hand C-heap code cache ]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
> [GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
> [GC (CMS Final Remark) [Verifying CMS Marking... done] 1604K(121600K), 
> 0.1008210 secs]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
>
> And with the proposed flag turned on:
> [GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
> [GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
> [GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
> ---
>
> thanks,
> StefanK

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

From bengt.rutisson at oracle.com  Thu Apr 25 06:20:04 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 25 Apr 2013 08:20:04 +0200
Subject: Review request: 8013132: Add a flag to turn off the output of
	the verbose verification code
In-Reply-To: <5178207E.1080209@oracle.com>
References: <5178207E.1080209@oracle.com>
Message-ID: <5178CB14.90006@oracle.com>


Stefan,

Looks good to me.

Bengt


On 4/24/13 8:12 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8013132/webrev.00/
>
> This RFE adds a new flag named VerifySilently, which can be used to 
> turn off the verbose output that the verification code produces. The 
> proposed name has been chosen to match other Verify flags.
>
> From the Bug description:
> ---
> The HotSpot verification code is rather verbose and intrusive. I 
> propose that we add a flag that can be used to turn this output off.
>
> An example of the verification output:
> $ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions 
> -XX:+VerifyBeforeExit -XX:+VerifyAfterGC -XX:+VerifyBeforeGC 
> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -cp 
> /localhome/tests/ HelloSystemGC
>  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
> generation par new generation remset syms strs zone dict cldg 
> metaspace chunks hand C-heap code cache ]
> [GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
>  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep 
> generation par new generation remset syms strs zone dict cldg 
> metaspace chunks hand C-heap code cache ]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
> [GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
> [GC (CMS Final Remark) [Verifying CMS Marking... done] 1604K(121600K), 
> 0.1008210 secs]
> [Verifying threads heap concurrent mark-sweep generation par new 
> generation remset syms strs zone dict cldg metaspace chunks hand 
> C-heap code cache ]
>
> And with the proposed flag turned on:
> [GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
> [GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
> [GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
> ---
>
> thanks,
> StefanK

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

From bengt.rutisson at oracle.com  Thu Apr 25 06:33:13 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 25 Apr 2013 08:33:13 +0200
Subject: RFR(S): 8011898: gc/TestVerifyBeforeGCDuringStartup.java:
	java.lang.RuntimeException
In-Reply-To: <5177243D.9030006@oracle.com>
References: <5177243D.9030006@oracle.com>
Message-ID: <5178CE29.8090807@oracle.com>


Hi John,

This looks good.

A couple of questions:

The test is pretty verbose. Do you really want to keep all the 
System.out.print-ing?

   51     System.out.print("Testing:\n" + JDKToolFinder.getJDKTool("java"));
   52     for (int i = 0; i < vmOpts.size(); i += 1) {
   53       System.out.print(" " + vmOpts.get(i));
   54     }
   55     System.out.println();

   61     System.out.println("Output:\n" + output.getOutput());

If you remove the printing at line 51 I guess you can also remove the 
import of JDKToolsFinder.

Thanks,
Bengt


On 4/24/13 2:15 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review these changes to the 
> regression test I added for 8010463 and changed for 8011343? The 
> webrev can found at: http://cr.openjdk.java.net/~johnc/8011898/webrev.0/
>
> Summary:
> The call to System.getProperty("test.vm.opts") will return null if no 
> additional vm or java options are passed into jtreg. Hence the first 
> entry in the String array, that is passed to 
> createJavaProcessBuilder(), is null. When the null is converted to 
> options, the first option will be the empty string which the java 
> launcher interprets as the name of the main class.
>
> Many thanks to Bengt for his diagnosis.
>
> Notes:
>
> In this test I'm using the same mechanism as in Tao's test for 
> 6761744. His is much nicer than what I came up with. Many tanks to Tao.
>
> The test now reads the test.java.opts instead of test.vm.opts after 
> feedback from SQE.
>
> Also I added a couple of prints to test to make it easier to see what 
> the command line of the child java process actually is and it's 
> resulting output. In the .jtr file you see something like:
>
>> ----------messages:(3/144)----------
>> command: main TestVerifyDuringStartup
>> reason: Assumed action based on file name: run main 
>> TestVerifyDuringStartup
>> elapsed time (seconds): 0.32
>> ----------System.out:(8/408)----------
>> Testing:
>> /export/jdk8-1/solaris-x64/bin/java -XX:+UseG1GC -XX:-UseTLAB 
>> -XX:+UnlockDiagnosticVMOptions -XX:+VerifyDuringStartup -version
>> Output:
>> [Verifying threads Roots HeapRegionSets HeapRegions RemSet syms strs 
>> zone dict metaspace chunks hand C-heap code cache ]
>> java version "1.8.0-ea"
>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b58)
>> Java HotSpot(TM) Server VM (build 25.0-b29-internal, mixed mode)
>>
>> ----------System.err:(1/15)----------
>> STATUS:Passed.
>> result: Passed. Execution successful
>
> Thanks,
>
> JohnC

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

From stefan.karlsson at oracle.com  Thu Apr 25 07:05:02 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 25 Apr 2013 09:05:02 +0200
Subject: Review request: 8013132: Add a flag to turn off the output of
	the verbose verification code
In-Reply-To: <51787FFB.3000103@oracle.com>
References: <5178207E.1080209@oracle.com> <51787FFB.3000103@oracle.com>
Message-ID: <5178D59E.5020908@oracle.com>

On 04/25/2013 02:59 AM, John Cuthbertson wrote:
> Hi Stefan,
>
> Looks fine to me.

Thanks, John.

>
> One minor point - this will affect the reg test I sent out for review 
> yesterday which explicitly looks for "[Verifying..."

The flag is off by default, so this will not affect  your test. I've 
verified this by applying you patch.

thanks,
StefanK

>
> JohnC
>
> On 4/24/2013 11:12 AM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8013132/webrev.00/
>>
>> This RFE adds a new flag named VerifySilently, which can be used to 
>> turn off the verbose output that the verification code produces. The 
>> proposed name has been chosen to match other Verify flags.
>>
>> From the Bug description:
>> ---
>> The HotSpot verification code is rather verbose and intrusive. I 
>> propose that we add a flag that can be used to turn this output off.
>>
>> An example of the verification output:
>> $ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions 
>> -XX:+VerifyBeforeExit -XX:+VerifyAfterGC -XX:+VerifyBeforeGC 
>> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -cp 
>> /localhome/tests/ HelloSystemGC
>>  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
>> generation par new generation remset syms strs zone dict cldg 
>> metaspace chunks hand C-heap code cache ]
>> [GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
>>  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep 
>> generation par new generation remset syms strs zone dict cldg 
>> metaspace chunks hand C-heap code cache ]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>> [GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>> [GC (CMS Final Remark) [Verifying CMS Marking... done] 
>> 1604K(121600K), 0.1008210 secs]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>>
>> And with the proposed flag turned on:
>> [GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
>> [GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
>> [GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
>> ---
>>
>> thanks,
>> StefanK
>

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

From stefan.karlsson at oracle.com  Thu Apr 25 07:05:18 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 25 Apr 2013 09:05:18 +0200
Subject: Review request: 8013132: Add a flag to turn off the output of
	the verbose verification code
In-Reply-To: <5178CB14.90006@oracle.com>
References: <5178207E.1080209@oracle.com> <5178CB14.90006@oracle.com>
Message-ID: <5178D5AE.2030400@oracle.com>

On 04/25/2013 08:20 AM, Bengt Rutisson wrote:
>
> Stefan,
>
> Looks good to me.

Thanks, Bengt.

StefanK

>
> Bengt
>
>
> On 4/24/13 8:12 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8013132/webrev.00/
>>
>> This RFE adds a new flag named VerifySilently, which can be used to 
>> turn off the verbose output that the verification code produces. The 
>> proposed name has been chosen to match other Verify flags.
>>
>> From the Bug description:
>> ---
>> The HotSpot verification code is rather verbose and intrusive. I 
>> propose that we add a flag that can be used to turn this output off.
>>
>> An example of the verification output:
>> $ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions 
>> -XX:+VerifyBeforeExit -XX:+VerifyAfterGC -XX:+VerifyBeforeGC 
>> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -cp 
>> /localhome/tests/ HelloSystemGC
>>  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
>> generation par new generation remset syms strs zone dict cldg 
>> metaspace chunks hand C-heap code cache ]
>> [GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
>>  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep 
>> generation par new generation remset syms strs zone dict cldg 
>> metaspace chunks hand C-heap code cache ]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>> [GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>> [GC (CMS Final Remark) [Verifying CMS Marking... done] 
>> 1604K(121600K), 0.1008210 secs]
>> [Verifying threads heap concurrent mark-sweep generation par new 
>> generation remset syms strs zone dict cldg metaspace chunks hand 
>> C-heap code cache ]
>>
>> And with the proposed flag turned on:
>> [GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
>> [GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
>> [GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
>> ---
>>
>> thanks,
>> StefanK
>

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

From john.cuthbertson at oracle.com  Thu Apr 25 07:10:21 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Thu, 25 Apr 2013 07:10:21 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8012715: G1: GraphKit accesses
	PtrQueue::_index as int but is size_t
Message-ID: <20130425071026.52493485BC@hg.openjdk.java.net>

Changeset: d50cc62e94ff
Author:    johnc
Date:      2013-04-24 14:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d50cc62e94ff

8012715: G1: GraphKit accesses PtrQueue::_index as int but is size_t
Summary: In graphKit INT operations were generated to access PtrQueue::_index which has type size_t. This is 64 bit on 64-bit machines. No problems occur on little endian machines as long as the index fits into 32 bit, but on big endian machines the upper part is read, which is zero. This leads to unnecessary branches to the slow path in the runtime.
Reviewed-by: twisti, johnc
Contributed-by: Martin Doerr <martin.doerr at sap.com>

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



From mikael.gerdin at oracle.com  Thu Apr 25 09:10:16 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 25 Apr 2013 11:10:16 +0200
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due to
	mixed usage of safepoint aware and non-safepoint aware locking
Message-ID: <5178F2F8.7020900@oracle.com>

Hi,

Problem:
We've seen some hangs in the GC nightly testing recently.
When I looked at the minidump files from some of those hangs they looked 
like safepoint deadlocks where one thread was parked in 
Mutex::lock_without_safepoint_check on one of the "Metaspace allocation 
locks".

Both of the hangs I investigated also had threads trying to lock the 
same Metaspace lock but without eliding safepoint checks because they 
were originating from Metaspace::deallocate.

I believe that since the change to allocate MethodCounters on demand and 
potentially deallocating them when racing this issue was brought to the 
surface because of more frequent calls to Metaspace::deallocate when not 
at a safepoint.

I was able to reproduce the hang after about an hour by running an 
instrumented build where MethodCounters are allocated and then 
unconditionally deallocated on each entry to Method::build_method_counters.

I can't describe the failure mode in detail since I'm not familiar with 
the Mutex code but I can imagine that the locking state machine is 
broken when we take completely different code paths for the same Mutex.

Suggested fix:
My suggested fix is to change Metaspace::deallocate to take the lock 
with Mutex::_no_safepoint_check_flag.

With my fix I ran the test that managed to reproduce the failure 
overnight without reproducing the hang.
I also ran the parallel class loading tests and nashorn's 
test262parallel for good measure.

Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129

/Mikael


From bengt.rutisson at oracle.com  Thu Apr 25 11:09:06 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 25 Apr 2013 13:09:06 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken on
	Windows
Message-ID: <51790ED2.8020407@oracle.com>


Hi everyone,

Could I have a couple of reviews of this change?
http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/

Background from the CR:

The method ReservedSpace::align_reserved_region() does not work on 
Windows. It tries to free parts of the previously allocated memory by 
doing two calls to os::release_memory(). However, on Windows 
os::release_memory() is implemented as:

  VirtualFree(addr, 0, MEM_RELEASE)

which will always free up all the allocated memory:

http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 


"The function frees the entire region that is reserved in the initial 
allocation call to VirtualAlloc."

This means that if ReservedSpace::align_reserved_region() is executed on 
Windows and we try to trim the beginning of the memory that we had 
allocated we will free all of the allocated memory. Subsequent calls to 
os::commit_memory() which will end up as:

VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)

will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
address.

The solution is to use the existing method os::reserve_memory_aligned() 
which does the same thing but works on all platforms.

I assume that it is unusual that we enter this code path since I haven't 
seen a lot of crashes that seem related to this issue. But when we tried 
a patch that plays a bit with the alignments we crash on Windows. To 
have a simple reproducer I added a unit test. The test is not 100% fool 
proof, but on Windows without my proposed fix it fails 999 times out of 
1000 runs. With my fix it passes 100% of the time.

Thanks,
Bengt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130425/c2158d53/attachment.htm>

From mikael.gerdin at oracle.com  Thu Apr 25 11:38:40 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 25 Apr 2013 13:38:40 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <51790ED2.8020407@oracle.com>
References: <51790ED2.8020407@oracle.com>
Message-ID: <517915C0.1000703@oracle.com>

Bengt,

On 04/25/2013 01:09 PM, Bengt Rutisson wrote:
>
> Hi everyone,
>
> Could I have a couple of reviews of this change?
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>
> Background from the CR:
>
> The method ReservedSpace::align_reserved_region() does not work on
> Windows. It tries to free parts of the previously allocated memory by
> doing two calls to os::release_memory(). However, on Windows
> os::release_memory() is implemented as:
>
>   VirtualFree(addr, 0, MEM_RELEASE)
>
> which will always free up all the allocated memory:
>
> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx
>
>
> "The function frees the entire region that is reserved in the initial
> allocation call to VirtualAlloc."
>
> This means that if ReservedSpace::align_reserved_region() is executed on
> Windows and we try to trim the beginning of the memory that we had
> allocated we will free all of the allocated memory. Subsequent calls to
> os::commit_memory() which will end up as:
>
> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>
> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid
> address.
>
> The solution is to use the existing method os::reserve_memory_aligned()
> which does the same thing but works on all platforms.
>
> I assume that it is unusual that we enter this code path since I haven't
> seen a lot of crashes that seem related to this issue. But when we tried
> a patch that plays a bit with the alignments we crash on Windows. To
> have a simple reproducer I added a unit test. The test is not 100% fool
> proof, but on Windows without my proposed fix it fails 999 times out of
> 1000 runs. With my fix it passes 100% of the time.

The fix looks good and I like that you added a test for this even though 
the test is not 100% deterministic.

Ship it!
/Mikael

>
> Thanks,
> Bengt



From coleen.phillimore at oracle.com  Thu Apr 25 11:54:22 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 25 Apr 2013 07:54:22 -0400
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <51790ED2.8020407@oracle.com>
References: <51790ED2.8020407@oracle.com>
Message-ID: <5179196E.9060801@oracle.com>


Hi Bengt,
My memory was that all that weird code for aligning windows mmap space 
was for CDS.   Can you try your test with -Xshare:dump and -Xshare:on 
-version?
thanks,
Coleen

On 4/25/2013 7:09 AM, Bengt Rutisson wrote:
>
> Hi everyone,
>
> Could I have a couple of reviews of this change?
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>
> Background from the CR:
>
> The method ReservedSpace::align_reserved_region() does not work on 
> Windows. It tries to free parts of the previously allocated memory by 
> doing two calls to os::release_memory(). However, on Windows 
> os::release_memory() is implemented as:
>
>  VirtualFree(addr, 0, MEM_RELEASE)
>
> which will always free up all the allocated memory:
>
> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>
>
> "The function frees the entire region that is reserved in the initial 
> allocation call to VirtualAlloc."
>
> This means that if ReservedSpace::align_reserved_region() is executed 
> on Windows and we try to trim the beginning of the memory that we had 
> allocated we will free all of the allocated memory. Subsequent calls 
> to os::commit_memory() which will end up as:
>
> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>
> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
> address.
>
> The solution is to use the existing method 
> os::reserve_memory_aligned() which does the same thing but works on 
> all platforms.
>
> I assume that it is unusual that we enter this code path since I 
> haven't seen a lot of crashes that seem related to this issue. But 
> when we tried a patch that plays a bit with the alignments we crash on 
> Windows. To have a simple reproducer I added a unit test. The test is 
> not 100% fool proof, but on Windows without my proposed fix it fails 
> 999 times out of 1000 runs. With my fix it passes 100% of the time.
>
> Thanks,
> Bengt

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

From coleen.phillimore at oracle.com  Thu Apr 25 11:57:47 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 25 Apr 2013 07:57:47 -0400
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <5178F2F8.7020900@oracle.com>
References: <5178F2F8.7020900@oracle.com>
Message-ID: <51791A3B.2060608@oracle.com>


Mikael,

I believe this change is correct.  I think if we elide safepoint locks 
for a lock sometimes, we always have to elide safepoint checks for that 
lock.   David will correct me if I'm wrong.

Coleen

On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
> Hi,
>
> Problem:
> We've seen some hangs in the GC nightly testing recently.
> When I looked at the minidump files from some of those hangs they 
> looked like safepoint deadlocks where one thread was parked in 
> Mutex::lock_without_safepoint_check on one of the "Metaspace 
> allocation locks".
>
> Both of the hangs I investigated also had threads trying to lock the 
> same Metaspace lock but without eliding safepoint checks because they 
> were originating from Metaspace::deallocate.
>
> I believe that since the change to allocate MethodCounters on demand 
> and potentially deallocating them when racing this issue was brought 
> to the surface because of more frequent calls to Metaspace::deallocate 
> when not at a safepoint.
>
> I was able to reproduce the hang after about an hour by running an 
> instrumented build where MethodCounters are allocated and then 
> unconditionally deallocated on each entry to 
> Method::build_method_counters.
>
> I can't describe the failure mode in detail since I'm not familiar 
> with the Mutex code but I can imagine that the locking state machine 
> is broken when we take completely different code paths for the same 
> Mutex.
>
> Suggested fix:
> My suggested fix is to change Metaspace::deallocate to take the lock 
> with Mutex::_no_safepoint_check_flag.
>
> With my fix I ran the test that managed to reproduce the failure 
> overnight without reproducing the hang.
> I also ran the parallel class loading tests and nashorn's 
> test262parallel for good measure.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>
> /Mikael



From mikael.gerdin at oracle.com  Thu Apr 25 12:03:44 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 25 Apr 2013 14:03:44 +0200
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <51791A3B.2060608@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
Message-ID: <51791BA0.9070108@oracle.com>

Coleen,

On 04/25/2013 01:57 PM, Coleen Phillimore wrote:
>
> Mikael,
>
> I believe this change is correct.  I think if we elide safepoint locks
> for a lock sometimes, we always have to elide safepoint checks for that
> lock.   David will correct me if I'm wrong.

I also believe that the change is correct.
And I hope that David will chime in on this one.

/Mikael

>
> Coleen
>
> On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
>> Hi,
>>
>> Problem:
>> We've seen some hangs in the GC nightly testing recently.
>> When I looked at the minidump files from some of those hangs they
>> looked like safepoint deadlocks where one thread was parked in
>> Mutex::lock_without_safepoint_check on one of the "Metaspace
>> allocation locks".
>>
>> Both of the hangs I investigated also had threads trying to lock the
>> same Metaspace lock but without eliding safepoint checks because they
>> were originating from Metaspace::deallocate.
>>
>> I believe that since the change to allocate MethodCounters on demand
>> and potentially deallocating them when racing this issue was brought
>> to the surface because of more frequent calls to Metaspace::deallocate
>> when not at a safepoint.
>>
>> I was able to reproduce the hang after about an hour by running an
>> instrumented build where MethodCounters are allocated and then
>> unconditionally deallocated on each entry to
>> Method::build_method_counters.
>>
>> I can't describe the failure mode in detail since I'm not familiar
>> with the Mutex code but I can imagine that the locking state machine
>> is broken when we take completely different code paths for the same
>> Mutex.
>>
>> Suggested fix:
>> My suggested fix is to change Metaspace::deallocate to take the lock
>> with Mutex::_no_safepoint_check_flag.
>>
>> With my fix I ran the test that managed to reproduce the failure
>> overnight without reproducing the hang.
>> I also ran the parallel class loading tests and nashorn's
>> test262parallel for good measure.
>>
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>
>> /Mikael
>



From stefan.karlsson at oracle.com  Thu Apr 25 12:07:48 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 25 Apr 2013 14:07:48 +0200
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <517851C8.50802@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
Message-ID: <51791C94.7070604@oracle.com>

On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>
>>> Stefan,
>>>
>>> Is there a common place for this code?
>>
>> I don't think there's any common place in the GCs for this. I'm open 
>> for suggestions if you know a good place in the runtime code.
>
> memory/genCollectedHeap?   I have no idea...
>>
>>> It's 4 copies of the similar code, which takes me a while to find 
>>> when I set out looking for it.
>>
>> Yes, I tried to make them look alike so that we/I have an opportunity 
>> to extract it out to one function. The fact that CMS does this 
>> differently made me hesitant to combine them.
>>
>>> In the future, I think StringTable::unlink() could be moved after 
>>> CLDG::purge() which I thought should be around here too (but it's 
>>> not). The only reason StringTable::unlink() used to be here was 
>>> because it used to have Oops in it.
>>
>> Don't you mean the SymbolTable? I'm OK with moving the SymbolTable, 
>> but not the StringTable ...
>
> I did mean SymbolTable.
>
>>
>>>    Can you unite this duplicated code?
>>
>> It's easy to unit the code for psMarkSweep, genMarkSweep, g1MarkSweep 
>> and psParallelCompact but it's a bit more work to also unify the CMS 
>> code. Would it be good enough for this patch if I united the former 
>> GCs? And maybe handle CMS when G1 also starts doing class unloading?
>
> Ok, keep it in mind for future work.  It would be nice to have the 
> runtime GC things be called in one place or easy to find.
>
> I semi-reviewed the code and except for the GC part (which is most of 
> the change).   We don't pass the keep_alive closure anymore for 
> compiledICHolders so I guess this makes sense if this is what the 
> keep_alive closure did.   So this is a partial review.

I've update the patch to gather the unloading code in a helper class 
called GCUnloading. What do you think?

http://cr.openjdk.java.net/~stefank/8013160/webrev.01/

thanks,
StefanK

>
> Thanks,
> Coleen
>>
>> thanks,
>> StefanK
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>
>>>> There's some remnants from the PermGen that's confusing in the 
>>>> class unloading code. This patch removes the unnecessary code, 
>>>> cleans up some comments and unifies the code structure over 
>>>> different GCs.
>>>>
>>>> From the Bug report:
>>>> ---
>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>> objects to C++ objects.
>>>>
>>>> CodeCache::do_unloading(...) used to take a keep_alive closure that 
>>>> was applied to CompiledICHolders deep down in 
>>>> nmethod::do_unloading. Since CompileICHolders don't move anymore, 
>>>> and we have other ways to keep them alive, we don't use the 
>>>> keep_alive closures in these functions anymore.
>>>>
>>>> Because of this, CodeCache::do_unloading will not populate the 
>>>> marking stacks, and we can remove the call to drain the stacks 
>>>> after the calls to CodeCache::do_unloading.
>>>>
>>>> This also has the neat effect that we now can verify that the 
>>>> marking has really completed before we start unloading classes, 
>>>> which makes the code easier to maintain/understand.
>>>> ---
>>>>
>>>> thanks,
>>>> StefanK
>>>
>>
>

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

From bengt.rutisson at oracle.com  Thu Apr 25 12:15:10 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 25 Apr 2013 14:15:10 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <5179196E.9060801@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179196E.9060801@oracle.com>
Message-ID: <51791E4E.5020606@oracle.com>


Hi Coleen,

Thanks for looking at this!

On 4/25/13 1:54 PM, Coleen Phillimore wrote:
>
> Hi Bengt,
> My memory was that all that weird code for aligning windows mmap space 
> was for CDS.   Can you try your test with -Xshare:dump and -Xshare:on 
> -version?
> thanks,

Seems to work:

 >hotspot.exe -Xshare:dump
Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre
Loading classes to share ... done.
Rewriting and linking classes ... done.
Number of classes 2245
Calculating fingerprints ... done.
Removing unshareable information ... done.
ro space:   7132288 [ 36.9% of total] out of  16777216 bytes [42.5% 
used] at 0x0000000800000000
rw space:  10270832 [ 53.2% of total] out of  16777216 bytes [61.2% 
used] at 0x0000000801000000
md space:   1881528 [  9.7% of total] out of   4194304 bytes [44.9% 
used] at 0x0000000802000000
mc space:     34053 [  0.2% of total] out of    122880 bytes [27.7% 
used] at 0x0000000802400000
total   :  19318701 [100.0% of total] out of  37871616 bytes [51.0% used]

 >hotspot.exe -Xshare:on -version
Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b148)
Java HotSpot(TM) 64-Bit Client VM (build 25.0-b30-internal-debug, mixed 
mode, sharing)


I have also run JPRT on my change and I think that does some CDS 
testing, right?

Thanks,
Bengt

> Coleen
>
> On 4/25/2013 7:09 AM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I have a couple of reviews of this change?
>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>
>> Background from the CR:
>>
>> The method ReservedSpace::align_reserved_region() does not work on 
>> Windows. It tries to free parts of the previously allocated memory by 
>> doing two calls to os::release_memory(). However, on Windows 
>> os::release_memory() is implemented as:
>>
>>  VirtualFree(addr, 0, MEM_RELEASE)
>>
>> which will always free up all the allocated memory:
>>
>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>>
>>
>> "The function frees the entire region that is reserved in the initial 
>> allocation call to VirtualAlloc."
>>
>> This means that if ReservedSpace::align_reserved_region() is executed 
>> on Windows and we try to trim the beginning of the memory that we had 
>> allocated we will free all of the allocated memory. Subsequent calls 
>> to os::commit_memory() which will end up as:
>>
>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>
>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
>> address.
>>
>> The solution is to use the existing method 
>> os::reserve_memory_aligned() which does the same thing but works on 
>> all platforms.
>>
>> I assume that it is unusual that we enter this code path since I 
>> haven't seen a lot of crashes that seem related to this issue. But 
>> when we tried a patch that plays a bit with the alignments we crash 
>> on Windows. To have a simple reproducer I added a unit test. The test 
>> is not 100% fool proof, but on Windows without my proposed fix it 
>> fails 999 times out of 1000 runs. With my fix it passes 100% of the time.
>>
>> Thanks,
>> Bengt
>

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

From coleen.phillimore at oracle.com  Thu Apr 25 12:34:49 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 25 Apr 2013 08:34:49 -0400
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <51791E4E.5020606@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179196E.9060801@oracle.com>
	<51791E4E.5020606@oracle.com>
Message-ID: <517922E9.6020502@oracle.com>

On 4/25/2013 8:15 AM, Bengt Rutisson wrote:
>
> Hi Coleen,
>
> Thanks for looking at this!
>
> On 4/25/13 1:54 PM, Coleen Phillimore wrote:
>>
>> Hi Bengt,
>> My memory was that all that weird code for aligning windows mmap 
>> space was for CDS.   Can you try your test with -Xshare:dump and 
>> -Xshare:on -version?
>> thanks,
>
> Seems to work:
>
> >hotspot.exe -Xshare:dump
> Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre
> Loading classes to share ... done.
> Rewriting and linking classes ... done.
> Number of classes 2245
> Calculating fingerprints ... done.
> Removing unshareable information ... done.
> ro space:   7132288 [ 36.9% of total] out of  16777216 bytes [42.5% 
> used] at 0x0000000800000000
> rw space:  10270832 [ 53.2% of total] out of  16777216 bytes [61.2% 
> used] at 0x0000000801000000
> md space:   1881528 [  9.7% of total] out of   4194304 bytes [44.9% 
> used] at 0x0000000802000000
> mc space:     34053 [  0.2% of total] out of    122880 bytes [27.7% 
> used] at 0x0000000802400000
> total   :  19318701 [100.0% of total] out of  37871616 bytes [51.0% used]
>
> >hotspot.exe -Xshare:on -version
> Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b148)
> Java HotSpot(TM) 64-Bit Client VM (build 25.0-b30-internal-debug, 
> mixed mode, sharing)
>
>
> I have also run JPRT on my change and I think that does some CDS 
> testing, right?

Yes, JPRT does test this with a client VM.  Does your test run with 
-Xshare:on (and hit the code that you changed)?
thanks,
Coleen
>
> Thanks,
> Bengt
>
>> Coleen
>>
>> On 4/25/2013 7:09 AM, Bengt Rutisson wrote:
>>>
>>> Hi everyone,
>>>
>>> Could I have a couple of reviews of this change?
>>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>>
>>> Background from the CR:
>>>
>>> The method ReservedSpace::align_reserved_region() does not work on 
>>> Windows. It tries to free parts of the previously allocated memory 
>>> by doing two calls to os::release_memory(). However, on Windows 
>>> os::release_memory() is implemented as:
>>>
>>>  VirtualFree(addr, 0, MEM_RELEASE)
>>>
>>> which will always free up all the allocated memory:
>>>
>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>>>
>>>
>>> "The function frees the entire region that is reserved in the 
>>> initial allocation call to VirtualAlloc."
>>>
>>> This means that if ReservedSpace::align_reserved_region() is 
>>> executed on Windows and we try to trim the beginning of the memory 
>>> that we had allocated we will free all of the allocated memory. 
>>> Subsequent calls to os::commit_memory() which will end up as:
>>>
>>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>>
>>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access 
>>> invalid address.
>>>
>>> The solution is to use the existing method 
>>> os::reserve_memory_aligned() which does the same thing but works on 
>>> all platforms.
>>>
>>> I assume that it is unusual that we enter this code path since I 
>>> haven't seen a lot of crashes that seem related to this issue. But 
>>> when we tried a patch that plays a bit with the alignments we crash 
>>> on Windows. To have a simple reproducer I added a unit test. The 
>>> test is not 100% fool proof, but on Windows without my proposed fix 
>>> it fails 999 times out of 1000 runs. With my fix it passes 100% of 
>>> the time.
>>>
>>> Thanks,
>>> Bengt
>>
>

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

From stefan.karlsson at oracle.com  Thu Apr 25 12:45:32 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Thu, 25 Apr 2013 12:45:32 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8013132: Add a flag to turn off the
	output of the verbose verification code
Message-ID: <20130425124539.BEF79485C4@hg.openjdk.java.net>

Changeset: b06ac540229e
Author:    stefank
Date:      2013-04-24 20:13 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b06ac540229e

8013132: Add a flag to turn off the output of the verbose verification code
Reviewed-by: johnc, brutisso

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.hpp



From bengt.rutisson at oracle.com  Thu Apr 25 14:33:04 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 25 Apr 2013 16:33:04 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <517922E9.6020502@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179196E.9060801@oracle.com>
	<51791E4E.5020606@oracle.com> <517922E9.6020502@oracle.com>
Message-ID: <51793EA0.7080105@oracle.com>


On 4/25/13 2:34 PM, Coleen Phillimore wrote:
> On 4/25/2013 8:15 AM, Bengt Rutisson wrote:
>>
>> Hi Coleen,
>>
>> Thanks for looking at this!
>>
>> On 4/25/13 1:54 PM, Coleen Phillimore wrote:
>>>
>>> Hi Bengt,
>>> My memory was that all that weird code for aligning windows mmap 
>>> space was for CDS.   Can you try your test with -Xshare:dump and 
>>> -Xshare:on -version?
>>> thanks,
>>
>> Seems to work:
>>
>> >hotspot.exe -Xshare:dump
>> Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre
>> Loading classes to share ... done.
>> Rewriting and linking classes ... done.
>> Number of classes 2245
>> Calculating fingerprints ... done.
>> Removing unshareable information ... done.
>> ro space:   7132288 [ 36.9% of total] out of  16777216 bytes [42.5% 
>> used] at 0x0000000800000000
>> rw space:  10270832 [ 53.2% of total] out of  16777216 bytes [61.2% 
>> used] at 0x0000000801000000
>> md space:   1881528 [  9.7% of total] out of   4194304 bytes [44.9% 
>> used] at 0x0000000802000000
>> mc space:     34053 [  0.2% of total] out of    122880 bytes [27.7% 
>> used] at 0x0000000802400000
>> total   :  19318701 [100.0% of total] out of  37871616 bytes [51.0% used]
>>
>> >hotspot.exe -Xshare:on -version
>> Using java runtime at: d:\java\jdk-7-fcs-bin-b148\jre
>> java version "1.7.0"
>> Java(TM) SE Runtime Environment (build 1.7.0-b148)
>> Java HotSpot(TM) 64-Bit Client VM (build 25.0-b30-internal-debug, 
>> mixed mode, sharing)
>>
>>
>> I have also run JPRT on my change and I think that does some CDS 
>> testing, right?
>
> Yes, JPRT does test this with a client VM.  Does your test run with 
> -Xshare:on (and hit the code that you changed)?
> thanks,

Thanks for asking this, Coleen!

It turns out that we don't hit the code. And the reason that we don't 
hit it is that it is dead code. Thanks for making me try this!

I'll send out a new webrev where this code is removed instead.

Here's why I thought this was used if anyone wonders:

This code is in use in JDK7 where PermGen still exists. I found the 
issue there and started fixing it. It turns out to be more difficult to 
fix it there, and I realized it would be a very simple fix in JDK8. I 
already had the test and ported the test to JDK8. The test reproduced 
the issue and I fixed the problem not realizing that my test was the 
only user of this code now. And I figured I'd send the change out for 
review and then go back to fixing this in JDK7.

I guess that I will now send out a review for removing this code in JDK8 
and then go back to how we should handle this in JDK7.

Thanks,
Bengt

> Coleen
>>
>> Thanks,
>> Bengt
>>
>>> Coleen
>>>
>>> On 4/25/2013 7:09 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Could I have a couple of reviews of this change?
>>>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>>>
>>>> Background from the CR:
>>>>
>>>> The method ReservedSpace::align_reserved_region() does not work on 
>>>> Windows. It tries to free parts of the previously allocated memory 
>>>> by doing two calls to os::release_memory(). However, on Windows 
>>>> os::release_memory() is implemented as:
>>>>
>>>>  VirtualFree(addr, 0, MEM_RELEASE)
>>>>
>>>> which will always free up all the allocated memory:
>>>>
>>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>>>>
>>>>
>>>> "The function frees the entire region that is reserved in the 
>>>> initial allocation call to VirtualAlloc."
>>>>
>>>> This means that if ReservedSpace::align_reserved_region() is 
>>>> executed on Windows and we try to trim the beginning of the memory 
>>>> that we had allocated we will free all of the allocated memory. 
>>>> Subsequent calls to os::commit_memory() which will end up as:
>>>>
>>>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>>>
>>>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access 
>>>> invalid address.
>>>>
>>>> The solution is to use the existing method 
>>>> os::reserve_memory_aligned() which does the same thing but works on 
>>>> all platforms.
>>>>
>>>> I assume that it is unusual that we enter this code path since I 
>>>> haven't seen a lot of crashes that seem related to this issue. But 
>>>> when we tried a patch that plays a bit with the alignments we crash 
>>>> on Windows. To have a simple reproducer I added a unit test. The 
>>>> test is not 100% fool proof, but on Windows without my proposed fix 
>>>> it fails 999 times out of 1000 runs. With my fix it passes 100% of 
>>>> the time.
>>>>
>>>> Thanks,
>>>> Bengt
>>>
>>
>

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

From lokesh.gidra at yahoo.com  Thu Apr 25 14:52:11 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Thu, 25 Apr 2013 22:52:11 +0800 (SGT)
Subject: Deadlock while running SPECjbb2013
In-Reply-To: <51780E74.6020300@oracle.com>
References: <1366718385.83583.YahooMailNeo@web190905.mail.sg3.yahoo.com>
	<5177E920.2010207@oracle.com>
	<1366816066.41796.YahooMailNeo@web190903.mail.sg3.yahoo.com>
	<51780E74.6020300@oracle.com>
Message-ID: <1366901531.38632.YahooMailNeo@web190902.mail.sg3.yahoo.com>

I am making more tests to confirm what I said earlier. I will update soon.

Lokesh




----- Original Message -----
> From: Jon Masamitsu <jon.masamitsu at oracle.com>
> To: Lokesh Gidra <lokesh.gidra at yahoo.com>
> Cc: "hotspot-gc-dev at openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>
> Sent: Wednesday, 24 April 2013 6:55 PM
> Subject: Re: Deadlock while running SPECjbb2013
> 
> 
> On 4/24/13 8:07 AM, Lokesh Gidra wrote:
>>  Its on Linux 3.0.0
>> 
>>  It also causes out of memory at the given configuration, whereas I have 
> successfully managed to complete the test with 4G heap. So not really sure what 
> is causing these deadlocks/OOMs.
> 
> What cause is given for the OOM?? And when you say deadlock,
> are all the threads waiting?? Or are there threads that are
> working but never finish their task?
> 
> Jon
>> 
>>  Lokesh
>> 
>> 
>>>  ________________________________
>>>  From: Jon Masamitsu <jon.masamitsu at oracle.com>
>>>  To: hotspot-gc-dev at openjdk.java.net
>>>  Sent: Wednesday, 24 April 2013 4:16 PM
>>>  Subject: Re: Deadlock while running SPECjbb2013
>>> 
>>> 
>>> 
>>>  I don't think we've seen this.? What OS?
>>> 
>>>  I can create a bug report for this.? Please send the info needed to
>>>  reproduce it.
>>> 
>>>  Thanks.
>>> 
>>>  Jon
>>> 
>>> 
>>>  On 4/23/13 4:59 AM, Lokesh Gidra wrote:
>>> 
>>>  Hello,
>>>> 
>>>>  I am trying to experiment SPECjbb2013 on a 48-core AMD machine with 
> the following command line options on OpenJDK7 build 147:
>>>> 
>>>> 
>>>>  -XX:ParallelGCThreads=46 -Xms8g -Xmx8g -XX:+UseParallelOldGC 
> -XX:+DisableExplicitGC -XX:-UseLargePages -XX:-UseCompressedOops
>>>> 
>>>> 
>>>>  The execution hangs sometimes. When I attached the process to gdb, 
> found that the GC threads are stuck in the marking phase of Old generation 
> collection. The bug also hits with lesser GC threads. I am wondering if this is 
> a known issue.
>>>> 
>>>> 
>>>>  Regards,
>>>>  Lokesh
>>> 
>>> 
> 


From lokesh.gidra at yahoo.com  Thu Apr 25 14:57:39 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Thu, 25 Apr 2013 22:57:39 +0800 (SGT)
Subject: Static variables during marking phase of PSParallelCompact
Message-ID: <1366901859.17412.YahooMailNeo@web190902.mail.sg3.yahoo.com>

Hello,

I am trying to understand the code of PSParallelCompact. I am having hard time understanding, how are the static variables taken into account during the marking phase? There is no root set taken from the permanent generation, where I thought the static variables reside (inside the class objects). Please correct me and guide through right path.

Thanks,
Lokesh



From thomas.schatzl at oracle.com  Thu Apr 25 15:05:12 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 25 Apr 2013 17:05:12 +0200
Subject: Static variables during marking phase of PSParallelCompact
In-Reply-To: <1366901859.17412.YahooMailNeo@web190902.mail.sg3.yahoo.com>
References: <1366901859.17412.YahooMailNeo@web190902.mail.sg3.yahoo.com>
Message-ID: <1366902312.2712.38.camel@cirrus>

Hi,

On Thu, 2013-04-25 at 22:57 +0800, Lokesh Gidra wrote:
> Hello,
> 
> I am trying to understand the code of PSParallelCompact. I am having hard time understanding, how are the static variables taken into account during the marking phase? There is no root set taken from the permanent generation, where I thought the static variables reside (inside the class objects). Please correct me and guide through right path.
> 

In hs21 the static variables moved to the java.lang.Class instances in
the java heap.

(see http://bugs.sun.com/view_bug.do?bug_id=7017732)

Thomas



From bengt.rutisson at oracle.com  Thu Apr 25 15:14:53 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 25 Apr 2013 17:14:53 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <51790ED2.8020407@oracle.com>
References: <51790ED2.8020407@oracle.com>
Message-ID: <5179486D.8010403@oracle.com>


Hi again,

It turns out that the code that I was fixing is actually not in use. 
Thanks Coleen for triggering me to figure that out!

Here is an updated webrev where the code is removed instead:
http://cr.openjdk.java.net/~brutisso/8012915/webrev.01/

Thanks,
Bengt

On 4/25/13 1:09 PM, Bengt Rutisson wrote:
>
> Hi everyone,
>
> Could I have a couple of reviews of this change?
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>
> Background from the CR:
>
> The method ReservedSpace::align_reserved_region() does not work on 
> Windows. It tries to free parts of the previously allocated memory by 
> doing two calls to os::release_memory(). However, on Windows 
> os::release_memory() is implemented as:
>
>  VirtualFree(addr, 0, MEM_RELEASE)
>
> which will always free up all the allocated memory:
>
> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>
>
> "The function frees the entire region that is reserved in the initial 
> allocation call to VirtualAlloc."
>
> This means that if ReservedSpace::align_reserved_region() is executed 
> on Windows and we try to trim the beginning of the memory that we had 
> allocated we will free all of the allocated memory. Subsequent calls 
> to os::commit_memory() which will end up as:
>
> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>
> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
> address.
>
> The solution is to use the existing method 
> os::reserve_memory_aligned() which does the same thing but works on 
> all platforms.
>
> I assume that it is unusual that we enter this code path since I 
> haven't seen a lot of crashes that seem related to this issue. But 
> when we tried a patch that plays a bit with the alignments we crash on 
> Windows. To have a simple reproducer I added a unit test. The test is 
> not 100% fool proof, but on Windows without my proposed fix it fails 
> 999 times out of 1000 runs. With my fix it passes 100% of the time.
>
> Thanks,
> Bengt

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

From jon.masamitsu at oracle.com  Thu Apr 25 15:24:17 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 25 Apr 2013 08:24:17 -0700
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <51791BA0.9070108@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
	<51791BA0.9070108@oracle.com>
Message-ID: <51794AA1.8000803@oracle.com>


On 4/25/2013 5:03 AM, Mikael Gerdin wrote:
> Coleen,
>
> On 04/25/2013 01:57 PM, Coleen Phillimore wrote:
>>
>> Mikael,
>>
>> I believe this change is correct.  I think if we elide safepoint locks
>> for a lock sometimes, we always have to elide safepoint checks for that
>> lock.   David will correct me if I'm wrong.

I think this is a sufficient strategy and it's what I've followed
in the past.

So I agree with the change.

Jon

>
> I also believe that the change is correct.
> And I hope that David will chime in on this one.
>
> /Mikael
>
>>
>> Coleen
>>
>> On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> Problem:
>>> We've seen some hangs in the GC nightly testing recently.
>>> When I looked at the minidump files from some of those hangs they
>>> looked like safepoint deadlocks where one thread was parked in
>>> Mutex::lock_without_safepoint_check on one of the "Metaspace
>>> allocation locks".
>>>
>>> Both of the hangs I investigated also had threads trying to lock the
>>> same Metaspace lock but without eliding safepoint checks because they
>>> were originating from Metaspace::deallocate.
>>>
>>> I believe that since the change to allocate MethodCounters on demand
>>> and potentially deallocating them when racing this issue was brought
>>> to the surface because of more frequent calls to Metaspace::deallocate
>>> when not at a safepoint.
>>>
>>> I was able to reproduce the hang after about an hour by running an
>>> instrumented build where MethodCounters are allocated and then
>>> unconditionally deallocated on each entry to
>>> Method::build_method_counters.
>>>
>>> I can't describe the failure mode in detail since I'm not familiar
>>> with the Mutex code but I can imagine that the locking state machine
>>> is broken when we take completely different code paths for the same
>>> Mutex.
>>>
>>> Suggested fix:
>>> My suggested fix is to change Metaspace::deallocate to take the lock
>>> with Mutex::_no_safepoint_check_flag.
>>>
>>> With my fix I ran the test that managed to reproduce the failure
>>> overnight without reproducing the hang.
>>> I also ran the parallel class loading tests and nashorn's
>>> test262parallel for good measure.
>>>
>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>>> bugs.sun.com: 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>>
>>> /Mikael
>>
>



From jon.masamitsu at oracle.com  Thu Apr 25 15:35:47 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 25 Apr 2013 08:35:47 -0700
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <5179486D.8010403@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179486D.8010403@oracle.com>
Message-ID: <51794D53.10603@oracle.com>

Bengt,

Looks good.  I'm glad I waited for this version of the
change :-)

Jon

On 4/25/2013 8:14 AM, Bengt Rutisson wrote:
>
> Hi again,
>
> It turns out that the code that I was fixing is actually not in use. 
> Thanks Coleen for triggering me to figure that out!
>
> Here is an updated webrev where the code is removed instead:
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.01/
>
> Thanks,
> Bengt
>
> On 4/25/13 1:09 PM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I have a couple of reviews of this change?
>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>
>> Background from the CR:
>>
>> The method ReservedSpace::align_reserved_region() does not work on 
>> Windows. It tries to free parts of the previously allocated memory by 
>> doing two calls to os::release_memory(). However, on Windows 
>> os::release_memory() is implemented as:
>>
>>  VirtualFree(addr, 0, MEM_RELEASE)
>>
>> which will always free up all the allocated memory:
>>
>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>>
>>
>> "The function frees the entire region that is reserved in the initial 
>> allocation call to VirtualAlloc."
>>
>> This means that if ReservedSpace::align_reserved_region() is executed 
>> on Windows and we try to trim the beginning of the memory that we had 
>> allocated we will free all of the allocated memory. Subsequent calls 
>> to os::commit_memory() which will end up as:
>>
>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>
>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
>> address.
>>
>> The solution is to use the existing method 
>> os::reserve_memory_aligned() which does the same thing but works on 
>> all platforms.
>>
>> I assume that it is unusual that we enter this code path since I 
>> haven't seen a lot of crashes that seem related to this issue. But 
>> when we tried a patch that plays a bit with the alignments we crash 
>> on Windows. To have a simple reproducer I added a unit test. The test 
>> is not 100% fool proof, but on Windows without my proposed fix it 
>> fails 999 times out of 1000 runs. With my fix it passes 100% of the 
>> time.
>>
>> Thanks,
>> Bengt
>
>



From lokesh.gidra at yahoo.com  Thu Apr 25 15:38:42 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Thu, 25 Apr 2013 23:38:42 +0800 (SGT)
Subject: Static variables during marking phase of PSParallelCompact
In-Reply-To: <1366902312.2712.38.camel@cirrus>
References: <1366901859.17412.YahooMailNeo@web190902.mail.sg3.yahoo.com>
	<1366902312.2712.38.camel@cirrus>
Message-ID: <1366904322.42505.YahooMailNeo@web190904.mail.sg3.yahoo.com>

OK. Can you please also tell me which particular root type will cover them?

Thanks for you help.

Lokesh




----- Original Message -----
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> To: hotspot-gc-dev at openjdk.java.net
> Cc: 
> Sent: Thursday, 25 April 2013 5:05 PM
> Subject: Re: Static variables during marking phase of PSParallelCompact
> 
> Hi,
> 
> On Thu, 2013-04-25 at 22:57 +0800, Lokesh Gidra wrote:
>>  Hello,
>> 
>>  I am trying to understand the code of PSParallelCompact. I am having hard 
> time understanding, how are the static variables taken into account during the 
> marking phase? There is no root set taken from the permanent generation, where I 
> thought the static variables reside (inside the class objects). Please correct 
> me and guide through right path.
>> 
> 
> In hs21 the static variables moved to the java.lang.Class instances in
> the java heap.
> 
> (see http://bugs.sun.com/view_bug.do?bug_id=7017732)
> 
> Thomas
> 


From thomas.schatzl at oracle.com  Thu Apr 25 15:39:45 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 25 Apr 2013 17:39:45 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <5179486D.8010403@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179486D.8010403@oracle.com>
Message-ID: <1366904385.2712.55.camel@cirrus>

Hi,

On Thu, 2013-04-25 at 17:14 +0200, Bengt Rutisson wrote:
> 
> Hi again,
> 
> It turns out that the code that I was fixing is actually not in use.
> Thanks Coleen for triggering me to figure that out!
> 
> Here is an updated webrev where the code is removed instead:
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.01/

Looks good :)

Thomas





From john.cuthbertson at oracle.com  Thu Apr 25 17:01:46 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 25 Apr 2013 10:01:46 -0700
Subject: RFR(S): 8011898: gc/TestVerifyBeforeGCDuringStartup.java:
	java.lang.RuntimeException
In-Reply-To: <5178CE29.8090807@oracle.com>
References: <5177243D.9030006@oracle.com> <5178CE29.8090807@oracle.com>
Message-ID: <5179617A.60009@oracle.com>

Hi Bengt,

Thanks for looking at the test.

I found the output very useful in confirming your diagnosis of the 
problem. Now imagine someone, who is not as familiar with ProcessBuilder 
as you, would it help them?

Personally I don't have a strong opinion either way - but if I can do 
something so minor now that might save a bit of time later on then why not?

JohnC

On 4/24/2013 11:33 PM, Bengt Rutisson wrote:
>
> Hi John,
>
> This looks good.
>
> A couple of questions:
>
> The test is pretty verbose. Do you really want to keep all the 
> System.out.print-ing?
>
>   51     System.out.print("Testing:\n" + 
> JDKToolFinder.getJDKTool("java"));
>   52     for (int i = 0; i < vmOpts.size(); i += 1) {
>   53       System.out.print(" " + vmOpts.get(i));
>   54     }
>   55     System.out.println();
>
>   61     System.out.println("Output:\n" + output.getOutput());
>
> If you remove the printing at line 51 I guess you can also remove the 
> import of JDKToolsFinder.
>
> Thanks,
> Bengt
>
>
> On 4/24/13 2:15 AM, John Cuthbertson wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers review these changes to the 
>> regression test I added for 8010463 and changed for 8011343? The 
>> webrev can found at: http://cr.openjdk.java.net/~johnc/8011898/webrev.0/
>>
>> Summary:
>> The call to System.getProperty("test.vm.opts") will return null if no 
>> additional vm or java options are passed into jtreg. Hence the first 
>> entry in the String array, that is passed to 
>> createJavaProcessBuilder(), is null. When the null is converted to 
>> options, the first option will be the empty string which the java 
>> launcher interprets as the name of the main class.
>>
>> Many thanks to Bengt for his diagnosis.
>>
>> Notes:
>>
>> In this test I'm using the same mechanism as in Tao's test for 
>> 6761744. His is much nicer than what I came up with. Many tanks to Tao.
>>
>> The test now reads the test.java.opts instead of test.vm.opts after 
>> feedback from SQE.
>>
>> Also I added a couple of prints to test to make it easier to see what 
>> the command line of the child java process actually is and it's 
>> resulting output. In the .jtr file you see something like:
>>
>>> ----------messages:(3/144)----------
>>> command: main TestVerifyDuringStartup
>>> reason: Assumed action based on file name: run main 
>>> TestVerifyDuringStartup
>>> elapsed time (seconds): 0.32
>>> ----------System.out:(8/408)----------
>>> Testing:
>>> /export/jdk8-1/solaris-x64/bin/java -XX:+UseG1GC -XX:-UseTLAB 
>>> -XX:+UnlockDiagnosticVMOptions -XX:+VerifyDuringStartup -version
>>> Output:
>>> [Verifying threads Roots HeapRegionSets HeapRegions RemSet syms strs 
>>> zone dict metaspace chunks hand C-heap code cache ]
>>> java version "1.8.0-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b58)
>>> Java HotSpot(TM) Server VM (build 25.0-b29-internal, mixed mode)
>>>
>>> ----------System.err:(1/15)----------
>>> STATUS:Passed.
>>> result: Passed. Execution successful
>>
>> Thanks,
>>
>> JohnC
>

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

From john.cuthbertson at oracle.com  Thu Apr 25 17:03:24 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 25 Apr 2013 10:03:24 -0700
Subject: Review request: 8013132: Add a flag to turn off the output of
	the verbose verification code
In-Reply-To: <5178D59E.5020908@oracle.com>
References: <5178207E.1080209@oracle.com> <51787FFB.3000103@oracle.com>
	<5178D59E.5020908@oracle.com>
Message-ID: <517961DC.7060800@oracle.com>

Hi Stefan,

Apologies - I wasn't clear. What I meant was: should VerifySilently be 
explicitly disabled  in the test?

JohnC

On 4/25/2013 12:05 AM, Stefan Karlsson wrote:
> On 04/25/2013 02:59 AM, John Cuthbertson wrote:
>> Hi Stefan,
>>
>> Looks fine to me.
>
> Thanks, John.
>
>>
>> One minor point - this will affect the reg test I sent out for review 
>> yesterday which explicitly looks for "[Verifying..."
>
> The flag is off by default, so this will not affect  your test. I've 
> verified this by applying you patch.
>
> thanks,
> StefanK
>
>>
>> JohnC
>>
>> On 4/24/2013 11:12 AM, Stefan Karlsson wrote:
>>> http://cr.openjdk.java.net/~stefank/8013132/webrev.00/
>>>
>>> This RFE adds a new flag named VerifySilently, which can be used to 
>>> turn off the verbose output that the verification code produces. The 
>>> proposed name has been chosen to match other Verify flags.
>>>
>>> From the Bug description:
>>> ---
>>> The HotSpot verification code is rather verbose and intrusive. I 
>>> propose that we add a flag that can be used to turn this output off.
>>>
>>> An example of the verification output:
>>> $ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions 
>>> -XX:+VerifyBeforeExit -XX:+VerifyAfterGC -XX:+VerifyBeforeGC 
>>> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -cp 
>>> /localhome/tests/ HelloSystemGC
>>>  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
>>> generation par new generation remset syms strs zone dict cldg 
>>> metaspace chunks hand C-heap code cache ]
>>> [GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
>>>  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep 
>>> generation par new generation remset syms strs zone dict cldg 
>>> metaspace chunks hand C-heap code cache ]
>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>> C-heap code cache ]
>>> [GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>> C-heap code cache ]
>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>> C-heap code cache ]
>>> [GC (CMS Final Remark) [Verifying CMS Marking... done] 
>>> 1604K(121600K), 0.1008210 secs]
>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>> C-heap code cache ]
>>>
>>> And with the proposed flag turned on:
>>> [GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
>>> [GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
>>> [GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
>>> ---
>>>
>>> thanks,
>>> StefanK
>>
>

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

From thomas.schatzl at oracle.com  Thu Apr 25 17:25:11 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 25 Apr 2013 19:25:11 +0200
Subject: Static variables during marking phase of PSParallelCompact
In-Reply-To: <1366904322.42505.YahooMailNeo@web190904.mail.sg3.yahoo.com>
References: <1366901859.17412.YahooMailNeo@web190902.mail.sg3.yahoo.com>
	<1366902312.2712.38.camel@cirrus>
	<1366904322.42505.YahooMailNeo@web190904.mail.sg3.yahoo.com>
Message-ID: <1366910711.2732.6.camel@cirrus>

Hi,

On Thu, 2013-04-25 at 23:38 +0800, Lokesh Gidra wrote:
> OK. Can you please also tell me which particular root type will cover them?

There is no direct "root type": they are probably most directly
reachable via the java.lang.Class instances when iterating over the
ClassLoaderDataGraph; search for ClassLoaderDataGraph::oops_do() and
ClassLoaderDataGraph::always_strong_oops_do(). I.e. the _class_loader
member of the ClassLoaderData class.

If your question is during which root scanning task the CLDG will be
iterated, it's the SH_PS_SystemDictionary_oops_do task. See also
SharedHeap::process_strong_roots().

The code that finds the static members within a java.lang.Class instance
is in instanceMirrorKlass.?pp.

Hth,
  Thomas




From john.cuthbertson at oracle.com  Thu Apr 25 17:35:22 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Thu, 25 Apr 2013 10:35:22 -0700
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <5179486D.8010403@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179486D.8010403@oracle.com>
Message-ID: <5179695A.308@oracle.com>

Hi Bengt,

This looks good to me.

Thanks for the explanation regarding hs24 and hs25.

JohnC

On 4/25/2013 8:14 AM, Bengt Rutisson wrote:
>
> Hi again,
>
> It turns out that the code that I was fixing is actually not in use. 
> Thanks Coleen for triggering me to figure that out!
>
> Here is an updated webrev where the code is removed instead:
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.01/
>
> Thanks,
> Bengt
>
> On 4/25/13 1:09 PM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I have a couple of reviews of this change?
>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>
>> Background from the CR:
>>
>> The method ReservedSpace::align_reserved_region() does not work on 
>> Windows. It tries to free parts of the previously allocated memory by 
>> doing two calls to os::release_memory(). However, on Windows 
>> os::release_memory() is implemented as:
>>
>>  VirtualFree(addr, 0, MEM_RELEASE)
>>
>> which will always free up all the allocated memory:
>>
>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>>
>>
>> "The function frees the entire region that is reserved in the initial 
>> allocation call to VirtualAlloc."
>>
>> This means that if ReservedSpace::align_reserved_region() is executed 
>> on Windows and we try to trim the beginning of the memory that we had 
>> allocated we will free all of the allocated memory. Subsequent calls 
>> to os::commit_memory() which will end up as:
>>
>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>
>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid 
>> address.
>>
>> The solution is to use the existing method 
>> os::reserve_memory_aligned() which does the same thing but works on 
>> all platforms.
>>
>> I assume that it is unusual that we enter this code path since I 
>> haven't seen a lot of crashes that seem related to this issue. But 
>> when we tried a patch that plays a bit with the alignments we crash 
>> on Windows. To have a simple reproducer I added a unit test. The test 
>> is not 100% fool proof, but on Windows without my proposed fix it 
>> fails 999 times out of 1000 runs. With my fix it passes 100% of the time.
>>
>> Thanks,
>> Bengt
>

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

From jon.masamitsu at oracle.com  Thu Apr 25 17:43:30 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 25 Apr 2013 10:43:30 -0700
Subject: Request for review - 8013032 - CMS: assert(used() == used_after_gc
	&& used_after_gc <= capacity()) failed
Message-ID: <51796B42.4080405@oracle.com>

CMS: assert(used() == used_after_gc && used_after_gc <= capacity()) 
failed: used: 0 used_after_gc: 292080 capacity: 1431699456

The assertion was incorrect so I deleted it.  The assumption that the
metrics being tested should not be affected by the reset_after_compaction()
was incorrect.

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


From jon.masamitsu at oracle.com  Thu Apr 25 19:32:47 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 25 Apr 2013 12:32:47 -0700
Subject: Request for review - 8013184 CMS: Call reset_after_compaction() only
	if a compaction has been done
Message-ID: <517984DF.6020108@oracle.com>

8013184: CMS: Call reset_after_compaction() only if a compaction has been done

When a System.gc() is done with -XX:-UseCMSCompactAtFullCollection, a 
mark-sweep
without compaction is done.  In that instance the call to 
reset_after_compaction() is
not appropriate.

This changeset is built on top of the changeset for 8013032

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


From coleen.phillimore at oracle.com  Thu Apr 25 21:47:26 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 25 Apr 2013 17:47:26 -0400
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <51791C94.7070604@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com>
Message-ID: <5179A46E.9070605@oracle.com>


Hi, Sorry Stefan I think I liked your .00 version better.   Now there's 
a level of indirection and it doesn't seem to save any code because the 
call sites are slightly different.

Coleen

On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>
>>>> Stefan,
>>>>
>>>> Is there a common place for this code?
>>>
>>> I don't think there's any common place in the GCs for this. I'm open 
>>> for suggestions if you know a good place in the runtime code.
>>
>> memory/genCollectedHeap?   I have no idea...
>>>
>>>> It's 4 copies of the similar code, which takes me a while to find 
>>>> when I set out looking for it.
>>>
>>> Yes, I tried to make them look alike so that we/I have an 
>>> opportunity to extract it out to one function. The fact that CMS 
>>> does this differently made me hesitant to combine them.
>>>
>>>> In the future, I think StringTable::unlink() could be moved after 
>>>> CLDG::purge() which I thought should be around here too (but it's 
>>>> not).   The only reason StringTable::unlink() used to be here was 
>>>> because it used to have Oops in it.
>>>
>>> Don't you mean the SymbolTable? I'm OK with moving the SymbolTable, 
>>> but not the StringTable ...
>>
>> I did mean SymbolTable.
>>
>>>
>>>>    Can you unite this duplicated code?
>>>
>>> It's easy to unit the code for psMarkSweep, genMarkSweep, 
>>> g1MarkSweep and psParallelCompact but it's a bit more work to also 
>>> unify the CMS code. Would it be good enough for this patch if I 
>>> united the former GCs? And maybe handle CMS when G1 also starts 
>>> doing class unloading?
>>
>> Ok, keep it in mind for future work.  It would be nice to have the 
>> runtime GC things be called in one place or easy to find.
>>
>> I semi-reviewed the code and except for the GC part (which is most of 
>> the change).   We don't pass the keep_alive closure anymore for 
>> compiledICHolders so I guess this makes sense if this is what the 
>> keep_alive closure did.   So this is a partial review.
>
> I've update the patch to gather the unloading code in a helper class 
> called GCUnloading. What do you think?
>
> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>
> thanks,
> StefanK
>
>>
>> Thanks,
>> Coleen
>>>
>>> thanks,
>>> StefanK
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>
>>>>> There's some remnants from the PermGen that's confusing in the 
>>>>> class unloading code. This patch removes the unnecessary code, 
>>>>> cleans up some comments and unifies the code structure over 
>>>>> different GCs.
>>>>>
>>>>> From the Bug report:
>>>>> ---
>>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>>> objects to C++ objects.
>>>>>
>>>>> CodeCache::do_unloading(...) used to take a keep_alive closure 
>>>>> that was applied to CompiledICHolders deep down in 
>>>>> nmethod::do_unloading. Since CompileICHolders don't move anymore, 
>>>>> and we have other ways to keep them alive, we don't use the 
>>>>> keep_alive closures in these functions anymore.
>>>>>
>>>>> Because of this, CodeCache::do_unloading will not populate the 
>>>>> marking stacks, and we can remove the call to drain the stacks 
>>>>> after the calls to CodeCache::do_unloading.
>>>>>
>>>>> This also has the neat effect that we now can verify that the 
>>>>> marking has really completed before we start unloading classes, 
>>>>> which makes the code easier to maintain/understand.
>>>>> ---
>>>>>
>>>>> thanks,
>>>>> StefanK
>>>>
>>>
>>
>

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

From yumin.qi at oracle.com  Fri Apr 26 06:48:54 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 25 Apr 2013 23:48:54 -0700
Subject: RFR: 8012902: remove use of global operator new - take 2
Message-ID: <517A2356.1060606@oracle.com>

HI, all

   This bug is filed after this bug
   8010992: Remove calls to global ::operator new[] and new
   was anti-delta'ed due to testing failure on JVMTI. Now it takes both.

   http://cr.openjdk.java.net/~minqi/8012902/webrev/

   ObjectMonitor is an class which should not inherit from any class, 
but is has subclass in Jvmti, JvmtiRawMonitor. In previous changeset, 
ObjectMonitor is created through NEW_C_HEAP_OBJ/ARRAY macros, but 
JvmtiRawMonitor was missed. This is why when it is 'new'ed failed on 
disabled global operator new in debug mode. To prevent using more 
complex form of marco NEW_C_HEAP_OBJ/ARRAY operator new and new[] added 
to ObjectMonitor so JvmtiRawMonitor will inherit for them.

   HandleMark should be a StackObj but we create the first one in Thread 
ctor in heap, so it did not have StackObj as parent. Added oerator new 
and new [] to it though in fact it is  used as StackObj. Same treatment 
for MemRegion too, it is an _ValueObj (in Linux, it did not inherit from 
any). Adding operator new and new[] is mainly avoid using macro 
involving alloc/dealloc and ctor/dtor complexity.

   The make files, vm.make and fastdebug.make  changed under BSD is for 
one problem which is not clear: jdk code called operator new in hotspot 
library. This only happens on Darwin. Exposure of 
CATCH_OPERATOR_NEW_USAGE giving an warning when first time global 
operator new and new [] called.

   Tested with JPRT, vm.quick, jtreg.

   Thanks
   Yumin


From lokesh.gidra at yahoo.com  Fri Apr 26 07:45:56 2013
From: lokesh.gidra at yahoo.com (Lokesh Gidra)
Date: Fri, 26 Apr 2013 15:45:56 +0800 (SGT)
Subject: Static variables during marking phase of PSParallelCompact
In-Reply-To: <1366910711.2732.6.camel@cirrus>
References: <1366901859.17412.YahooMailNeo@web190902.mail.sg3.yahoo.com>
	<1366902312.2712.38.camel@cirrus>
	<1366904322.42505.YahooMailNeo@web190904.mail.sg3.yahoo.com>
	<1366910711.2732.6.camel@cirrus>
Message-ID: <1366962356.64397.YahooMailNeo@web190905.mail.sg3.yahoo.com>

Thanks a lot. This is exactly what I was looking for.

Regards,
Lokesh



----- Original Message -----
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> To: Lokesh Gidra <lokesh.gidra at yahoo.com>
> Cc: "hotspot-gc-dev at openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>
> Sent: Thursday, 25 April 2013 7:25 PM
> Subject: Re: Static variables during marking phase of PSParallelCompact
> 
> Hi,
> 
> On Thu, 2013-04-25 at 23:38 +0800, Lokesh Gidra wrote:
>>  OK. Can you please also tell me which particular root type will cover them?
> 
> There is no direct "root type": they are probably most directly
> reachable via the java.lang.Class instances when iterating over the
> ClassLoaderDataGraph; search for ClassLoaderDataGraph::oops_do() and
> ClassLoaderDataGraph::always_strong_oops_do(). I.e. the _class_loader
> member of the ClassLoaderData class.
> 
> If your question is during which root scanning task the CLDG will be
> iterated, it's the SH_PS_SystemDictionary_oops_do task. See also
> SharedHeap::process_strong_roots().
> 
> The code that finds the static members within a java.lang.Class instance
> is in instanceMirrorKlass.?pp.
> 
> Hth,
> ? Thomas
> 


From thomas.schatzl at oracle.com  Fri Apr 26 07:48:33 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 26 Apr 2013 09:48:33 +0200
Subject: RFR: 8012902: remove use of global operator new - take 2
In-Reply-To: <517A2356.1060606@oracle.com>
References: <517A2356.1060606@oracle.com>
Message-ID: <1366962513.2808.9.camel@cirrus>

Hi,

On Thu, 2013-04-25 at 23:48 -0700, Yumin Qi wrote:
> HI, all
> 
>    This bug is filed after this bug
>    8010992: Remove calls to global ::operator new[] and new
>    was anti-delta'ed due to testing failure on JVMTI. Now it takes both.
> 
>    http://cr.openjdk.java.net/~minqi/8012902/webrev/


The allocation in

./src/share/vm/gc_implementation/g1/g1RemSet.cpp:    ct_freq = new
jbyte[ct_freq_sz];

seems to have been overlooked. It's in some debug code that is never
used at the moment.

(I used an "egrep "new .*\[.+\]" `find . -name '*.?pp'`" to find that).

Could you fix that one too?

Thanks,
Thomas




From mikael.gerdin at oracle.com  Fri Apr 26 07:48:52 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 26 Apr 2013 09:48:52 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <5179486D.8010403@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179486D.8010403@oracle.com>
Message-ID: <517A3164.6000907@oracle.com>

Bengt,

On 2013-04-25 17:14, Bengt Rutisson wrote:
>
> Hi again,
>
> It turns out that the code that I was fixing is actually not in use.
> Thanks Coleen for triggering me to figure that out!
>
> Here is an updated webrev where the code is removed instead:
> http://cr.openjdk.java.net/~brutisso/8012915/webrev.01/

This version looks even better.

/m

>
> Thanks,
> Bengt
>
> On 4/25/13 1:09 PM, Bengt Rutisson wrote:
>>
>> Hi everyone,
>>
>> Could I have a couple of reviews of this change?
>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>
>> Background from the CR:
>>
>> The method ReservedSpace::align_reserved_region() does not work on
>> Windows. It tries to free parts of the previously allocated memory by
>> doing two calls to os::release_memory(). However, on Windows
>> os::release_memory() is implemented as:
>>
>>  VirtualFree(addr, 0, MEM_RELEASE)
>>
>> which will always free up all the allocated memory:
>>
>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx
>>
>>
>> "The function frees the entire region that is reserved in the initial
>> allocation call to VirtualAlloc."
>>
>> This means that if ReservedSpace::align_reserved_region() is executed
>> on Windows and we try to trim the beginning of the memory that we had
>> allocated we will free all of the allocated memory. Subsequent calls
>> to os::commit_memory() which will end up as:
>>
>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>
>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid
>> address.
>>
>> The solution is to use the existing method
>> os::reserve_memory_aligned() which does the same thing but works on
>> all platforms.
>>
>> I assume that it is unusual that we enter this code path since I
>> haven't seen a lot of crashes that seem related to this issue. But
>> when we tried a patch that plays a bit with the alignments we crash on
>> Windows. To have a simple reproducer I added a unit test. The test is
>> not 100% fool proof, but on Windows without my proposed fix it fails
>> 999 times out of 1000 runs. With my fix it passes 100% of the time.
>>
>> Thanks,
>> Bengt
>


From bengt.rutisson at oracle.com  Fri Apr 26 08:01:43 2013
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 26 Apr 2013 10:01:43 +0200
Subject: RFR (M): 8012915: ReservedSpace::align_reserved_region() broken
	on Windows
In-Reply-To: <517A3164.6000907@oracle.com>
References: <51790ED2.8020407@oracle.com> <5179486D.8010403@oracle.com>
	<517A3164.6000907@oracle.com>
Message-ID: <517A3467.4060707@oracle.com>


Thanks, Mikael, John, Jon and Thomas for the reviews!

Bengt

On 4/26/13 9:48 AM, Mikael Gerdin wrote:
> Bengt,
>
> On 2013-04-25 17:14, Bengt Rutisson wrote:
>>
>> Hi again,
>>
>> It turns out that the code that I was fixing is actually not in use.
>> Thanks Coleen for triggering me to figure that out!
>>
>> Here is an updated webrev where the code is removed instead:
>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.01/
>
> This version looks even better.
>
> /m
>
>>
>> Thanks,
>> Bengt
>>
>> On 4/25/13 1:09 PM, Bengt Rutisson wrote:
>>>
>>> Hi everyone,
>>>
>>> Could I have a couple of reviews of this change?
>>> http://cr.openjdk.java.net/~brutisso/8012915/webrev.00/
>>>
>>> Background from the CR:
>>>
>>> The method ReservedSpace::align_reserved_region() does not work on
>>> Windows. It tries to free parts of the previously allocated memory by
>>> doing two calls to os::release_memory(). However, on Windows
>>> os::release_memory() is implemented as:
>>>
>>>  VirtualFree(addr, 0, MEM_RELEASE)
>>>
>>> which will always free up all the allocated memory:
>>>
>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/aa366892%28v=vs.85%29.aspx 
>>>
>>>
>>>
>>> "The function frees the entire region that is reserved in the initial
>>> allocation call to VirtualAlloc."
>>>
>>> This means that if ReservedSpace::align_reserved_region() is executed
>>> on Windows and we try to trim the beginning of the memory that we had
>>> allocated we will free all of the allocated memory. Subsequent calls
>>> to os::commit_memory() which will end up as:
>>>
>>> VirtualAlloc(addr, bytes, MEM_COMMIT, PAGE_READWRITE)
>>>
>>> will fail with 487, ERROR_INVALID_ADDRESS - Attempt to access invalid
>>> address.
>>>
>>> The solution is to use the existing method
>>> os::reserve_memory_aligned() which does the same thing but works on
>>> all platforms.
>>>
>>> I assume that it is unusual that we enter this code path since I
>>> haven't seen a lot of crashes that seem related to this issue. But
>>> when we tried a patch that plays a bit with the alignments we crash on
>>> Windows. To have a simple reproducer I added a unit test. The test is
>>> not 100% fool proof, but on Windows without my proposed fix it fails
>>> 999 times out of 1000 runs. With my fix it passes 100% of the time.
>>>
>>> Thanks,
>>> Bengt
>>



From stefan.karlsson at oracle.com  Fri Apr 26 08:15:00 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 26 Apr 2013 10:15:00 +0200
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <5179A46E.9070605@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com> <5179A46E.9070605@oracle.com>
Message-ID: <517A3784.1060701@oracle.com>

On 04/25/2013 11:47 PM, Coleen Phillimore wrote:
>
> Hi, Sorry Stefan I think I liked your .00 version better.   Now 
> there's a level of indirection and it doesn't seem to save any code 
> because the call sites are slightly different.

It only saves code duplication in four of the collectors, the other two 
still does the unloading differently.

Could someone else review the .00 version?
http://cr.openjdk.java.net/~stefank/8013160/webrev.00/

thanks,
StefanK

>
> Coleen
>
> On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
>> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Is there a common place for this code?
>>>>
>>>> I don't think there's any common place in the GCs for this. I'm 
>>>> open for suggestions if you know a good place in the runtime code.
>>>
>>> memory/genCollectedHeap?   I have no idea...
>>>>
>>>>> It's 4 copies of the similar code, which takes me a while to find 
>>>>> when I set out looking for it.
>>>>
>>>> Yes, I tried to make them look alike so that we/I have an 
>>>> opportunity to extract it out to one function. The fact that CMS 
>>>> does this differently made me hesitant to combine them.
>>>>
>>>>> In the future, I think StringTable::unlink() could be moved after 
>>>>> CLDG::purge() which I thought should be around here too (but it's 
>>>>> not).   The only reason StringTable::unlink() used to be here was 
>>>>> because it used to have Oops in it.
>>>>
>>>> Don't you mean the SymbolTable? I'm OK with moving the SymbolTable, 
>>>> but not the StringTable ...
>>>
>>> I did mean SymbolTable.
>>>
>>>>
>>>>>    Can you unite this duplicated code?
>>>>
>>>> It's easy to unit the code for psMarkSweep, genMarkSweep, 
>>>> g1MarkSweep and psParallelCompact but it's a bit more work to also 
>>>> unify the CMS code. Would it be good enough for this patch if I 
>>>> united the former GCs? And maybe handle CMS when G1 also starts 
>>>> doing class unloading?
>>>
>>> Ok, keep it in mind for future work.  It would be nice to have the 
>>> runtime GC things be called in one place or easy to find.
>>>
>>> I semi-reviewed the code and except for the GC part (which is most 
>>> of the change).   We don't pass the keep_alive closure anymore for 
>>> compiledICHolders so I guess this makes sense if this is what the 
>>> keep_alive closure did.   So this is a partial review.
>>
>> I've update the patch to gather the unloading code in a helper class 
>> called GCUnloading. What do you think?
>>
>> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>>
>> thanks,
>> StefanK
>>
>>>
>>> Thanks,
>>> Coleen
>>>>
>>>> thanks,
>>>> StefanK
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>>
>>>>>> There's some remnants from the PermGen that's confusing in the 
>>>>>> class unloading code. This patch removes the unnecessary code, 
>>>>>> cleans up some comments and unifies the code structure over 
>>>>>> different GCs.
>>>>>>
>>>>>> From the Bug report:
>>>>>> ---
>>>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>>>> objects to C++ objects.
>>>>>>
>>>>>> CodeCache::do_unloading(...) used to take a keep_alive closure 
>>>>>> that was applied to CompiledICHolders deep down in 
>>>>>> nmethod::do_unloading. Since CompileICHolders don't move anymore, 
>>>>>> and we have other ways to keep them alive, we don't use the 
>>>>>> keep_alive closures in these functions anymore.
>>>>>>
>>>>>> Because of this, CodeCache::do_unloading will not populate the 
>>>>>> marking stacks, and we can remove the call to drain the stacks 
>>>>>> after the calls to CodeCache::do_unloading.
>>>>>>
>>>>>> This also has the neat effect that we now can verify that the 
>>>>>> marking has really completed before we start unloading classes, 
>>>>>> which makes the code easier to maintain/understand.
>>>>>> ---
>>>>>>
>>>>>> thanks,
>>>>>> StefanK
>>>>>
>>>>
>>>
>>
>

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

From mikael.gerdin at oracle.com  Fri Apr 26 08:34:52 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 26 Apr 2013 10:34:52 +0200
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <517A3784.1060701@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com> <5179A46E.9070605@oracle.com>
	<517A3784.1060701@oracle.com>
Message-ID: <517A3C2C.30105@oracle.com>

Stefan,

On 2013-04-26 10:15, Stefan Karlsson wrote:
> On 04/25/2013 11:47 PM, Coleen Phillimore wrote:
>>
>> Hi, Sorry Stefan I think I liked your .00 version better.   Now
>> there's a level of indirection and it doesn't seem to save any code
>> because the call sites are slightly different.
>
> It only saves code duplication in four of the collectors, the other two
> still does the unloading differently.
>
> Could someone else review the .00 version?
> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/

It looks good to me.

/Mikael


>
> thanks,
> StefanK
>
>>
>> Coleen
>>
>> On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
>>> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>>>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Stefan,
>>>>>>
>>>>>> Is there a common place for this code?
>>>>>
>>>>> I don't think there's any common place in the GCs for this. I'm
>>>>> open for suggestions if you know a good place in the runtime code.
>>>>
>>>> memory/genCollectedHeap?   I have no idea...
>>>>>
>>>>>> It's 4 copies of the similar code, which takes me a while to find
>>>>>> when I set out looking for it.
>>>>>
>>>>> Yes, I tried to make them look alike so that we/I have an
>>>>> opportunity to extract it out to one function. The fact that CMS
>>>>> does this differently made me hesitant to combine them.
>>>>>
>>>>>> In the future, I think StringTable::unlink() could be moved after
>>>>>> CLDG::purge() which I thought should be around here too (but it's
>>>>>> not).   The only reason StringTable::unlink() used to be here was
>>>>>> because it used to have Oops in it.
>>>>>
>>>>> Don't you mean the SymbolTable? I'm OK with moving the SymbolTable,
>>>>> but not the StringTable ...
>>>>
>>>> I did mean SymbolTable.
>>>>
>>>>>
>>>>>>    Can you unite this duplicated code?
>>>>>
>>>>> It's easy to unit the code for psMarkSweep, genMarkSweep,
>>>>> g1MarkSweep and psParallelCompact but it's a bit more work to also
>>>>> unify the CMS code. Would it be good enough for this patch if I
>>>>> united the former GCs? And maybe handle CMS when G1 also starts
>>>>> doing class unloading?
>>>>
>>>> Ok, keep it in mind for future work.  It would be nice to have the
>>>> runtime GC things be called in one place or easy to find.
>>>>
>>>> I semi-reviewed the code and except for the GC part (which is most
>>>> of the change).   We don't pass the keep_alive closure anymore for
>>>> compiledICHolders so I guess this makes sense if this is what the
>>>> keep_alive closure did.   So this is a partial review.
>>>
>>> I've update the patch to gather the unloading code in a helper class
>>> called GCUnloading. What do you think?
>>>
>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>>>
>>> thanks,
>>> StefanK
>>>
>>>>
>>>> Thanks,
>>>> Coleen
>>>>>
>>>>> thanks,
>>>>> StefanK
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>>>
>>>>>>> There's some remnants from the PermGen that's confusing in the
>>>>>>> class unloading code. This patch removes the unnecessary code,
>>>>>>> cleans up some comments and unifies the code structure over
>>>>>>> different GCs.
>>>>>>>
>>>>>>> From the Bug report:
>>>>>>> ---
>>>>>>> The PermGen Removal changed CompiledICHolders from being Java
>>>>>>> objects to C++ objects.
>>>>>>>
>>>>>>> CodeCache::do_unloading(...) used to take a keep_alive closure
>>>>>>> that was applied to CompiledICHolders deep down in
>>>>>>> nmethod::do_unloading. Since CompileICHolders don't move anymore,
>>>>>>> and we have other ways to keep them alive, we don't use the
>>>>>>> keep_alive closures in these functions anymore.
>>>>>>>
>>>>>>> Because of this, CodeCache::do_unloading will not populate the
>>>>>>> marking stacks, and we can remove the call to drain the stacks
>>>>>>> after the calls to CodeCache::do_unloading.
>>>>>>>
>>>>>>> This also has the neat effect that we now can verify that the
>>>>>>> marking has really completed before we start unloading classes,
>>>>>>> which makes the code easier to maintain/understand.
>>>>>>> ---
>>>>>>>
>>>>>>> thanks,
>>>>>>> StefanK
>>>>>>
>>>>>
>>>>
>>>
>>
>


From david.holmes at oracle.com  Fri Apr 26 10:00:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Apr 2013 20:00:38 +1000
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <51791BA0.9070108@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
	<51791BA0.9070108@oracle.com>
Message-ID: <517A5046.4080702@oracle.com>

On 25/04/2013 10:03 PM, Mikael Gerdin wrote:
> On 04/25/2013 01:57 PM, Coleen Phillimore wrote:
>>
>> I believe this change is correct.  I think if we elide safepoint locks
>> for a lock sometimes, we always have to elide safepoint checks for that
>> lock.   David will correct me if I'm wrong.
>
> I also believe that the change is correct.
> And I hope that David will chime in on this one.

Well .... I think that is accurate though I haven't quite seen it stated 
that way. The ability to lock without a safepoint check depends, as far 
as I understand it (and I'm rusty on the details, and the details are 
complex) on the threads using the lock (and their state) and whether the 
lock may be needed by the VMThread during a safepoint.

Really to see what is going wrong I need to see the stacks of the 
threads when the deadlock occurs, else it is just speculation as to what 
might have gone wrong. There is a hint (a strong one) in mutex.cpp:

// Lock without safepoint check - a degenerate variant of lock().
// Should ONLY be used by safepoint code and other code
// that is guaranteed not to block while running inside the VM. If this 
is called with
// thread state set to be in VM, the safepoint synchronization code will 
deadlock!

If a mutator tries to lock without a safepoint check and the lock is 
held, the thread will block but remain in the _thread_in_vm state. If a 
safepoint commences during that time the lock owner will not be able to 
release the lock if it hits a safepoint check first. Meanwhile the 
VMThread will be waiting for the blocked thread to reach a safepoint 
safe state - which it never will as it is physically blocked while still 
_thread_in_vm. Hence deadlock.

So the current change to check for safepoints is undoubtedly a safe 
alternative.

Now an interesting thing with these changes is that one only applies to 
the VMThread - so what does presence or absence of a safepoint check 
mean for the VMThread itself? There is only one difference in that case: 
locking with a safepoint check allows "lock sneaking". But I don't think 
I need to expand on that here - see mutex.cpp.

But this does raise a follow on concern: when the thread is not the 
VMThread, can it hit a safepoint or otherwise block in the region whilst 
holding the Metaspace lock? If the answer is yes then we still have a 
potential safepoint deadlock because the VMThread will not be able to 
acquire the lock during the safepoint VM_operation and will block.

Aside: this also makes me wonder about the safety of other 
lock-without-safepoint-check usages.


David
-----

> /Mikael
>
>>
>> Coleen
>>
>> On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
>>> Hi,
>>>
>>> Problem:
>>> We've seen some hangs in the GC nightly testing recently.
>>> When I looked at the minidump files from some of those hangs they
>>> looked like safepoint deadlocks where one thread was parked in
>>> Mutex::lock_without_safepoint_check on one of the "Metaspace
>>> allocation locks".
>>>
>>> Both of the hangs I investigated also had threads trying to lock the
>>> same Metaspace lock but without eliding safepoint checks because they
>>> were originating from Metaspace::deallocate.
>>>
>>> I believe that since the change to allocate MethodCounters on demand
>>> and potentially deallocating them when racing this issue was brought
>>> to the surface because of more frequent calls to Metaspace::deallocate
>>> when not at a safepoint.
>>>
>>> I was able to reproduce the hang after about an hour by running an
>>> instrumented build where MethodCounters are allocated and then
>>> unconditionally deallocated on each entry to
>>> Method::build_method_counters.
>>>
>>> I can't describe the failure mode in detail since I'm not familiar
>>> with the Mutex code but I can imagine that the locking state machine
>>> is broken when we take completely different code paths for the same
>>> Mutex.
>>>
>>> Suggested fix:
>>> My suggested fix is to change Metaspace::deallocate to take the lock
>>> with Mutex::_no_safepoint_check_flag.
>>>
>>> With my fix I ran the test that managed to reproduce the failure
>>> overnight without reproducing the hang.
>>> I also ran the parallel class loading tests and nashorn's
>>> test262parallel for good measure.
>>>
>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>>> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>>
>>> /Mikael
>>
>


From john.coomes at oracle.com  Fri Apr 26 10:59:59 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 10:59:59 +0000
Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b87 for changeset
	f1709874d55a
Message-ID: <20130426110002.DD8584861F@hg.openjdk.java.net>

Changeset: 4e3a881ebb1e
Author:    katleman
Date:      2013-04-25 09:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/4e3a881ebb1e

Added tag jdk8-b87 for changeset f1709874d55a

! .hgtags



From bengt.rutisson at oracle.com  Fri Apr 26 10:59:11 2013
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Fri, 26 Apr 2013 10:59:11 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8012915:
	ReservedSpace::align_reserved_region() broken on Windows
Message-ID: <20130426105919.3AAE94861D@hg.openjdk.java.net>

Changeset: b294421fa3c5
Author:    brutisso
Date:      2013-04-26 09:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b294421fa3c5

8012915: ReservedSpace::align_reserved_region() broken on Windows
Summary: remove unused constructors and helper methods for ReservedHeapSpace and ReservedSpace
Reviewed-by: mgerdin, jmasa, johnc, tschatzl

! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp



From john.coomes at oracle.com  Fri Apr 26 10:59:55 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 10:59:55 +0000
Subject: hg: hsx/hotspot-gc: 6 new changesets
Message-ID: <20130426105955.ADA694861E@hg.openjdk.java.net>

Changeset: 7da551071fe8
Author:    lana
Date:      2013-04-11 19:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/7da551071fe8

Merge

! common/makefiles/Main.gmk

Changeset: b95c5c8ee60a
Author:    jgish
Date:      2013-04-16 13:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b95c5c8ee60a

8011347: JKD-8009824 has broken webrev with some ksh versions
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Changeset: 2600c8d8b619
Author:    lana
Date:      2013-04-17 10:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2600c8d8b619

Merge


Changeset: 238b28991d66
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/238b28991d66

Merge


Changeset: b9415faa7066
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b9415faa7066

Merge


Changeset: c29b583938b1
Author:    katleman
Date:      2013-04-25 09:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/rev/c29b583938b1

Added tag jdk8-b87 for changeset b9415faa7066

! .hgtags



From john.coomes at oracle.com  Fri Apr 26 11:00:10 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 11:00:10 +0000
Subject: hg: hsx/hotspot-gc/jaxp: 4 new changesets
Message-ID: <20130426110027.4EC2648620@hg.openjdk.java.net>

Changeset: 10db50a26b39
Author:    joehw
Date:      2013-02-18 11:33 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/10db50a26b39

6657673: Issues with JAXP
Reviewed-by: alanb, lancea, ahgross, mullan

! src/com/sun/org/apache/bcel/internal/classfile/JavaClass.java
! src/com/sun/org/apache/bcel/internal/util/Class2HTML.java
! src/com/sun/org/apache/bcel/internal/util/ClassPath.java
! src/com/sun/org/apache/bcel/internal/util/JavaWrapper.java
+ src/com/sun/org/apache/bcel/internal/util/SecuritySupport.java
! src/com/sun/org/apache/xalan/internal/res/XSLMessages.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java
! src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java
! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
! src/com/sun/org/apache/xalan/internal/xslt/Process.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java
! src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java
! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java
! src/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java
! src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java
! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java
! src/com/sun/org/apache/xml/internal/dtm/DTMManager.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java
! src/com/sun/org/apache/xml/internal/res/XMLMessages.java
! src/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java
! src/com/sun/org/apache/xml/internal/resolver/Resolver.java
! src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java
! src/com/sun/org/apache/xml/internal/serializer/Encodings.java
! src/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java
! src/com/sun/org/apache/xml/internal/serializer/ToStream.java
! src/com/sun/org/apache/xml/internal/serializer/TreeWalker.java
! src/com/sun/org/apache/xml/internal/serializer/utils/Messages.java
! src/com/sun/org/apache/xml/internal/utils/TreeWalker.java
! src/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java
! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java
! src/com/sun/org/apache/xpath/internal/res/XPATHMessages.java
! src/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/com/sun/xml/internal/stream/writers/WriterUtility.java
! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java
! src/javax/xml/datatype/FactoryFinder.java
! src/javax/xml/parsers/FactoryFinder.java
! src/javax/xml/stream/FactoryFinder.java
! src/javax/xml/transform/FactoryFinder.java
! src/javax/xml/validation/SchemaFactoryFinder.java
! src/javax/xml/xpath/XPathFactoryFinder.java
! src/org/w3c/dom/bootstrap/DOMImplementationRegistry.java
! src/org/xml/sax/helpers/NewInstance.java
! src/org/xml/sax/helpers/ParserAdapter.java
! src/org/xml/sax/helpers/ParserFactory.java
+ src/org/xml/sax/helpers/SecuritySupport.java
! src/org/xml/sax/helpers/XMLReaderFactory.java

Changeset: 3f9817b8b0e0
Author:    chegar
Date:      2013-04-12 10:20 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/3f9817b8b0e0

Merge


Changeset: eddbc8ad2435
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/eddbc8ad2435

Merge


Changeset: 7122f7bb0fcc
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/7122f7bb0fcc

Added tag jdk8-b87 for changeset eddbc8ad2435

! .hgtags



From john.coomes at oracle.com  Fri Apr 26 11:00:33 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 11:00:33 +0000
Subject: hg: hsx/hotspot-gc/jaxws: 5 new changesets
Message-ID: <20130426110047.8F5DE48621@hg.openjdk.java.net>

Changeset: 28886cb008bb
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/28886cb008bb

Merge


Changeset: ebbd87e3a8b2
Author:    lana
Date:      2013-04-17 10:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/ebbd87e3a8b2

Merge


Changeset: 9d251e1ec1eb
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/9d251e1ec1eb

Merge


Changeset: 72e03566f0a6
Author:    katleman
Date:      2013-04-23 18:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/72e03566f0a6

8012643: JDK8 b86 source with GPL header errors
Reviewed-by: dholmes, alanb

! src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyle.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyleFeature.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/Databinding.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingFactory.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingMode.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingModeFeature.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/JavaCallInfo.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLGenerator.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLResolver.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BaseDistributedPropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BasePropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ContentType.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/DistributedPropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContext.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/PropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ReadOnlyPropertyException.java
! src/share/jaxws_classes/com/oracle/webservices/internal/impl/encoding/StreamDecoderImpl.java
! src/share/jaxws_classes/com/oracle/webservices/internal/impl/internalspi/encoding/StreamDecoder.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ExistingAnnotationsType.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaMethod.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaParam.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaWsdlMappingType.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ObjectFactory.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingParameterStyle.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingStyle.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingUse.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/Util.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/WebParamMode.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAction.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAddressing.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlBindingType.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlFaultAction.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlHandlerChain.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlMTOM.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlOneway.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlRequestWrapper.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlResponseWrapper.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlSOAPBinding.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlServiceMode.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebEndpoint.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebFault.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebMethod.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebParam.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebResult.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebService.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceClient.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceProvider.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceRef.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/package-info.java

Changeset: 24fa5452e5d4
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/24fa5452e5d4

Added tag jdk8-b87 for changeset 72e03566f0a6

! .hgtags



From john.coomes at oracle.com  Fri Apr 26 11:03:37 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 11:03:37 +0000
Subject: hg: hsx/hotspot-gc/jdk: 101 new changesets
Message-ID: <20130426112538.ACBF148623@hg.openjdk.java.net>

Changeset: b59b1f5a98dd
Author:    bae
Date:      2013-04-15 16:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b59b1f5a98dd

8005930: [lcms] ColorConvertOp: Alpha channel is not transferred from source to destination.
Reviewed-by: prr

! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
+ test/sun/java2d/cmm/ColorConvertOp/AlphaTest.java

Changeset: 03ee8c648624
Author:    bae
Date:      2013-04-15 18:10 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/03ee8c648624

8011622: Use lcms as the default color management module in jdk8
Reviewed-by: prr, vadim

! make/sun/cmm/Makefile
! make/sun/cmm/kcms/Makefile
! make/sun/cmm/lcms/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
+ src/share/classes/sun/java2d/cmm/CMMServiceProvider.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
+ src/share/classes/sun/java2d/cmm/lcms/LcmsServiceProvider.java
+ src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.CMMServiceProvider
- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: 271d5bf7d61f
Author:    lana
Date:      2013-04-17 12:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/271d5bf7d61f

Merge

! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk

Changeset: 0799af4553b5
Author:    lana
Date:      2013-04-17 21:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0799af4553b5

Merge

- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: d241f117ff46
Author:    malenkov
Date:      2013-04-11 19:12 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d241f117ff46

4683761: Incomplete Introspection on nonpublic classes lead to IllegalAccessExceptions
Reviewed-by: alexsch

! src/share/classes/java/beans/Introspector.java
+ test/java/beans/Introspector/Test4683761.java

Changeset: be89273ceb9c
Author:    pchelko
Date:      2013-04-12 14:09 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/be89273ceb9c

8010009: [macosx] Unable type into online word games on MacOSX
Reviewed-by: anthony, dcherepanov

! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/TestApplet.java

Changeset: 4490ef60ecd3
Author:    anthony
Date:      2013-04-12 14:33 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4490ef60ecd3

8010297: Missing isLoggable() checks in logging code
Summary: Add isLoggable() checks
Reviewed-by: anthony, mchung, serb
Contributed-by: Laurent Bourges <bourges.laurent at gmail.com>

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XMSelection.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java

Changeset: 39ce1056694d
Author:    serb
Date:      2013-04-12 15:28 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/39ce1056694d

8000629: [macosx] Blurry rendering with Java 7 on Retina display
Reviewed-by: anthony, prr, flar

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CGraphicsDevice.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.m
! src/share/classes/sun/awt/image/SurfaceManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/Region.java
+ test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java
+ test/java/awt/Graphics2D/FlipDrawImage/FlipDrawImage.java
+ test/java/awt/Graphics2D/TransformSetGet/TransformSetGet.java
+ test/java/awt/image/DrawImage/IncorrectBounds.java
+ test/java/awt/image/DrawImage/IncorrectOffset.java

Changeset: ffd45b1a9c11
Author:    serb
Date:      2013-04-12 20:39 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ffd45b1a9c11

8004866: [macosx] HiDPI support in Aqua L&F
Reviewed-by: swingler, alexsch

! src/macosx/classes/com/apple/laf/AquaPainter.java
! src/macosx/classes/com/apple/laf/ImageCache.java
! src/macosx/native/com/apple/laf/JRSUIController.m

Changeset: dcdf8cd4b09e
Author:    ant
Date:      2013-04-15 13:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dcdf8cd4b09e

7147075: JTextField doesn't get focus or loses focus forever
Reviewed-by: anthony

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

Changeset: 8fbe247ad2d8
Author:    lana
Date:      2013-04-17 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8fbe247ad2d8

Merge

! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java

Changeset: bb098a221d85
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bb098a221d85

Merge


Changeset: 863da64214e8
Author:    mduigou
Date:      2013-04-10 14:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/863da64214e8

8010948: Add conversion functional interfaces
Reviewed-by: mduigou, dholmes
Contributed-by: Brian Goetz <brian.goetz at oracle.com>

+ src/share/classes/java/util/function/DoubleToIntFunction.java
+ src/share/classes/java/util/function/DoubleToLongFunction.java
+ src/share/classes/java/util/function/IntToDoubleFunction.java
+ src/share/classes/java/util/function/IntToLongFunction.java
+ src/share/classes/java/util/function/LongToDoubleFunction.java
+ src/share/classes/java/util/function/LongToIntFunction.java

Changeset: b0458dd21ba6
Author:    darcy
Date:      2013-04-10 16:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b0458dd21ba6

8011930: Long.parseLong(String, int) has inaccurate limit on radix for using 'L'
Reviewed-by: smarks

! src/share/classes/java/lang/Long.java

Changeset: 6f8e1428f7c3
Author:    weijun
Date:      2013-04-11 10:58 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6f8e1428f7c3

8005460: [findbugs] Probably returned array should be cloned
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/PrincipalName.java
+ test/sun/security/krb5/name/Immutable.java

Changeset: 0ab22e58d151
Author:    weijun
Date:      2013-04-11 11:09 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0ab22e58d151

8011867: Accept unknown PKCS #9 attributes
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
+ test/sun/security/pkcs/pkcs9/UnknownAttribute.java

Changeset: 1c3fff140324
Author:    weijun
Date:      2013-04-11 11:10 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1c3fff140324

8011745: Unknown CertificateChoices
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs/PKCS7.java

Changeset: 006a7a576fe9
Author:    peytoia
Date:      2013-04-11 12:22 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/006a7a576fe9

8009638: Wrong comment for PL in LocaleISOData, 1989 forward Poland is Republic of Poland
Reviewed-by: okutsu

! src/share/classes/java/util/LocaleISOData.java

Changeset: e62a707a77d8
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e62a707a77d8

Merge


Changeset: f4d50e8cc9e2
Author:    sherman
Date:      2013-04-12 07:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f4d50e8cc9e2

8011172: JSR 310 DateTime API Updates II
Summary: Integration of JSR310 Date/Time API update
Reviewed-by: alanb, naoto, dholmes
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com

! make/java/java/Makefile
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/sun/text/FILES_java.gmk
! make/sun/tzdb/Makefile
! make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
! make/tools/src/build/tools/cldrconverter/Bundle.java
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
! makefiles/CopyFiles.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataTZDB.gmk
! makefiles/profile-includes.txt
! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/IsoEra.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimeParseContext.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/DateTimeTextProvider.java
+ src/share/classes/java/time/format/Parsed.java
+ src/share/classes/java/time/format/ResolverStyle.java
! src/share/classes/java/time/format/TextStyle.java
- src/share/classes/java/time/temporal/Adjusters.java
! src/share/classes/java/time/temporal/ChronoField.java
! src/share/classes/java/time/temporal/ChronoUnit.java
! src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
+ src/share/classes/java/time/temporal/TemporalAdjusters.java
! src/share/classes/java/time/temporal/TemporalAmount.java
! src/share/classes/java/time/temporal/TemporalField.java
+ src/share/classes/java/time/temporal/TemporalQueries.java
! src/share/classes/java/time/temporal/TemporalQuery.java
! src/share/classes/java/time/temporal/TemporalUnit.java
+ src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/temporal/package-info.java
! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRulesProvider.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/sun/text/resources/FormatData.java
+ src/share/classes/sun/text/resources/JavaTimeSupplementary.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java
+ src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java
! src/share/classes/sun/text/resources/be/FormatData_be.java
! src/share/classes/sun/text/resources/be/FormatData_be_BY.java
+ src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java
! src/share/classes/sun/text/resources/bg/FormatData_bg.java
! src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java
+ src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java
! src/share/classes/sun/text/resources/ca/FormatData_ca.java
! src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java
+ src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java
! src/share/classes/sun/text/resources/cs/FormatData_cs.java
! src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java
+ src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java
! src/share/classes/sun/text/resources/da/FormatData_da.java
! src/share/classes/sun/text/resources/da/FormatData_da_DK.java
+ src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java
! src/share/classes/sun/text/resources/de/FormatData_de.java
! src/share/classes/sun/text/resources/de/FormatData_de_AT.java
! src/share/classes/sun/text/resources/de/FormatData_de_CH.java
! src/share/classes/sun/text/resources/de/FormatData_de_DE.java
! src/share/classes/sun/text/resources/de/FormatData_de_LU.java
+ src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/el/FormatData_el_CY.java
! src/share/classes/sun/text/resources/el/FormatData_el_GR.java
+ src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java
! src/share/classes/sun/text/resources/en/FormatData_en.java
! src/share/classes/sun/text/resources/en/FormatData_en_AU.java
! src/share/classes/sun/text/resources/en/FormatData_en_CA.java
! src/share/classes/sun/text/resources/en/FormatData_en_GB.java
! src/share/classes/sun/text/resources/en/FormatData_en_IE.java
! src/share/classes/sun/text/resources/en/FormatData_en_IN.java
! src/share/classes/sun/text/resources/en/FormatData_en_MT.java
! src/share/classes/sun/text/resources/en/FormatData_en_NZ.java
! src/share/classes/sun/text/resources/en/FormatData_en_PH.java
! src/share/classes/sun/text/resources/en/FormatData_en_SG.java
! src/share/classes/sun/text/resources/en/FormatData_en_US.java
! src/share/classes/sun/text/resources/en/FormatData_en_ZA.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java
! src/share/classes/sun/text/resources/es/FormatData_es.java
! src/share/classes/sun/text/resources/es/FormatData_es_AR.java
! src/share/classes/sun/text/resources/es/FormatData_es_BO.java
! src/share/classes/sun/text/resources/es/FormatData_es_CL.java
! src/share/classes/sun/text/resources/es/FormatData_es_CO.java
! src/share/classes/sun/text/resources/es/FormatData_es_CR.java
! src/share/classes/sun/text/resources/es/FormatData_es_DO.java
! src/share/classes/sun/text/resources/es/FormatData_es_EC.java
! src/share/classes/sun/text/resources/es/FormatData_es_ES.java
! src/share/classes/sun/text/resources/es/FormatData_es_GT.java
! src/share/classes/sun/text/resources/es/FormatData_es_HN.java
! src/share/classes/sun/text/resources/es/FormatData_es_MX.java
! src/share/classes/sun/text/resources/es/FormatData_es_NI.java
! src/share/classes/sun/text/resources/es/FormatData_es_PA.java
! src/share/classes/sun/text/resources/es/FormatData_es_PE.java
! src/share/classes/sun/text/resources/es/FormatData_es_PR.java
! src/share/classes/sun/text/resources/es/FormatData_es_PY.java
! src/share/classes/sun/text/resources/es/FormatData_es_SV.java
! src/share/classes/sun/text/resources/es/FormatData_es_US.java
! src/share/classes/sun/text/resources/es/FormatData_es_UY.java
! src/share/classes/sun/text/resources/es/FormatData_es_VE.java
+ src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java
! src/share/classes/sun/text/resources/et/FormatData_et.java
! src/share/classes/sun/text/resources/et/FormatData_et_EE.java
+ src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java
+ src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java
! src/share/classes/sun/text/resources/fr/FormatData_fr.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java
+ src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java
! src/share/classes/sun/text/resources/ga/FormatData_ga.java
! src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java
+ src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java
! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
+ src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java
+ src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java
! src/share/classes/sun/text/resources/hu/FormatData_hu.java
! src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java
+ src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java
! src/share/classes/sun/text/resources/in/FormatData_in.java
! src/share/classes/sun/text/resources/in/FormatData_in_ID.java
! src/share/classes/sun/text/resources/is/FormatData_is.java
! src/share/classes/sun/text/resources/is/FormatData_is_IS.java
+ src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java
! src/share/classes/sun/text/resources/it/FormatData_it.java
! src/share/classes/sun/text/resources/it/FormatData_it_CH.java
! src/share/classes/sun/text/resources/it/FormatData_it_IT.java
+ src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java
! src/share/classes/sun/text/resources/iw/FormatData_iw.java
! src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java
+ src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java
+ src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java
+ src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java
+ src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java
! src/share/classes/sun/text/resources/lt/FormatData_lt.java
! src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java
+ src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java
! src/share/classes/sun/text/resources/lv/FormatData_lv.java
! src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java
+ src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java
! src/share/classes/sun/text/resources/mk/FormatData_mk.java
! src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java
+ src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java
! src/share/classes/sun/text/resources/ms/FormatData_ms.java
! src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java
+ src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java
! src/share/classes/sun/text/resources/mt/FormatData_mt.java
! src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java
+ src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java
! src/share/classes/sun/text/resources/nl/FormatData_nl.java
! src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java
! src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java
+ src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java
! src/share/classes/sun/text/resources/no/FormatData_no.java
! src/share/classes/sun/text/resources/no/FormatData_no_NO.java
! src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java
+ src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java
! src/share/classes/sun/text/resources/pl/FormatData_pl.java
! src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java
+ src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java
! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java
! src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java
+ src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java
+ src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java
! src/share/classes/sun/text/resources/ro/FormatData_ro.java
! src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java
+ src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java
! src/share/classes/sun/text/resources/ru/FormatData_ru.java
! src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java
+ src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java
! src/share/classes/sun/text/resources/sk/FormatData_sk.java
! src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java
+ src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java
! src/share/classes/sun/text/resources/sl/FormatData_sl.java
! src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java
+ src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java
! src/share/classes/sun/text/resources/sq/FormatData_sq.java
! src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java
+ src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java
+ src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java
+ src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java
+ src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java
! src/share/classes/sun/text/resources/th/FormatData_th.java
! src/share/classes/sun/text/resources/th/FormatData_th_TH.java
+ src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java
! src/share/classes/sun/text/resources/tr/FormatData_tr.java
! src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java
+ src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java
! src/share/classes/sun/text/resources/uk/FormatData_uk.java
! src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java
+ src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java
! src/share/classes/sun/text/resources/vi/FormatData_vi.java
! src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java
+ src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java
+ src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java
+ src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
+ src/share/classes/sun/util/resources/ParallelListResourceBundle.java
! src/share/lib/calendars.properties
+ src/share/lib/hijrah-config-umalqura.properties
! test/java/time/tck/java/time/AbstractDateTimeTest.java
! test/java/time/tck/java/time/TCKClock.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKPeriod.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
- test/java/time/tck/java/time/TestChronology.java
! test/java/time/tck/java/time/TestIsoChronology.java
! test/java/time/tck/java/time/chrono/CopticChronology.java
! test/java/time/tck/java/time/chrono/CopticDate.java
! test/java/time/tck/java/time/chrono/CopticEra.java
+ test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
+ test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
+ test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronology.java
+ test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
+ test/java/time/tck/java/time/chrono/TCKHijrahChronology.java
+ test/java/time/tck/java/time/chrono/TCKHijrahEra.java
+ test/java/time/tck/java/time/chrono/TCKIsoChronology.java
+ test/java/time/tck/java/time/chrono/TCKIsoEra.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
+ test/java/time/tck/java/time/chrono/TCKMinguoChronology.java
+ test/java/time/tck/java/time/chrono/TCKMinguoEra.java
! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java
+ test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java
! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
+ test/java/time/tck/java/time/format/TCKTextStyle.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
! test/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/java/time/tck/java/time/temporal/TCKJulianFields.java
+ test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java
! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/TestClock_System.java
! test/java/time/test/java/time/TestDuration.java
! test/java/time/test/java/time/TestLocalDate.java
! test/java/time/test/java/time/TestLocalDateTime.java
! test/java/time/test/java/time/TestLocalTime.java
! test/java/time/test/java/time/TestMonthDay.java
! test/java/time/test/java/time/TestOffsetDateTime.java
! test/java/time/test/java/time/TestOffsetDateTime_instants.java
! test/java/time/test/java/time/TestPeriod.java
! test/java/time/test/java/time/TestZoneId.java
+ test/java/time/test/java/time/chrono/TestChronoLocalDate.java
+ test/java/time/test/java/time/chrono/TestChronologyPerf.java
! test/java/time/test/java/time/chrono/TestExampleCode.java
! test/java/time/test/java/time/chrono/TestIsoChronoImpl.java
+ test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/java/time/test/java/time/chrono/TestServiceLoader.java
+ test/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java
+ test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/java/time/test/java/time/format/MockIOExceptionAppendable.java
! test/java/time/test/java/time/format/TestCharLiteralParser.java
! test/java/time/test/java/time/format/TestCharLiteralPrinter.java
! test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java
! test/java/time/test/java/time/format/TestDateTimeFormatter.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestFractionPrinterParser.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberParser.java
! test/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/java/time/test/java/time/format/TestReducedParser.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/format/TestSettingsParser.java
! test/java/time/test/java/time/format/TestStringLiteralParser.java
! test/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java
! test/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/java/time/test/java/time/format/ZoneName.java
! test/java/time/test/java/time/temporal/MockFieldValue.java
+ test/java/time/test/java/time/temporal/TestChronoField.java
! test/java/time/test/java/time/temporal/TestChronoUnit.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java
! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
! test/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/java/time/test/java/util/TestFormatter.java
! test/java/util/Calendar/Bug8007038.java
! test/java/util/Calendar/CldrFormatNamesTest.java
! test/java/util/Calendar/JavatimeTest.java
! test/sun/text/resources/LocaleData
! test/sun/util/calendar/zi/TestZoneInfo310.java

Changeset: 035a61c9f981
Author:    sherman
Date:      2013-04-12 09:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/035a61c9f981

8012123: hijrah-config-umalqura.properties is missing from makefiles/profile-includes.txt
Summary: added the hijrah-config-umalqura.properties into the list
Reviewed-by: alanb

! makefiles/profile-includes.txt

Changeset: e2cd40d7567c
Author:    rfield
Date:      2013-04-12 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e2cd40d7567c

8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries
Reviewed-by: mduigou, alanb

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/sun/tools/java/BinaryConstantPool.java
! src/share/classes/sun/tools/java/RuntimeConstants.java
+ test/sun/tools/java/CFCTest.java

Changeset: 2e3cc7f599ca
Author:    mduigou
Date:      2013-04-10 12:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2e3cc7f599ca

8011200: (coll) Optimize empty HashMap and ArrayList
Reviewed-by: mduigou, alanb, bchristi, martin
Contributed-by: Sergey Linetskiy <sergey.linetskiy at oracle.com>, John Rose <john.r.rose at oracle.com>, Mike Duigou <mike.duigou at oracle.com>

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
+ test/java/util/Map/BasicSerialization.java

Changeset: 6c935c5ac7ff
Author:    sherman
Date:      2013-04-12 12:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6c935c5ac7ff

8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime
Summary: added the toInstant()/from(Instant) to FileTime
Reviewed-by: alanb

! src/share/classes/java/nio/file/attribute/FileTime.java
! test/java/nio/file/attribute/FileTime/Basic.java

Changeset: 729ca1ef7c75
Author:    sherman
Date:      2013-04-12 12:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/729ca1ef7c75

8002390: (zipfs) Problems moving files between zip file systems
Summary: fixed the corner cases in zipfs
Reviewed-by: sherman
Contributed-by: mark.sheppard at oracle.com

! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! test/demo/zipfs/ZipFSTester.java
! test/demo/zipfs/basic.sh

Changeset: d8cae0195fe9
Author:    henryjen
Date:      2013-04-12 12:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d8cae0195fe9

8010279: java.util.Stream.min/max((Comparator)null) is not consistent in throwing (unspecified) NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Comparators.java
+ test/java/util/Comparators/BasicTest.java
- test/java/util/ComparatorsTest.java

Changeset: 06dfdfa8c3e6
Author:    rfield
Date:      2013-04-12 20:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/06dfdfa8c3e6

8012028: Metafactory-generated lambda classes should be final
8008941: isSynthetic() returns false for lambda instances
Reviewed-by: mduigou

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/LambdaClassFinal.java
+ test/java/lang/invoke/lambda/LambdaClassSynthetic.java

Changeset: 0111bab8dc35
Author:    jzavgren
Date:      2013-04-11 12:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0111bab8dc35

8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c
Summary: Modified the path processing code so that it detects and handles out of memory errors.
Reviewed-by: chegar, martin, christos, alanb, msheppar
Contributed-by: john.zavgren at oracle.com

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/ProcessEnvironment_md.c
! src/solaris/native/java/lang/UNIXProcess_md.c

Changeset: 5c406a747192
Author:    chegar
Date:      2013-04-14 19:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5c406a747192

8011799: CompletableFuture/Basic.java fails intermittently
Reviewed-by: martin, alanb

! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 4ed143ddbb8a
Author:    martin
Date:      2013-04-15 14:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4ed143ddbb8a

8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's jni_md.h needs similar change
Summary: Define JNIEXPORT to use "default" visibility where possible.
Reviewed-by: coleenp, ddehaven, dcubed, anthony

! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
! src/share/npt/npt.h
! src/solaris/javavm/export/jni_md.h
! src/solaris/native/sun/awt/awt_LoadLibrary.c

Changeset: baaa706d7677
Author:    darcy
Date:      2013-04-15 18:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/baaa706d7677

8011800: Add java.util.Objects.requireNonNull(T, Supplier<String>)
Reviewed-by: alanb, dholmes, mduigou

! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: 61cfbe08ce5d
Author:    chegar
Date:      2013-04-16 12:23 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/61cfbe08ce5d

8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build
Reviewed-by: alanb

! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: e2a0e37b152c
Author:    chegar
Date:      2013-04-16 12:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e2a0e37b152c

8012237: CompletableFuture/Basic.java still fails intermittently
Reviewed-by: martin

! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 6135c60e77e5
Author:    chegar
Date:      2013-04-16 13:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6135c60e77e5

8012244: java/net/Socket/asyncClose/Race.java fails intermittently on Windows
Reviewed-by: alanb, dsamersoff

! src/windows/classes/java/net/DualStackPlainSocketImpl.java
! src/windows/native/java/net/SocketInputStream.c
! test/java/net/Socket/asyncClose/Race.java

Changeset: e4e9f6455f3c
Author:    mduigou
Date:      2013-04-16 11:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e4e9f6455f3c

8004518: Add in-place operations to Map
8010122: Add defaults for ConcurrentMap operations to Map
Reviewed-by: darcy, briangoetz, mduigou, dholmes, ulfzibis
Contributed-by: Doug Lea <dl at cs.oswego.edu>, Henry Jen <henry.jen at oracle.com>, Akhil Arora <akhil.arora at oracle.com>, Peter Levart <peter.levart at gmail.com>, Mike Duigou <mike.duigou at oracle.com>

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
+ test/java/util/Map/Defaults.java

Changeset: c5ead5aa2e13
Author:    bae
Date:      2013-02-07 19:15 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c5ead5aa2e13

8007014: Improve image handling
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/BytePackedRaster.java
! src/share/classes/sun/awt/image/IntegerComponentRaster.java
! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c
! src/share/native/sun/awt/medialib/safe_alloc.h
+ src/share/native/sun/awt/medialib/safe_math.h

Changeset: c95973aac928
Author:    malenkov
Date:      2013-02-08 17:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c95973aac928

7200507: Refactor Introspector internals
Reviewed-by: ahgross, art

! src/share/classes/java/beans/ThreadGroupContext.java
+ src/share/classes/java/beans/WeakIdentityMap.java

Changeset: 210fb90ee33a
Author:    michaelm
Date:      2013-02-13 10:40 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/210fb90ee33a

8000724: Improve networking serialization
Summary: delegate InetAddress fields to a holder object
Reviewed-by: alanb, chegar

! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/Inet4AddressImpl.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/Inet6AddressImpl.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/native/java/net/InetAddress.c
! src/share/native/java/net/net_util.c
! src/share/native/java/net/net_util.h
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/net_util_md.c
! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h
! src/windows/native/java/net/NetworkInterface_winXP.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/net_util_md.c

Changeset: 5ffba58b541f
Author:    valeriep
Date:      2013-02-26 11:12 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5ffba58b541f

8000897: VM crash in CompileBroker
Summary: Fixed to use the corresponding digest length when generating output.
Reviewed-by: mullan

! src/share/classes/sun/security/provider/SHA2.java

Changeset: 96890625ebdf
Author:    smarks
Date:      2013-02-27 14:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/96890625ebdf

8001040: Rework RMI model
Reviewed-by: alanb, ahgross, coffeys, dmocek

! src/share/classes/sun/rmi/server/MarshalInputStream.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/security.policy
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
+ test/java/rmi/server/RMIClassLoader/useCodebaseOnlyDefault/UseCodebaseOnlyDefault.java
! test/java/rmi/testlibrary/RMID.java

Changeset: f12921c0b15b
Author:    dfuchs
Date:      2013-03-14 13:10 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f12921c0b15b

8001322: Refactor deserialization
Reviewed-by: mchung, skoivu, smarks

! src/share/classes/java/io/ObjectInputStream.java

Changeset: bae4a15265d3
Author:    dmocek
Date:      2013-02-05 16:38 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bae4a15265d3

8001329: Augment RMI logging
Reviewed-by: smarks, hawtin, alanb

! src/share/classes/java/rmi/server/LogStream.java

Changeset: c876e9321616
Author:    chegar
Date:      2012-12-20 13:40 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c876e9321616

8003335: Better handling of Finalizer thread
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/ref/Finalizer.java

Changeset: 0c5c54303c92
Author:    serb
Date:      2013-02-15 13:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0c5c54303c92

8004261: Improve input validation
Reviewed-by: art, mschoene, amenkov

! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/share/classes/com/sun/media/sound/FastShortMessage.java
! src/share/classes/com/sun/media/sound/FastSysexMessage.java
! src/share/classes/com/sun/media/sound/MidiOutDevice.java
! src/share/classes/com/sun/media/sound/RealTimeSequencer.java

Changeset: 3d155555f809
Author:    uta
Date:      2013-02-22 17:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3d155555f809

8005942: (process) Improved Runtime.exec
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/ProcessBuilder.java
! src/windows/classes/java/lang/ProcessImpl.java

Changeset: cf01f2847551
Author:    dsamersoff
Date:      2013-03-05 00:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cf01f2847551

8006435: Improvements in JMX
Summary: Improvements in JMX
Reviewed-by: dfuchs, skoivu, alanb, mchung

! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java

Changeset: 4effe291c08b
Author:    prr
Date:      2013-02-08 09:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4effe291c08b

8006795: Improve font warning messages
Reviewed-by: bae, jgodinez

! src/share/classes/sun/font/CMap.java

Changeset: 9b4bee66fa24
Author:    bae
Date:      2013-02-19 11:47 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9b4bee66fa24

8007617: Better validation of images
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/awt/image/ImageRepresentation.java
! src/share/native/sun/awt/image/awt_ImageRep.c

Changeset: 620a08212c79
Author:    bae
Date:      2013-02-26 00:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/620a08212c79

8007667: Better image reading
Reviewed-by: prr, jgodinez, mschoene

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: 2deab0b85b82
Author:    bae
Date:      2013-02-26 01:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2deab0b85b82

8007918: Better image writing
Reviewed-by: mschoene, prr, jgodinez

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: f7b331b8661f
Author:    chegar
Date:      2013-03-03 10:07 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f7b331b8661f

8009063: Improve reliability of ConcurrentHashMap
Reviewed-by: alanb, ahgross

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: 5c2c8fb0b885
Author:    dfuchs
Date:      2013-03-14 18:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5c2c8fb0b885

8009305: Improve AWT data transfer
Reviewed-by: art, skoivu, smarks, ant

! src/share/classes/sun/awt/datatransfer/TransferableProxy.java

Changeset: af881cbec91e
Author:    uta
Date:      2013-03-08 13:35 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af881cbec91e

8009463: Regression test test\java\lang\Runtime\exec\ArgWithSpaceAndFinalBackslash.java failing.
Reviewed-by: alanb, ahgross

! src/windows/classes/java/lang/ProcessImpl.java

Changeset: 633fd0b99a8d
Author:    valeriep
Date:      2013-03-11 20:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/633fd0b99a8d

8009610: Blacklist certificate used with malware.
Summary: updated the black list and the reg test with the new cert.
Reviewed-by: weijun

! src/share/classes/sun/security/util/UntrustedCertificates.java

Changeset: 37296d45a11e
Author:    lancea
Date:      2013-03-18 13:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/37296d45a11e

8009814: Better driver management
Reviewed-by: alanb, skoivu

! src/share/classes/java/sql/DriverManager.java

Changeset: fa919c17da9f
Author:    smarks
Date:      2013-03-18 18:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fa919c17da9f

8009857: Problem with plugin
Reviewed-by: jdn, mchung

! src/share/classes/sun/reflect/misc/MethodUtil.java

Changeset: 4267ae18e13a
Author:    prr
Date:      2013-02-15 13:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4267ae18e13a

8008249: Sync ICU into JDK
Reviewed-by: bae, jgodinez

! make/sun/font/FILES_c.gmk
! src/share/native/sun/font/layout/ContextualGlyphInsertion.h
+ src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp
+ src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h
+ src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
+ src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h
+ src/share/native/sun/font/layout/GXLayoutEngine2.cpp
+ src/share/native/sun/font/layout/GXLayoutEngine2.h
! src/share/native/sun/font/layout/IndicClassTables.cpp
! src/share/native/sun/font/layout/IndicRearrangement.h
+ src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp
+ src/share/native/sun/font/layout/IndicRearrangementProcessor2.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/IndicReordering.h
! src/share/native/sun/font/layout/LEFontInstance.h
! src/share/native/sun/font/layout/LEGlyphFilter.h
! src/share/native/sun/font/layout/LEInsertionList.h
! src/share/native/sun/font/layout/LEScripts.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
+ src/share/native/sun/font/layout/LigatureSubstProc2.cpp
+ src/share/native/sun/font/layout/LigatureSubstProc2.h
! src/share/native/sun/font/layout/LigatureSubstitution.h
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/MPreFixups.cpp
! src/share/native/sun/font/layout/MorphStateTables.h
! src/share/native/sun/font/layout/MorphTables.h
+ src/share/native/sun/font/layout/MorphTables2.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubst.h
+ src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp
+ src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.h
+ src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp
+ src/share/native/sun/font/layout/SegmentArrayProcessor2.h
+ src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp
+ src/share/native/sun/font/layout/SegmentSingleProcessor2.h
+ src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp
+ src/share/native/sun/font/layout/SimpleArrayProcessor2.h
+ src/share/native/sun/font/layout/SingleTableProcessor2.cpp
+ src/share/native/sun/font/layout/SingleTableProcessor2.h
+ src/share/native/sun/font/layout/StateTableProcessor2.cpp
+ src/share/native/sun/font/layout/StateTableProcessor2.h
! src/share/native/sun/font/layout/StateTables.h
+ src/share/native/sun/font/layout/SubtableProcessor2.cpp
+ src/share/native/sun/font/layout/SubtableProcessor2.h
+ src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp
+ src/share/native/sun/font/layout/TrimmedArrayProcessor2.h

Changeset: 43f2d3d715c5
Author:    prr
Date:      2013-02-26 10:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/43f2d3d715c5

8004986: Better handling of glyph table
8004987: Improve font layout
8004994: Improve checking of glyph table
Reviewed-by: srl, jgodinez

! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/StateTableProcessor.cpp
! src/share/native/sun/font/layout/StateTableProcessor2.cpp
! src/share/native/sun/font/layout/StateTables.h

Changeset: 32778f4f945f
Author:    prr
Date:      2013-03-07 10:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/32778f4f945f

8001031: Better font processing
Reviewed-by: srl, vadim

! src/share/native/sun/font/FontInstanceAdapter.cpp
! src/share/native/sun/font/FontInstanceAdapter.h
! src/share/native/sun/font/fontscalerdefs.h
! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp
! src/share/native/sun/font/layout/AlternateSubstSubtables.h
! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ArabicLayoutEngine.h
! src/share/native/sun/font/layout/ArabicShaping.cpp
! src/share/native/sun/font/layout/ArabicShaping.h
! src/share/native/sun/font/layout/AttachmentPosnSubtables.h
! src/share/native/sun/font/layout/CanonData.cpp
! src/share/native/sun/font/layout/CanonShaping.cpp
! src/share/native/sun/font/layout/CanonShaping.h
! src/share/native/sun/font/layout/ClassDefinitionTables.cpp
! src/share/native/sun/font/layout/ClassDefinitionTables.h
! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp
! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h
! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp
! src/share/native/sun/font/layout/ContextualSubstSubtables.h
! src/share/native/sun/font/layout/CoverageTables.h
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h
! src/share/native/sun/font/layout/DeviceTables.h
! src/share/native/sun/font/layout/ExtensionSubtables.cpp
! src/share/native/sun/font/layout/Features.cpp
! src/share/native/sun/font/layout/GDEFMarkFilter.cpp
! src/share/native/sun/font/layout/GDEFMarkFilter.h
! src/share/native/sun/font/layout/GXLayoutEngine.cpp
! src/share/native/sun/font/layout/GXLayoutEngine.h
! src/share/native/sun/font/layout/GXLayoutEngine2.cpp
! src/share/native/sun/font/layout/GXLayoutEngine2.h
! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp
! src/share/native/sun/font/layout/GlyphDefinitionTables.h
! src/share/native/sun/font/layout/GlyphIterator.cpp
! src/share/native/sun/font/layout/GlyphIterator.h
! src/share/native/sun/font/layout/GlyphLookupTables.cpp
! src/share/native/sun/font/layout/GlyphLookupTables.h
! src/share/native/sun/font/layout/GlyphPositioningTables.cpp
! src/share/native/sun/font/layout/GlyphPositioningTables.h
! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp
! src/share/native/sun/font/layout/GlyphPosnLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp
! src/share/native/sun/font/layout/GlyphSubstLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp
! src/share/native/sun/font/layout/GlyphSubstitutionTables.h
! src/share/native/sun/font/layout/HanLayoutEngine.cpp
! src/share/native/sun/font/layout/HanLayoutEngine.h
! src/share/native/sun/font/layout/HangulLayoutEngine.cpp
! src/share/native/sun/font/layout/HangulLayoutEngine.h
! src/share/native/sun/font/layout/ICUFeatures.h
! src/share/native/sun/font/layout/IndicLayoutEngine.cpp
! src/share/native/sun/font/layout/IndicLayoutEngine.h
! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp
! src/share/native/sun/font/layout/IndicRearrangementProcessor.h
! src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp
! src/share/native/sun/font/layout/IndicRearrangementProcessor2.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/KernTable.cpp
! src/share/native/sun/font/layout/KernTable.h
! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp
! src/share/native/sun/font/layout/KhmerLayoutEngine.h
! src/share/native/sun/font/layout/LEScripts.h
+ src/share/native/sun/font/layout/LETableReference.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc.h
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.h
! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp
! src/share/native/sun/font/layout/LigatureSubstSubtables.h
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/LookupProcessor.h
! src/share/native/sun/font/layout/LookupTables.cpp
! src/share/native/sun/font/layout/LookupTables.h
! src/share/native/sun/font/layout/Lookups.cpp
! src/share/native/sun/font/layout/Lookups.h
! src/share/native/sun/font/layout/MarkArrays.h
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h
! src/share/native/sun/font/layout/MorphTables.cpp
! src/share/native/sun/font/layout/MorphTables.h
! src/share/native/sun/font/layout/MorphTables2.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.h
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/OpenTypeTables.h
! src/share/native/sun/font/layout/OpenTypeUtilities.cpp
! src/share/native/sun/font/layout/OpenTypeUtilities.h
! src/share/native/sun/font/layout/PairPositioningSubtables.cpp
! src/share/native/sun/font/layout/PairPositioningSubtables.h
! src/share/native/sun/font/layout/ScriptAndLanguage.cpp
! src/share/native/sun/font/layout/ScriptAndLanguage.h
! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp
! src/share/native/sun/font/layout/SegmentArrayProcessor.h
! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp
! src/share/native/sun/font/layout/SegmentArrayProcessor2.h
! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp
! src/share/native/sun/font/layout/SegmentSingleProcessor.h
! src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp
! src/share/native/sun/font/layout/SegmentSingleProcessor2.h
! src/share/native/sun/font/layout/ShapingTypeData.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor.h
! src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor2.h
! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp
! src/share/native/sun/font/layout/SinglePositioningSubtables.h
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h
! src/share/native/sun/font/layout/SingleTableProcessor.cpp
! src/share/native/sun/font/layout/SingleTableProcessor.h
! src/share/native/sun/font/layout/SingleTableProcessor2.cpp
! src/share/native/sun/font/layout/SingleTableProcessor2.h
! src/share/native/sun/font/layout/StateTableProcessor.cpp
! src/share/native/sun/font/layout/StateTableProcessor.h
! src/share/native/sun/font/layout/StateTableProcessor2.cpp
! src/share/native/sun/font/layout/StateTableProcessor2.h
! src/share/native/sun/font/layout/StateTables.h
! src/share/native/sun/font/layout/SubtableProcessor.cpp
! src/share/native/sun/font/layout/SubtableProcessor.h
! src/share/native/sun/font/layout/SubtableProcessor2.cpp
! src/share/native/sun/font/layout/SubtableProcessor2.h
! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp
! src/share/native/sun/font/layout/TibetanLayoutEngine.cpp
! src/share/native/sun/font/layout/TibetanLayoutEngine.h
! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp
! src/share/native/sun/font/layout/TrimmedArrayProcessor.h
! src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp
! src/share/native/sun/font/layout/TrimmedArrayProcessor2.h
! src/share/native/sun/font/layout/ValueRecords.h
! src/share/native/sun/font/sunFont.c

Changeset: 7b03efca912f
Author:    malenkov
Date:      2013-02-05 20:07 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7b03efca912f

8006790: Improve checking for windows
Reviewed-by: art, mschoene

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/peer/WindowPeer.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: 4ea6d44a20a0
Author:    mullan
Date:      2013-03-27 10:37 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4ea6d44a20a0

8003445: Adjust JAX-WS to focus on API
Reviewed-by: vinnie, ahgross, mgrebac

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile

Changeset: c921d68edf08
Author:    joehw
Date:      2013-02-18 13:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c921d68edf08

6657673: Issues with JAXP
Reviewed-by: alanb, lancea, ahgross, mullan

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile

Changeset: 6a09e4648cfb
Author:    mkos
Date:      2013-03-07 07:19 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6a09e4648cfb

8005432: Update access to JAX-WS
Summary: newly restricted the whole package com.sun.xml.internal; fix reviewed also by Alexander Fomin
Reviewed-by: mullan, skoivu

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 12ca12303c33
Author:    raginip
Date:      2013-03-27 21:32 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/12ca12303c33

8007406: Improve accessibility of AccessBridge
Reviewed-by: skoivu, mullan, ptbrunet

! src/share/lib/security/java.security-windows

Changeset: 269b7955a885
Author:    chegar
Date:      2013-03-28 09:50 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/269b7955a885

8010944: Incorrectly separated package list in java.security-windows
Reviewed-by: mullan

! src/share/lib/security/java.security-windows

Changeset: 7c663f528ff6
Author:    vlivanov
Date:      2013-03-01 04:45 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7c663f528ff6

8008140: Better method handle resolution
Reviewed-by: jrose, twisti, jdn

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

Changeset: 0fb15205acb6
Author:    bae
Date:      2013-02-19 12:06 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0fb15205acb6

8007675: Improve color conversion
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java

Changeset: b057eaf53935
Author:    chegar
Date:      2013-04-04 17:34 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b057eaf53935

Merge

! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java

Changeset: 5f46a666e06d
Author:    chegar
Date:      2013-04-13 20:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5f46a666e06d

Merge

! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/windows/classes/java/lang/ProcessImpl.java
! test/Makefile

Changeset: 84df34924f67
Author:    chegar
Date:      2013-04-13 21:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/84df34924f67

Merge

- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 9246b0fee2f2
Author:    chegar
Date:      2013-04-16 13:30 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9246b0fee2f2

Merge


Changeset: 10fd3b4a77ae
Author:    chegar
Date:      2013-04-16 21:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/10fd3b4a77ae

Merge


Changeset: a3cc4b8e217a
Author:    weijun
Date:      2013-04-17 10:15 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a3cc4b8e217a

8011124: Make KerberosTime immutable
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbAppMessage.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java
! src/share/classes/sun/security/krb5/internal/LastReqEntry.java
! src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java
! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java
! test/sun/security/krb5/MicroTime.java

Changeset: da6addef956e
Author:    mchung
Date:      2013-04-16 21:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/da6addef956e

8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive
Reviewed-by: jrose, alanb, twisti

! make/java/java/FILES_c.gmk
! make/java/java/mapfile-vers
! make/java/java/reorder-i586
! make/java/java/reorder-sparc
! make/java/java/reorder-sparcv9
! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjava/reorder-sparc
! makefiles/mapfiles/libjava/reorder-sparcv9
! makefiles/mapfiles/libjava/reorder-x86
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/sun/misc/Unsafe.java
+ src/share/classes/sun/reflect/CallerSensitive.java
! src/share/classes/sun/reflect/Reflection.java
! src/share/javavm/export/jvm.h
! src/share/native/java/lang/ClassLoader.c
- src/share/native/java/lang/ResourceBundle.c
! src/share/native/java/lang/SecurityManager.c
! src/share/native/sun/reflect/Reflection.c
! test/Makefile
+ test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java
+ test/sun/reflect/CallerSensitive/MethodFinder.java
+ test/sun/reflect/CallerSensitive/MissingCallerSensitive.java
+ test/sun/reflect/Reflection/GetCallerClass.java
+ test/sun/reflect/Reflection/GetCallerClassTest.java
+ test/sun/reflect/Reflection/GetCallerClassTest.sh

Changeset: 414384c3b3eb
Author:    yhuang
Date:      2013-04-16 22:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/414384c3b3eb

8011977: ISO 4217 Amendment Number 155
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! test/java/util/Currency/tablea1.txt

Changeset: 779ba708fee3
Author:    yhuang
Date:      2013-04-17 01:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/779ba708fee3

Merge

- src/share/native/java/lang/ResourceBundle.c

Changeset: 473ed4b94306
Author:    vinnie
Date:      2013-04-11 17:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/473ed4b94306

7171982: Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider
Reviewed-by: vinnie, wetmore
Contributed-by: Tony Scarpino <anthony.scarpino at oracle.com>

! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/CipherWithWrappingSpi.java
! src/share/classes/com/sun/crypto/provider/ConstructKeys.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/share/classes/com/sun/crypto/provider/PBES2Core.java
! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/RSACipher.java
! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: a6ca7cd399b2
Author:    vinnie
Date:      2013-04-11 18:00 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a6ca7cd399b2

8001596: Incorrect condition check in PBKDF2KeyImpl.JAVA
Reviewed-by: wetmore
Contributed-by: Tony Scarpino <anthony.scarpino at oracle.com>

! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
+ test/com/sun/crypto/provider/Cipher/PBE/NegativeLength.java

Changeset: 747a09471fd9
Author:    erikj
Date:      2013-04-11 14:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/747a09471fd9

8011812: JDK-8011278 breaks the old build
Reviewed-by: tbell, wetmore

! make/sun/splashscreen/Makefile

Changeset: 793e0072bfd6
Author:    wetmore
Date:      2013-04-11 17:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/793e0072bfd6

8012056: SunJCEInstance needs to run in it's own vm
Reviewed-by: wetmore
Contributed-by: anthony.scarpino at oracle.com

! test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: d8d037a7569e
Author:    xuelei
Date:      2013-04-11 18:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d8d037a7569e

8011680: Re-integrate AEAD implementation of JSSE
Summary: It is a re-merge of JDK-7030966.
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
+ src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: ea7976ed9bc6
Author:    wetmore
Date:      2013-04-11 19:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ea7976ed9bc6

Merge


Changeset: 0f93bd5cc8d7
Author:    wetmore
Date:      2013-04-11 21:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0f93bd5cc8d7

6425477: Better support for generation of high entropy random numbers
Reviewed-by: xuelei, weijun, mullan

! src/share/classes/java/security/SecureRandom.java
! src/share/classes/sun/security/pkcs11/P11SecureRandom.java
! src/share/classes/sun/security/provider/SecureRandom.java
! src/share/classes/sun/security/provider/SeedGenerator.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/solaris/classes/sun/security/provider/NativePRNG.java
! src/solaris/classes/sun/security/provider/NativeSeedGenerator.java
! src/windows/classes/sun/security/mscapi/PRNG.java
! src/windows/classes/sun/security/provider/NativePRNG.java
! src/windows/classes/sun/security/provider/NativeSeedGenerator.java
+ test/sun/security/provider/SecureRandom/StrongSecureRandom.java
+ test/sun/security/provider/SecureRandom/StrongSeedReader.java

Changeset: 5435f112e5ea
Author:    vinnie
Date:      2013-04-12 10:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5435f112e5ea

Merge

- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java

Changeset: 6f80a6584fb9
Author:    vinnie
Date:      2013-04-16 01:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6f80a6584fb9

Merge

- test/java/util/ComparatorsTest.java

Changeset: 29cbb4617c92
Author:    vinnie
Date:      2013-04-16 05:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/29cbb4617c92

Merge


Changeset: 13e18d3ac414
Author:    vinnie
Date:      2013-04-16 05:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/13e18d3ac414

Merge


Changeset: f90b7503019f
Author:    vinnie
Date:      2013-04-17 02:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f90b7503019f

Merge

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
- src/share/native/java/lang/ResourceBundle.c

Changeset: 7ded74ffea36
Author:    alanb
Date:      2013-04-17 16:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7ded74ffea36

8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win)
Reviewed-by: chegar

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeDispatcher.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
+ test/java/nio/channels/FileChannel/InterruptDeadlock.java

Changeset: d9f9040554d6
Author:    mduigou
Date:      2013-04-17 11:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d9f9040554d6

8010953: Add primitive summary statistics utils
Reviewed-by: mduigou, dholmes, chegar, darcy
Contributed-by: Brian Goetz <brian.goetz at oracle.com>

+ src/share/classes/java/util/DoubleSummaryStatistics.java
+ src/share/classes/java/util/IntSummaryStatistics.java
+ src/share/classes/java/util/LongSummaryStatistics.java

Changeset: 73e3b474125e
Author:    mchung
Date:      2013-04-17 12:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/73e3b474125e

8004260: dynamic proxy class should have the same Java language access as the proxy interfaces
Reviewed-by: alanb, jrose, jdn

! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/tracing/ProviderSkeleton.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/SimpleProxy.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Bar.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Foo.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy

Changeset: 7f9f69729934
Author:    coleenp
Date:      2013-04-17 12:50 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7f9f69729934

8009531: Crash when redefining class with annotated method
Summary: Add code to annotated methods and command line flags to the tests to verify bug above
Reviewed-by: acorn, sspitsyn, dcubed, dholmes, alanb

! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java

Changeset: 36f9e357b84b
Author:    coleenp
Date:      2013-04-17 15:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/36f9e357b84b

Merge


Changeset: a954e407680c
Author:    lana
Date:      2013-04-17 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a954e407680c

Merge


Changeset: 17dcb75682b7
Author:    lana
Date:      2013-04-17 12:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/17dcb75682b7

Merge


Changeset: 131686bea632
Author:    lana
Date:      2013-04-17 12:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/131686bea632

Merge


Changeset: 674880648db4
Author:    briangoetz
Date:      2013-04-16 13:51 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/674880648db4

8010096: Initial java.util.Spliterator putback
Reviewed-by: mduigou, alanb, chegar, darcy
Contributed-by: Paul Sandoz <paul.sandoz at oracle.com>, Brian Goetz <brian.goetz at oracle.com>, Doug Lea <dl at cs.oswego.edu>

! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java
+ src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
+ src/share/classes/java/util/Spliterator.java
+ src/share/classes/java/util/Spliterators.java
+ src/share/classes/java/util/Tripwire.java
+ test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
+ test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

Changeset: 4b8e606f8afb
Author:    lana
Date:      2013-04-17 21:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4b8e606f8afb

Merge

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
- src/share/native/java/lang/ResourceBundle.c
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 10ad4a4330bc
Author:    lana
Date:      2013-04-23 09:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/10ad4a4330bc

Merge


Changeset: d5228e624826
Author:    katleman
Date:      2013-04-23 18:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d5228e624826

8012643: JDK8 b86 source with GPL header errors
Reviewed-by: dholmes, alanb

! test/java/lang/Runtime/exec/WinCommand.java
! test/java/lang/reflect/Method/DefaultMethodModeling.java

Changeset: 53be90fb39d6
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/53be90fb39d6

Added tag jdk8-b87 for changeset d5228e624826

! .hgtags



From john.coomes at oracle.com  Fri Apr 26 11:32:23 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 11:32:23 +0000
Subject: hg: hsx/hotspot-gc/langtools: 17 new changesets
Message-ID: <20130426113316.D58DC48624@hg.openjdk.java.net>

Changeset: eb134c8e931d
Author:    bpatel
Date:      2013-04-09 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/eb134c8e931d

8005091: javadoc should be able to return the receiver type
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.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/MethodWriterImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
+ test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassExtends.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodReturnType.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodTypeParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Parameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Receivers.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Throws.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/TypeParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Varargs.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Wildcards.java

Changeset: a4be2c2fe0a1
Author:    vromero
Date:      2013-04-10 12:31 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a4be2c2fe0a1

8011432: javac, compiler regression iterable + captured type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java

Changeset: d13af7751456
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d13af7751456

Merge


Changeset: 137994c189e5
Author:    jfranck
Date:      2013-04-12 12:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/137994c189e5

7015104: use new subtype of TypeSymbol for type parameters
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/scope/7017664/CompoundScopeTest.java
! test/tools/javac/types/TypeHarness.java

Changeset: 76537856a54e
Author:    vromero
Date:      2013-04-13 12:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/76537856a54e

8010659: Javac Crashes while building OpenJFX
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

+ src/share/classes/com/sun/tools/javac/comp/CompileStates.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java
! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java
! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java

Changeset: f10cffab99b4
Author:    bpatel
Date:      2013-04-13 18:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f10cffab99b4

8009686: Generated javadoc documentation should be able to display type annotation on an array
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/javadoc/Type.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java
! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
! test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java

Changeset: b26f36a7ae3b
Author:    mcimadamore
Date:      2013-04-15 14:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b26f36a7ae3b

8011383: Symbol.getModifiers omits ACC_ABSTRACT from interface with default methods
Summary: Fixup for default method modifiers erroneously applies to class-level modifiers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/defaultMethods/DefaultMethodFlags.java

Changeset: c430f1cde21c
Author:    mcimadamore
Date:      2013-04-15 14:12 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c430f1cde21c

8011377: Javac crashes when multiple lambdas are defined in an array
Summary: Wrong attribution environment used by DeferredAttr
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
+ test/tools/javac/lambda/TargetType71.java

Changeset: 083c6b199e2f
Author:    mcimadamore
Date:      2013-04-15 14:15 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/083c6b199e2f

8011376: Spurious checked exception errors in nested method call
Summary: Fallback attribution logic doesn't work properly when lambda throws checked exceptions
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/TargetType72.java

Changeset: 6dacab087652
Author:    mcimadamore
Date:      2013-04-15 14:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6dacab087652

8011028: lang/INFR/infr001/infr00101md/infr00101md.java fails to compile after switch to JDK8-b82
Summary: Fix bug in Types.removeWildcards
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! test/tools/javac/lambda/TargetType69.java
+ test/tools/javac/lambda/TargetType70.java

Changeset: c2315af9cc28
Author:    mcimadamore
Date:      2013-04-15 14:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c2315af9cc28

8011392: Missing checkcast when casting to intersection type
Summary: javac should emit a checkcast for each additional target type specified in an intersection type cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/Intersection03.java

Changeset: 950e8ac120f0
Author:    mcimadamore
Date:      2013-04-15 14:18 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/950e8ac120f0

8010923: Avoid redundant speculative attribution
Summary: Add optimization to avoid speculative attribution for certain argument expressions
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java

Changeset: 49d32c84dfea
Author:    vromero
Date:      2013-04-17 11:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/49d32c84dfea

8011181: javac, empty UTF8 entry generated for inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/T8011181/EmptyUTF8ForInnerClassNameTest.java

Changeset: 94870c08391c
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/94870c08391c

Merge


Changeset: cad4fc23f691
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/cad4fc23f691

Merge


Changeset: 1329f9c38d93
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1329f9c38d93

Merge


Changeset: a1e10f3adc47
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a1e10f3adc47

Added tag jdk8-b87 for changeset 1329f9c38d93

! .hgtags



From john.coomes at oracle.com  Fri Apr 26 11:33:21 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 11:33:21 +0000
Subject: hg: hsx/hotspot-gc/nashorn: 15 new changesets
Message-ID: <20130426113333.C49E048625@hg.openjdk.java.net>

Changeset: 480b90430d29
Author:    lana
Date:      2013-04-11 19:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/480b90430d29

Merge


Changeset: 635a93b61d34
Author:    hannesw
Date:      2013-04-10 14:00 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/635a93b61d34

8011714: Regexp decimal escape handling still not correct
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011714.js
+ test/script/basic/JDK-8011714.js.EXPECTED

Changeset: b4ea8678bf15
Author:    hannesw
Date:      2013-04-10 14:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b4ea8678bf15

8011749: Bugs with empty character class handling
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011749.js
+ test/script/basic/JDK-8011749.js.EXPECTED

Changeset: 8ae9ed1ac1e2
Author:    hannesw
Date:      2013-04-10 14:08 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8ae9ed1ac1e2

8011756: Wrong characters supported in RegExp \c escape
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011756.js
+ test/script/basic/JDK-8011756.js.EXPECTED

Changeset: 571e06d5d23c
Author:    sundar
Date:      2013-04-11 13:20 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/571e06d5d23c

8011960: [2,1].sort(null) should throw TypeError
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011960.js

Changeset: 256bb030ce0a
Author:    sundar
Date:      2013-04-11 15:04 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/256bb030ce0a

8011974: Comparator function returning negative and positive Infinity does not work as expected with Array.prototype.sort
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
+ test/script/basic/JDK-8011974.js

Changeset: a3fc89d33072
Author:    hannesw
Date:      2013-04-11 12:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a3fc89d33072

8011980: Allow NUL character in character class
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011980.js
+ test/script/basic/JDK-8011980.js.EXPECTED

Changeset: ed4293ceec0e
Author:    hannesw
Date:      2013-04-12 16:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ed4293ceec0e

8011884: Regexp literals are compiled twice
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java

Changeset: 36e36a2d4312
Author:    hannesw
Date:      2013-04-12 16:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/36e36a2d4312

8011885: Switch to Joni as default Regexp engine
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java

Changeset: e70e6b38826b
Author:    jlaskey
Date:      2013-04-15 08:39 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e70e6b38826b

Merge


Changeset: 222a72df2f42
Author:    mchung
Date:      2013-04-16 22:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/222a72df2f42

8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive
Reviewed-by: jrose, alanb, twisti, sundar

! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/internal/runtime/Context.java

Changeset: 44d8612e29b0
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/44d8612e29b0

Merge


Changeset: cba329ce5efe
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/cba329ce5efe

Merge


Changeset: 774aeaa89bc1
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/774aeaa89bc1

Merge


Changeset: 40c107d1ae6f
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/40c107d1ae6f

Added tag jdk8-b87 for changeset 774aeaa89bc1

! .hgtags



From thomas.schatzl at oracle.com  Fri Apr 26 12:05:32 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 26 Apr 2013 14:05:32 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <5170340B.6020704@oracle.com>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
Message-ID: <1366977932.2808.73.camel@cirrus>

Hi all,

On Thu, 2013-04-18 at 10:57 -0700, John Cuthbertson wrote: 
> Hi Thomas,
> 
> [...]
> 
> Ship it.
> 
> JohnC

  I still need another reviewer to actually ship this :)

It would also help to have this cleanup for CR-7057939 and CR-8012591.

Thanks,
  Thomas

On Thu, 2013-04-18 at 10:57 -0700, John Cuthbertson wrote:
> Hi Thomas,
> 
> Thanks for the resonse. Inline...
> 
> On 4/17/2013 12:23 AM, Thomas Schatzl wrote:
> > Hi,
> >
> >    I had the same concerns about inconsistencies with -Xms and
> > -XX:InitialHeapSize, but -Xms is (apparently) defined to set both
> > minimum and initial heap size.
> > I already raised that issue in an earlier discussion.
> 
> OK. I don't have a problem with it. It just looked 'odd'.
> >
> > If you have an official source that states that -Xms only sets minimum
> > or initial heap size, I will gladly change this. I could not find
> > anything; actually the documentation (java -X) for -Xms states only that it sets the initial heap size.
> >
> > The observations below result from this definition.
> >
> > On Mon, 2013-04-15 at 16:29 -0700, John Cuthbertson wrote:
> >> Hi Thomas,
> >>
> >> Why do we treat:
> >>
> >> java -Xms8M  -XX:InitialHeapSize=4M...
> >>
> >> as an error while accepting:
> > Because -Xms sets minimum heap size to 8M, and if you then set initial
> > heap size to 4M there is a conflict in the general condition that
> > minimum <= initial <= max.
> >
> >> java -XX:InitialHeapSize=4M -Xms8M...
> >>
> >> It looks inconsistent. In both cases the user has asked for an initial
> >> heap size less than his requested minimum.
> > As mentioned, -Xms unfortunately seems to be defined to set both initial
> > and minimum heap size. So there is no conflict.
> 
> You're correct. I've looked at the contents of the Xusage.txt file for a 
> couple of really ancient jdks and it says that it sets the initial size.
> 
> 
> >> In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be
> >> coalesced into a single line for each? This would make the setting of
> >> Initial and Min consistent with the code that sets Max on line 87.
> >>
> > Done.
> >
> > See http://cr.openjdk.java.net/~tschatzl/8006088/webrev.7/ for the new
> > webrev.
> >
> > In addition to this change I fixed the headers of the jprt test cases to
> > avoid some issues with jtreg. Namely precompile the used classes and
> > install the whitebox api class into the boot class path.
> 
> Thanks. collectorPolicy.cpp looks much cleaner.
> 
> Ship it.
> 
> JohnC




From mikael.gerdin at oracle.com  Fri Apr 26 12:08:24 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 26 Apr 2013 14:08:24 +0200
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <517A5046.4080702@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
	<51791BA0.9070108@oracle.com> <517A5046.4080702@oracle.com>
Message-ID: <517A6E38.2010805@oracle.com>

David,

On 2013-04-26 12:00, David Holmes wrote:
> On 25/04/2013 10:03 PM, Mikael Gerdin wrote:
>> On 04/25/2013 01:57 PM, Coleen Phillimore wrote:
>>>
>>> I believe this change is correct.  I think if we elide safepoint locks
>>> for a lock sometimes, we always have to elide safepoint checks for that
>>> lock.   David will correct me if I'm wrong.
>>
>> I also believe that the change is correct.
>> And I hope that David will chime in on this one.
>
> Well .... I think that is accurate though I haven't quite seen it stated
> that way. The ability to lock without a safepoint check depends, as far
> as I understand it (and I'm rusty on the details, and the details are
> complex) on the threads using the lock (and their state) and whether the
> lock may be needed by the VMThread during a safepoint.
>
> Really to see what is going wrong I need to see the stacks of the
> threads when the deadlock occurs, else it is just speculation as to what
> might have gone wrong. There is a hint (a strong one) in mutex.cpp:
>
> // Lock without safepoint check - a degenerate variant of lock().
> // Should ONLY be used by safepoint code and other code
> // that is guaranteed not to block while running inside the VM. If this
> is called with
> // thread state set to be in VM, the safepoint synchronization code will
> deadlock!
>
> If a mutator tries to lock without a safepoint check and the lock is
> held, the thread will block but remain in the _thread_in_vm state. If a
> safepoint commences during that time the lock owner will not be able to
> release the lock if it hits a safepoint check first. Meanwhile the
> VMThread will be waiting for the blocked thread to reach a safepoint
> safe state - which it never will as it is physically blocked while still
> _thread_in_vm. Hence deadlock.

This is what I saw in one of the hangs. The VM was trying to safepoint 
and one thread was waiting on the lock with _no_safepoint_check_flag.

This in itself should not be a problem since the last thread to hold the 
lock should have made sure that it woke up the waiting thread when 
leaving the critical region.

My theory is that mixing Mutex::lock and 
Mutex::lock_without_safepoint_check somehow leads to a thread leaving 
the lock without signaling that properly to the next in line.

I've dumped a bit of information on the hang in a text file at:
http://cr.openjdk.java.net/~mgerdin/8013129/deadlock-info.txt

>
> So the current change to check for safepoints is undoubtedly a safe
> alternative.
>
> Now an interesting thing with these changes is that one only applies to
> the VMThread - so what does presence or absence of a safepoint check
> mean for the VMThread itself? There is only one difference in that case:
> locking with a safepoint check allows "lock sneaking". But I don't think
> I need to expand on that here - see mutex.cpp.

The separate VMThread and non-vmthread code paths in this change are 
unnecessary and I thought Coleen had a change which was going to fix 
that but I may have been mistaken.

>
> But this does raise a follow on concern: when the thread is not the
> VMThread, can it hit a safepoint or otherwise block in the region whilst
> holding the Metaspace lock? If the answer is yes then we still have a
> potential safepoint deadlock because the VMThread will not be able to
> acquire the lock during the safepoint VM_operation and will block.

Currently we don't block in the allocation path and if we need to 
trigger a GC I believe we release the locks before starting a VM_operation.

>
> Aside: this also makes me wonder about the safety of other
> lock-without-safepoint-check usages.

Indeed, if there is a deadlock possiblility when mixing 
lock-without-safepoint-check and "normal" lock then we should consider 
enforcing that a lock is used only for one of the two paths, perhaps 
using the C++ compiler / type system.

/Mikael

>
>
> David
> -----
>
>> /Mikael
>>
>>>
>>> Coleen
>>>
>>> On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
>>>> Hi,
>>>>
>>>> Problem:
>>>> We've seen some hangs in the GC nightly testing recently.
>>>> When I looked at the minidump files from some of those hangs they
>>>> looked like safepoint deadlocks where one thread was parked in
>>>> Mutex::lock_without_safepoint_check on one of the "Metaspace
>>>> allocation locks".
>>>>
>>>> Both of the hangs I investigated also had threads trying to lock the
>>>> same Metaspace lock but without eliding safepoint checks because they
>>>> were originating from Metaspace::deallocate.
>>>>
>>>> I believe that since the change to allocate MethodCounters on demand
>>>> and potentially deallocating them when racing this issue was brought
>>>> to the surface because of more frequent calls to Metaspace::deallocate
>>>> when not at a safepoint.
>>>>
>>>> I was able to reproduce the hang after about an hour by running an
>>>> instrumented build where MethodCounters are allocated and then
>>>> unconditionally deallocated on each entry to
>>>> Method::build_method_counters.
>>>>
>>>> I can't describe the failure mode in detail since I'm not familiar
>>>> with the Mutex code but I can imagine that the locking state machine
>>>> is broken when we take completely different code paths for the same
>>>> Mutex.
>>>>
>>>> Suggested fix:
>>>> My suggested fix is to change Metaspace::deallocate to take the lock
>>>> with Mutex::_no_safepoint_check_flag.
>>>>
>>>> With my fix I ran the test that managed to reproduce the failure
>>>> overnight without reproducing the hang.
>>>> I also ran the parallel class loading tests and nashorn's
>>>> test262parallel for good measure.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>>>> bugs.sun.com:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>>>
>>>> /Mikael
>>>
>>


From thomas.schatzl at oracle.com  Fri Apr 26 12:26:54 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 26 Apr 2013 14:26:54 +0200
Subject: Request for review - 8013032 - CMS: assert(used() ==
	used_after_gc && used_after_gc <= capacity()) failed
In-Reply-To: <51796B42.4080405@oracle.com>
References: <51796B42.4080405@oracle.com>
Message-ID: <1366979214.2808.84.camel@cirrus>

Hi,

On Thu, 2013-04-25 at 10:43 -0700, Jon Masamitsu wrote:
> CMS: assert(used() == used_after_gc && used_after_gc <= capacity()) 
> failed: used: 0 used_after_gc: 292080 capacity: 1431699456
> 
> The assertion was incorrect so I deleted it.  The assumption that the
> metrics being tested should not be affected by the reset_after_compaction()
> was incorrect.
> 
> http://cr.openjdk.java.net/~jmasa/8013032/webrev.00/

In the comment maybe add an explicit note that because of that we cannot
verify heap sizes yet. I.e. something along "So we cannot verify heap
sizes yet".

When reading this comment I asked myselves what the particular reason
for that comment at that point is. I mean, during recomputation of heap
sizes there're often windows where there are inconsistencies between
data. So the comment tells me facts, but not the actual warning what
(not) to do at this point (imho).

But to me this is a minor issue, you may keep the message (or remove the
message altogether).

Thomas



From coleen.phillimore at oracle.com  Fri Apr 26 12:44:29 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 26 Apr 2013 08:44:29 -0400
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <517A6E38.2010805@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
	<51791BA0.9070108@oracle.com> <517A5046.4080702@oracle.com>
	<517A6E38.2010805@oracle.com>
Message-ID: <517A76AD.104@oracle.com>

On 4/26/2013 8:08 AM, Mikael Gerdin wrote:
>> Now an interesting thing with these changes is that one only applies to
>> the VMThread - so what does presence or absence of a safepoint check
>> mean for the VMThread itself? There is only one difference in that case:
>> locking with a safepoint check allows "lock sneaking". But I don't think
>> I need to expand on that here - see mutex.cpp.
>
> The separate VMThread and non-vmthread code paths in this change are 
> unnecessary and I thought Coleen had a change which was going to fix 
> that but I may have been mistaken.

Yes, unifying those code path is in the fix for 8011610: NPG: Class 
metaspace limits number of classes for UseCompressedKlassPointers which 
I'm still working on.
>
>>
>> But this does raise a follow on concern: when the thread is not the
>> VMThread, can it hit a safepoint or otherwise block in the region whilst
>> holding the Metaspace lock? If the answer is yes then we still have a
>> potential safepoint deadlock because the VMThread will not be able to
>> acquire the lock during the safepoint VM_operation and will block.
>
> Currently we don't block in the allocation path and if we need to 
> trigger a GC I believe we release the locks before starting a 
> VM_operation.

The reason we can't check for safepoint in these locks is because GC 
tries to allocate while in the safepoint so takes out these locks 
again.   Which is a different can of worms.

>
>>
>> Aside: this also makes me wonder about the safety of other
>> lock-without-safepoint-check usages.
>
> Indeed, if there is a deadlock possiblility when mixing 
> lock-without-safepoint-check and "normal" lock then we should consider 
> enforcing that a lock is used only for one of the two paths, perhaps 
> using the C++ compiler / type system.

Yes, that would be ideal.

Coleen

>
> /Mikael
>
>>



From david.holmes at oracle.com  Fri Apr 26 12:47:58 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Apr 2013 22:47:58 +1000
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <517A6E38.2010805@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
	<51791BA0.9070108@oracle.com> <517A5046.4080702@oracle.com>
	<517A6E38.2010805@oracle.com>
Message-ID: <517A777E.8080706@oracle.com>

On 26/04/2013 10:08 PM, Mikael Gerdin wrote:
> David,
>
> On 2013-04-26 12:00, David Holmes wrote:
>> On 25/04/2013 10:03 PM, Mikael Gerdin wrote:
>>> On 04/25/2013 01:57 PM, Coleen Phillimore wrote:
>>>>
>>>> I believe this change is correct.  I think if we elide safepoint locks
>>>> for a lock sometimes, we always have to elide safepoint checks for that
>>>> lock.   David will correct me if I'm wrong.
>>>
>>> I also believe that the change is correct.
>>> And I hope that David will chime in on this one.
>>
>> Well .... I think that is accurate though I haven't quite seen it stated
>> that way. The ability to lock without a safepoint check depends, as far
>> as I understand it (and I'm rusty on the details, and the details are
>> complex) on the threads using the lock (and their state) and whether the
>> lock may be needed by the VMThread during a safepoint.
>>
>> Really to see what is going wrong I need to see the stacks of the
>> threads when the deadlock occurs, else it is just speculation as to what
>> might have gone wrong. There is a hint (a strong one) in mutex.cpp:
>>
>> // Lock without safepoint check - a degenerate variant of lock().
>> // Should ONLY be used by safepoint code and other code
>> // that is guaranteed not to block while running inside the VM. If this
>> is called with
>> // thread state set to be in VM, the safepoint synchronization code will
>> deadlock!
>>
>> If a mutator tries to lock without a safepoint check and the lock is
>> held, the thread will block but remain in the _thread_in_vm state. If a
>> safepoint commences during that time the lock owner will not be able to
>> release the lock if it hits a safepoint check first. Meanwhile the
>> VMThread will be waiting for the blocked thread to reach a safepoint
>> safe state - which it never will as it is physically blocked while still
>> _thread_in_vm. Hence deadlock.
>
> This is what I saw in one of the hangs. The VM was trying to safepoint
> and one thread was waiting on the lock with _no_safepoint_check_flag.
>
> This in itself should not be a problem since the last thread to hold the
> lock should have made sure that it woke up the waiting thread when
> leaving the critical region.

The deadlock should be quite simple:

- vmThread is initiating safepoint and is waiting on thread B to be 
safepoint-safe
- thread A holds lock and is blocked at safepoint
- thread B tried to lock-without-safepoint-check and is blocked on the lock

> My theory is that mixing Mutex::lock and
> Mutex::lock_without_safepoint_check somehow leads to a thread leaving
> the lock without signaling that properly to the next in line.
> I've dumped a bit of information on the hang in a text file at:
> http://cr.openjdk.java.net/~mgerdin/8013129/deadlock-info.txt

So here is what has happens. One thread was blocked acquiring the lock 
with a safepoint check. The owning thread releases the lock and wakes 
the first thread. That thread acquires the lock, clears OnDeck and 
returns from ILock at which point the ThreadBlockInVM destructor is 
called. This results in the thread blocking at the safepoint. But note 
that owner is still NULL at this stage. Meanwhile another thread has 
done a lock-without-safepoint-check which goes straight to ILock (which 
doesn't even look at owner) and blocks because the low-level lock is 
indeed held.

Hence deadlock.

>> So the current change to check for safepoints is undoubtedly a safe
>> alternative.
>>
>> Now an interesting thing with these changes is that one only applies to
>> the VMThread - so what does presence or absence of a safepoint check
>> mean for the VMThread itself? There is only one difference in that case:
>> locking with a safepoint check allows "lock sneaking". But I don't think
>> I need to expand on that here - see mutex.cpp.
>
> The separate VMThread and non-vmthread code paths in this change are
> unnecessary and I thought Coleen had a change which was going to fix
> that but I may have been mistaken.
>
>>
>> But this does raise a follow on concern: when the thread is not the
>> VMThread, can it hit a safepoint or otherwise block in the region whilst
>> holding the Metaspace lock? If the answer is yes then we still have a
>> potential safepoint deadlock because the VMThread will not be able to
>> acquire the lock during the safepoint VM_operation and will block.
>
> Currently we don't block in the allocation path and if we need to
> trigger a GC I believe we release the locks before starting a VM_operation.

What about the deallocation path? The thing is that all critical 
sections involving this lock must be non-blocking if the VMThread also 
needs the lock.

>> Aside: this also makes me wonder about the safety of other
>> lock-without-safepoint-check usages.
>
> Indeed, if there is a deadlock possiblility when mixing
> lock-without-safepoint-check and "normal" lock then we should consider
> enforcing that a lock is used only for one of the two paths, perhaps
> using the C++ compiler / type system.

The constraint is only for JavaThreads that must participate in the 
safepoint. Or simply stating that another way, as it says in mutex.hpp, 
no thread that is _thread_in_vm should ever lock without a safepoint 
check. I wonder why we don't assert that in lock_without_safepoint_check?

David
-----

> /Mikael
>
>>
>>
>> David
>> -----
>>
>>> /Mikael
>>>
>>>>
>>>> Coleen
>>>>
>>>> On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
>>>>> Hi,
>>>>>
>>>>> Problem:
>>>>> We've seen some hangs in the GC nightly testing recently.
>>>>> When I looked at the minidump files from some of those hangs they
>>>>> looked like safepoint deadlocks where one thread was parked in
>>>>> Mutex::lock_without_safepoint_check on one of the "Metaspace
>>>>> allocation locks".
>>>>>
>>>>> Both of the hangs I investigated also had threads trying to lock the
>>>>> same Metaspace lock but without eliding safepoint checks because they
>>>>> were originating from Metaspace::deallocate.
>>>>>
>>>>> I believe that since the change to allocate MethodCounters on demand
>>>>> and potentially deallocating them when racing this issue was brought
>>>>> to the surface because of more frequent calls to Metaspace::deallocate
>>>>> when not at a safepoint.
>>>>>
>>>>> I was able to reproduce the hang after about an hour by running an
>>>>> instrumented build where MethodCounters are allocated and then
>>>>> unconditionally deallocated on each entry to
>>>>> Method::build_method_counters.
>>>>>
>>>>> I can't describe the failure mode in detail since I'm not familiar
>>>>> with the Mutex code but I can imagine that the locking state machine
>>>>> is broken when we take completely different code paths for the same
>>>>> Mutex.
>>>>>
>>>>> Suggested fix:
>>>>> My suggested fix is to change Metaspace::deallocate to take the lock
>>>>> with Mutex::_no_safepoint_check_flag.
>>>>>
>>>>> With my fix I ran the test that managed to reproduce the failure
>>>>> overnight without reproducing the hang.
>>>>> I also ran the parallel class loading tests and nashorn's
>>>>> test262parallel for good measure.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>>>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>>>>> bugs.sun.com:
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>>>>
>>>>> /Mikael
>>>>
>>>


From yumin.qi at oracle.com  Fri Apr 26 14:30:52 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 26 Apr 2013 07:30:52 -0700
Subject: RFR: 8012902: remove use of global operator new - take 2
In-Reply-To: <1366962513.2808.9.camel@cirrus>
References: <517A2356.1060606@oracle.com> <1366962513.2808.9.camel@cirrus>
Message-ID: <517A8F9C.3010308@oracle.com>

Thomas,  Thanks.

Yumin
On 4/26/2013 12:48 AM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2013-04-25 at 23:48 -0700, Yumin Qi wrote:
>> HI, all
>>
>>     This bug is filed after this bug
>>     8010992: Remove calls to global ::operator new[] and new
>>     was anti-delta'ed due to testing failure on JVMTI. Now it takes both.
>>
>>     http://cr.openjdk.java.net/~minqi/8012902/webrev/
>
> The allocation in
>
> ./src/share/vm/gc_implementation/g1/g1RemSet.cpp:    ct_freq = new
> jbyte[ct_freq_sz];
>
> seems to have been overlooked. It's in some debug code that is never
> used at the moment.
>
> (I used an "egrep "new .*\[.+\]" `find . -name '*.?pp'`" to find that).
>
> Could you fix that one too?
>
> Thanks,
> Thomas
>
>



From mikael.gerdin at oracle.com  Fri Apr 26 14:57:08 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Fri, 26 Apr 2013 16:57:08 +0200
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <517A777E.8080706@oracle.com>
References: <5178F2F8.7020900@oracle.com> <51791A3B.2060608@oracle.com>
	<51791BA0.9070108@oracle.com> <517A5046.4080702@oracle.com>
	<517A6E38.2010805@oracle.com> <517A777E.8080706@oracle.com>
Message-ID: <517A95C4.6080701@oracle.com>

David,

On 2013-04-26 14:47, David Holmes wrote:
> On 26/04/2013 10:08 PM, Mikael Gerdin wrote:
>> David,
>>
>> On 2013-04-26 12:00, David Holmes wrote:
>>> On 25/04/2013 10:03 PM, Mikael Gerdin wrote:
>>>> On 04/25/2013 01:57 PM, Coleen Phillimore wrote:
>>>>>
>>>>> I believe this change is correct.  I think if we elide safepoint locks
>>>>> for a lock sometimes, we always have to elide safepoint checks for
>>>>> that
>>>>> lock.   David will correct me if I'm wrong.
>>>>
>>>> I also believe that the change is correct.
>>>> And I hope that David will chime in on this one.
>>>
>>> Well .... I think that is accurate though I haven't quite seen it stated
>>> that way. The ability to lock without a safepoint check depends, as far
>>> as I understand it (and I'm rusty on the details, and the details are
>>> complex) on the threads using the lock (and their state) and whether the
>>> lock may be needed by the VMThread during a safepoint.
>>>
>>> Really to see what is going wrong I need to see the stacks of the
>>> threads when the deadlock occurs, else it is just speculation as to what
>>> might have gone wrong. There is a hint (a strong one) in mutex.cpp:
>>>
>>> // Lock without safepoint check - a degenerate variant of lock().
>>> // Should ONLY be used by safepoint code and other code
>>> // that is guaranteed not to block while running inside the VM. If this
>>> is called with
>>> // thread state set to be in VM, the safepoint synchronization code will
>>> deadlock!
>>>
>>> If a mutator tries to lock without a safepoint check and the lock is
>>> held, the thread will block but remain in the _thread_in_vm state. If a
>>> safepoint commences during that time the lock owner will not be able to
>>> release the lock if it hits a safepoint check first. Meanwhile the
>>> VMThread will be waiting for the blocked thread to reach a safepoint
>>> safe state - which it never will as it is physically blocked while still
>>> _thread_in_vm. Hence deadlock.
>>
>> This is what I saw in one of the hangs. The VM was trying to safepoint
>> and one thread was waiting on the lock with _no_safepoint_check_flag.
>>
>> This in itself should not be a problem since the last thread to hold the
>> lock should have made sure that it woke up the waiting thread when
>> leaving the critical region.
>
> The deadlock should be quite simple:
>
> - vmThread is initiating safepoint and is waiting on thread B to be
> safepoint-safe
> - thread A holds lock and is blocked at safepoint
> - thread B tried to lock-without-safepoint-check and is blocked on the lock

I think that's the same conclusion I came to in the end as well.

>
>> My theory is that mixing Mutex::lock and
>> Mutex::lock_without_safepoint_check somehow leads to a thread leaving
>> the lock without signaling that properly to the next in line.
>> I've dumped a bit of information on the hang in a text file at:
>> http://cr.openjdk.java.net/~mgerdin/8013129/deadlock-info.txt
>
> So here is what has happens. One thread was blocked acquiring the lock
> with a safepoint check. The owning thread releases the lock and wakes
> the first thread. That thread acquires the lock, clears OnDeck and
> returns from ILock at which point the ThreadBlockInVM destructor is
> called. This results in the thread blocking at the safepoint. But note
> that owner is still NULL at this stage. Meanwhile another thread has
> done a lock-without-safepoint-check which goes straight to ILock (which
> doesn't even look at owner) and blocks because the low-level lock is
> indeed held.
>
> Hence deadlock.

Thanks for this detailed description David.

>
>>> So the current change to check for safepoints is undoubtedly a safe
>>> alternative.
>>>
>>> Now an interesting thing with these changes is that one only applies to
>>> the VMThread - so what does presence or absence of a safepoint check
>>> mean for the VMThread itself? There is only one difference in that case:
>>> locking with a safepoint check allows "lock sneaking". But I don't think
>>> I need to expand on that here - see mutex.cpp.
>>
>> The separate VMThread and non-vmthread code paths in this change are
>> unnecessary and I thought Coleen had a change which was going to fix
>> that but I may have been mistaken.
>>
>>>
>>> But this does raise a follow on concern: when the thread is not the
>>> VMThread, can it hit a safepoint or otherwise block in the region whilst
>>> holding the Metaspace lock? If the answer is yes then we still have a
>>> potential safepoint deadlock because the VMThread will not be able to
>>> acquire the lock during the safepoint VM_operation and will block.
>>
>> Currently we don't block in the allocation path and if we need to
>> trigger a GC I believe we release the locks before starting a
>> VM_operation.
>
> What about the deallocation path? The thing is that all critical
> sections involving this lock must be non-blocking if the VMThread also
> needs the lock.

The deallocation path is also non-blocking.

>
>>> Aside: this also makes me wonder about the safety of other
>>> lock-without-safepoint-check usages.
>>
>> Indeed, if there is a deadlock possiblility when mixing
>> lock-without-safepoint-check and "normal" lock then we should consider
>> enforcing that a lock is used only for one of the two paths, perhaps
>> using the C++ compiler / type system.
>
> The constraint is only for JavaThreads that must participate in the
> safepoint. Or simply stating that another way, as it says in mutex.hpp,
> no thread that is _thread_in_vm should ever lock without a safepoint
> check. I wonder why we don't assert that in lock_without_safepoint_check?

Currently every metaspace allocation will take the metaspace allocation 
lock with lock_without_safepoint_check while the thread is 
_thread_in_vm. I can's say if any other locks are used that way but 
since we don't assert it I'm sure someone else does it as well.

If we could have separate Mutex/MutexLocker classes for locks which have 
safepoint checks and locks which don't have them we would at least get 
rid of the problem with mixing them on the same lock.

/Mikael

>
> David
> -----
>
>> /Mikael
>>
>>>
>>>
>>> David
>>> -----
>>>
>>>> /Mikael
>>>>
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 4/25/2013 5:10 AM, Mikael Gerdin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Problem:
>>>>>> We've seen some hangs in the GC nightly testing recently.
>>>>>> When I looked at the minidump files from some of those hangs they
>>>>>> looked like safepoint deadlocks where one thread was parked in
>>>>>> Mutex::lock_without_safepoint_check on one of the "Metaspace
>>>>>> allocation locks".
>>>>>>
>>>>>> Both of the hangs I investigated also had threads trying to lock the
>>>>>> same Metaspace lock but without eliding safepoint checks because they
>>>>>> were originating from Metaspace::deallocate.
>>>>>>
>>>>>> I believe that since the change to allocate MethodCounters on demand
>>>>>> and potentially deallocating them when racing this issue was brought
>>>>>> to the surface because of more frequent calls to
>>>>>> Metaspace::deallocate
>>>>>> when not at a safepoint.
>>>>>>
>>>>>> I was able to reproduce the hang after about an hour by running an
>>>>>> instrumented build where MethodCounters are allocated and then
>>>>>> unconditionally deallocated on each entry to
>>>>>> Method::build_method_counters.
>>>>>>
>>>>>> I can't describe the failure mode in detail since I'm not familiar
>>>>>> with the Mutex code but I can imagine that the locking state machine
>>>>>> is broken when we take completely different code paths for the same
>>>>>> Mutex.
>>>>>>
>>>>>> Suggested fix:
>>>>>> My suggested fix is to change Metaspace::deallocate to take the lock
>>>>>> with Mutex::_no_safepoint_check_flag.
>>>>>>
>>>>>> With my fix I ran the test that managed to reproduce the failure
>>>>>> overnight without reproducing the hang.
>>>>>> I also ran the parallel class loading tests and nashorn's
>>>>>> test262parallel for good measure.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>>>>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>>>>>> bugs.sun.com:
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>>>>>
>>>>>> /Mikael
>>>>>
>>>>


From stefan.karlsson at oracle.com  Fri Apr 26 15:02:34 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 26 Apr 2013 17:02:34 +0200
Subject: Review request: 8013132: Add a flag to turn off the output of
	the verbose verification code
In-Reply-To: <517961DC.7060800@oracle.com>
References: <5178207E.1080209@oracle.com> <51787FFB.3000103@oracle.com>
	<5178D59E.5020908@oracle.com> <517961DC.7060800@oracle.com>
Message-ID: <517A970A.2060104@oracle.com>

On 04/25/2013 07:03 PM, John Cuthbertson wrote:
> Hi Stefan,
>
> Apologies - I wasn't clear. What I meant was: should VerifySilently be 
> explicitly disabled  in the test?

I don't that's needed. If someone changes the test flags or the default 
value, we'll find it and fix it then.

StefanK

>
> JohnC
>
> On 4/25/2013 12:05 AM, Stefan Karlsson wrote:
>> On 04/25/2013 02:59 AM, John Cuthbertson wrote:
>>> Hi Stefan,
>>>
>>> Looks fine to me.
>>
>> Thanks, John.
>>
>>>
>>> One minor point - this will affect the reg test I sent out for 
>>> review yesterday which explicitly looks for "[Verifying..."
>>
>> The flag is off by default, so this will not affect  your test. I've 
>> verified this by applying you patch.
>>
>> thanks,
>> StefanK
>>
>>>
>>> JohnC
>>>
>>> On 4/24/2013 11:12 AM, Stefan Karlsson wrote:
>>>> http://cr.openjdk.java.net/~stefank/8013132/webrev.00/
>>>>
>>>> This RFE adds a new flag named VerifySilently, which can be used to 
>>>> turn off the verbose output that the verification code produces. 
>>>> The proposed name has been chosen to match other Verify flags.
>>>>
>>>> From the Bug description:
>>>> ---
>>>> The HotSpot verification code is rather verbose and intrusive. I 
>>>> propose that we add a flag that can be used to turn this output off.
>>>>
>>>> An example of the verification output:
>>>> $ java -XX:+PrintGC -XX:+UnlockDiagnosticVMOptions 
>>>> -XX:+VerifyBeforeExit -XX:+VerifyAfterGC -XX:+VerifyBeforeGC 
>>>> -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -cp 
>>>> /localhome/tests/ HelloSystemGC
>>>>  VerifyBeforeGC:[Verifying threads heap concurrent mark-sweep 
>>>> generation par new generation remset syms strs zone dict cldg 
>>>> metaspace chunks hand C-heap code cache ]
>>>> [GC (System.gc()) 672K->260K(121600K), 0.0060920 secs]
>>>>  VerifyAfterGC:[Verifying threads heap concurrent mark-sweep 
>>>> generation par new generation remset syms strs zone dict cldg 
>>>> metaspace chunks hand C-heap code cache ]
>>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>>> C-heap code cache ]
>>>> [GC (CMS Initial Mark) 260K(121600K), 0.0204040 secs]
>>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>>> C-heap code cache ]
>>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>>> C-heap code cache ]
>>>> [GC (CMS Final Remark) [Verifying CMS Marking... done] 
>>>> 1604K(121600K), 0.1008210 secs]
>>>> [Verifying threads heap concurrent mark-sweep generation par new 
>>>> generation remset syms strs zone dict cldg metaspace chunks hand 
>>>> C-heap code cache ]
>>>>
>>>> And with the proposed flag turned on:
>>>> [GC (System.gc()) 672K->269K(121600K), 0.0050710 secs]
>>>> [GC (CMS Initial Mark) 269K(121600K), 0.0203380 secs]
>>>> [GC (CMS Final Remark) 1613K(121600K), 0.1007210 secs]
>>>> ---
>>>>
>>>> thanks,
>>>> StefanK
>>>
>>
>

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

From stefan.karlsson at oracle.com  Fri Apr 26 16:20:49 2013
From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com)
Date: Fri, 26 Apr 2013 16:20:49 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8013160: NPG: Remove unnecessary mark
	stack draining after CodeCache::do_unloading
Message-ID: <20130426162054.40AAC4863A@hg.openjdk.java.net>

Changeset: 2f50bc369470
Author:    stefank
Date:      2013-04-26 10:40 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2f50bc369470

8013160: NPG: Remove unnecessary mark stack draining after CodeCache::do_unloading
Reviewed-by: coleenp, mgerdin

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/memory/genMarkSweep.cpp



From jon.masamitsu at oracle.com  Fri Apr 26 17:09:24 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 26 Apr 2013 10:09:24 -0700
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <517A3784.1060701@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com> <5179A46E.9070605@oracle.com>
	<517A3784.1060701@oracle.com>
Message-ID: <517AB4C4.8060509@oracle.com>

http://cr.openjdk.java.net/~stefank/8013160/webrev.00/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.frames.html

I understand that the point of the change was that CodeCache::do_unloading()
cannot not add to the marking stack anymore but the
original code was less trusting in that it called for verification
when it really thought it was not needed.  For example,

> 6047   verify_work_stacks_empty();

Any second thoughts on removing the later calls to 
verify_work_stacks_empty()?
If you think it can never happen and it's not worth checking (and cluttering
the code) no problem.  Either way, looks good.

Jon



On 4/26/2013 1:15 AM, Stefan Karlsson wrote:
> On 04/25/2013 11:47 PM, Coleen Phillimore wrote:
>>
>> Hi, Sorry Stefan I think I liked your .00 version better.   Now 
>> there's a level of indirection and it doesn't seem to save any code 
>> because the call sites are slightly different.
>
> It only saves code duplication in four of the collectors, the other 
> two still does the unloading differently.
>
> Could someone else review the .00 version?
> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>
> thanks,
> StefanK
>
>>
>> Coleen
>>
>> On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
>>> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>>>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Stefan,
>>>>>>
>>>>>> Is there a common place for this code?
>>>>>
>>>>> I don't think there's any common place in the GCs for this. I'm 
>>>>> open for suggestions if you know a good place in the runtime code.
>>>>
>>>> memory/genCollectedHeap?   I have no idea...
>>>>>
>>>>>> It's 4 copies of the similar code, which takes me a while to find 
>>>>>> when I set out looking for it.
>>>>>
>>>>> Yes, I tried to make them look alike so that we/I have an 
>>>>> opportunity to extract it out to one function. The fact that CMS 
>>>>> does this differently made me hesitant to combine them.
>>>>>
>>>>>> In the future, I think StringTable::unlink() could be moved after 
>>>>>> CLDG::purge() which I thought should be around here too (but it's 
>>>>>> not).   The only reason StringTable::unlink() used to be here was 
>>>>>> because it used to have Oops in it.
>>>>>
>>>>> Don't you mean the SymbolTable? I'm OK with moving the 
>>>>> SymbolTable, but not the StringTable ...
>>>>
>>>> I did mean SymbolTable.
>>>>
>>>>>
>>>>>>    Can you unite this duplicated code?
>>>>>
>>>>> It's easy to unit the code for psMarkSweep, genMarkSweep, 
>>>>> g1MarkSweep and psParallelCompact but it's a bit more work to also 
>>>>> unify the CMS code. Would it be good enough for this patch if I 
>>>>> united the former GCs? And maybe handle CMS when G1 also starts 
>>>>> doing class unloading?
>>>>
>>>> Ok, keep it in mind for future work.  It would be nice to have the 
>>>> runtime GC things be called in one place or easy to find.
>>>>
>>>> I semi-reviewed the code and except for the GC part (which is most 
>>>> of the change).   We don't pass the keep_alive closure anymore for 
>>>> compiledICHolders so I guess this makes sense if this is what the 
>>>> keep_alive closure did.   So this is a partial review.
>>>
>>> I've update the patch to gather the unloading code in a helper class 
>>> called GCUnloading. What do you think?
>>>
>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>>>
>>> thanks,
>>> StefanK
>>>
>>>>
>>>> Thanks,
>>>> Coleen
>>>>>
>>>>> thanks,
>>>>> StefanK
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>>>
>>>>>>> There's some remnants from the PermGen that's confusing in the 
>>>>>>> class unloading code. This patch removes the unnecessary code, 
>>>>>>> cleans up some comments and unifies the code structure over 
>>>>>>> different GCs.
>>>>>>>
>>>>>>> From the Bug report:
>>>>>>> ---
>>>>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>>>>> objects to C++ objects.
>>>>>>>
>>>>>>> CodeCache::do_unloading(...) used to take a keep_alive closure 
>>>>>>> that was applied to CompiledICHolders deep down in 
>>>>>>> nmethod::do_unloading. Since CompileICHolders don't move 
>>>>>>> anymore, and we have other ways to keep them alive, we don't use 
>>>>>>> the keep_alive closures in these functions anymore.
>>>>>>>
>>>>>>> Because of this, CodeCache::do_unloading will not populate the 
>>>>>>> marking stacks, and we can remove the call to drain the stacks 
>>>>>>> after the calls to CodeCache::do_unloading.
>>>>>>>
>>>>>>> This also has the neat effect that we now can verify that the 
>>>>>>> marking has really completed before we start unloading classes, 
>>>>>>> which makes the code easier to maintain/understand.
>>>>>>> ---
>>>>>>>
>>>>>>> thanks,
>>>>>>> StefanK
>>>>>>
>>>>>
>>>>
>>>
>>
>
>



From jon.masamitsu at oracle.com  Fri Apr 26 17:13:26 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 26 Apr 2013 10:13:26 -0700
Subject: Request for review - 8013032 - CMS: assert(used() == used_after_gc
	&& used_after_gc <= capacity()) failed
In-Reply-To: <1366979214.2808.84.camel@cirrus>
References: <51796B42.4080405@oracle.com> <1366979214.2808.84.camel@cirrus>
Message-ID: <517AB5B6.6030909@oracle.com>

Thomas,

I can remove the comments.  They are there mostly to explain why the
assertion checking should be removed for the code reviewer.  I've 
removed them.

Jon

On 4/26/2013 5:26 AM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2013-04-25 at 10:43 -0700, Jon Masamitsu wrote:
>> CMS: assert(used() == used_after_gc && used_after_gc <= capacity())
>> failed: used: 0 used_after_gc: 292080 capacity: 1431699456
>>
>> The assertion was incorrect so I deleted it.  The assumption that the
>> metrics being tested should not be affected by the reset_after_compaction()
>> was incorrect.
>>
>> http://cr.openjdk.java.net/~jmasa/8013032/webrev.00/
> In the comment maybe add an explicit note that because of that we cannot
> verify heap sizes yet. I.e. something along "So we cannot verify heap
> sizes yet".
>
> When reading this comment I asked myselves what the particular reason
> for that comment at that point is. I mean, during recomputation of heap
> sizes there're often windows where there are inconsistencies between
> data. So the comment tells me facts, but not the actual warning what
> (not) to do at this point (imho).
>
> But to me this is a minor issue, you may keep the message (or remove the
> message altogether).
>
> Thomas
>



From john.cuthbertson at oracle.com  Fri Apr 26 19:58:35 2013
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Fri, 26 Apr 2013 19:58:35 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8011898:
	gc/TestVerifyBeforeGCDuringStartup.java:
	java.lang.RuntimeException: '[Verifying' missing from
	stdout/stderr: [Error: Could not find or load main class]
Message-ID: <20130426195837.092F44864B@hg.openjdk.java.net>

Changeset: 3edf23423bb2
Author:    johnc
Date:      2013-04-26 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3edf23423bb2

8011898: gc/TestVerifyBeforeGCDuringStartup.java: java.lang.RuntimeException: '[Verifying' missing from stdout/stderr: [Error: Could not find or load main class]
Summary: System.getProperty("test.java.opts") can return NULL, which gets converted to to the empty string, and the child java command then interprets that as the name of the main class.
Reviewed-by: jmasa, brutisso

! test/gc/TestVerifyDuringStartup.java



From stefan.karlsson at oracle.com  Mon Apr 29 06:57:16 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 29 Apr 2013 08:57:16 +0200
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <517AB4C4.8060509@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com> <5179A46E.9070605@oracle.com>
	<517A3784.1060701@oracle.com> <517AB4C4.8060509@oracle.com>
Message-ID: <517E19CC.7040504@oracle.com>

On 04/26/2013 07:09 PM, Jon Masamitsu wrote:
> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.frames.html 
>
>
> I understand that the point of the change was that 
> CodeCache::do_unloading()
> cannot not add to the marking stack anymore but the
> original code was less trusting in that it called for verification
> when it really thought it was not needed.  For example,
>
>> 6047   verify_work_stacks_empty();
>
> Any second thoughts on removing the later calls to 
> verify_work_stacks_empty()?
> If you think it can never happen and it's not worth checking (and 
> cluttering
> the code) no problem.  Either way, looks good.

I wanted to remove the later, unnecessary calls to 
verify_work_stacks_empty(), to clearly mark the place above where we 
stop populating the marking stacks.

thanks,
StefanK

>
> Jon
>
>
>
> On 4/26/2013 1:15 AM, Stefan Karlsson wrote:
>> On 04/25/2013 11:47 PM, Coleen Phillimore wrote:
>>>
>>> Hi, Sorry Stefan I think I liked your .00 version better. Now 
>>> there's a level of indirection and it doesn't seem to save any code 
>>> because the call sites are slightly different.
>>
>> It only saves code duplication in four of the collectors, the other 
>> two still does the unloading differently.
>>
>> Could someone else review the .00 version?
>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>
>> thanks,
>> StefanK
>>
>>>
>>> Coleen
>>>
>>> On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
>>>> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>>>>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>>>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>>>>
>>>>>>> Stefan,
>>>>>>>
>>>>>>> Is there a common place for this code?
>>>>>>
>>>>>> I don't think there's any common place in the GCs for this. I'm 
>>>>>> open for suggestions if you know a good place in the runtime code.
>>>>>
>>>>> memory/genCollectedHeap?   I have no idea...
>>>>>>
>>>>>>> It's 4 copies of the similar code, which takes me a while to 
>>>>>>> find when I set out looking for it.
>>>>>>
>>>>>> Yes, I tried to make them look alike so that we/I have an 
>>>>>> opportunity to extract it out to one function. The fact that CMS 
>>>>>> does this differently made me hesitant to combine them.
>>>>>>
>>>>>>> In the future, I think StringTable::unlink() could be moved 
>>>>>>> after CLDG::purge() which I thought should be around here too 
>>>>>>> (but it's not).   The only reason StringTable::unlink() used to 
>>>>>>> be here was because it used to have Oops in it.
>>>>>>
>>>>>> Don't you mean the SymbolTable? I'm OK with moving the 
>>>>>> SymbolTable, but not the StringTable ...
>>>>>
>>>>> I did mean SymbolTable.
>>>>>
>>>>>>
>>>>>>>    Can you unite this duplicated code?
>>>>>>
>>>>>> It's easy to unit the code for psMarkSweep, genMarkSweep, 
>>>>>> g1MarkSweep and psParallelCompact but it's a bit more work to 
>>>>>> also unify the CMS code. Would it be good enough for this patch 
>>>>>> if I united the former GCs? And maybe handle CMS when G1 also 
>>>>>> starts doing class unloading?
>>>>>
>>>>> Ok, keep it in mind for future work.  It would be nice to have the 
>>>>> runtime GC things be called in one place or easy to find.
>>>>>
>>>>> I semi-reviewed the code and except for the GC part (which is most 
>>>>> of the change).   We don't pass the keep_alive closure anymore for 
>>>>> compiledICHolders so I guess this makes sense if this is what the 
>>>>> keep_alive closure did. So this is a partial review.
>>>>
>>>> I've update the patch to gather the unloading code in a helper 
>>>> class called GCUnloading. What do you think?
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>>>>
>>>> thanks,
>>>> StefanK
>>>>
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>>
>>>>>> thanks,
>>>>>> StefanK
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>>>>
>>>>>>>> There's some remnants from the PermGen that's confusing in the 
>>>>>>>> class unloading code. This patch removes the unnecessary code, 
>>>>>>>> cleans up some comments and unifies the code structure over 
>>>>>>>> different GCs.
>>>>>>>>
>>>>>>>> From the Bug report:
>>>>>>>> ---
>>>>>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>>>>>> objects to C++ objects.
>>>>>>>>
>>>>>>>> CodeCache::do_unloading(...) used to take a keep_alive closure 
>>>>>>>> that was applied to CompiledICHolders deep down in 
>>>>>>>> nmethod::do_unloading. Since CompileICHolders don't move 
>>>>>>>> anymore, and we have other ways to keep them alive, we don't 
>>>>>>>> use the keep_alive closures in these functions anymore.
>>>>>>>>
>>>>>>>> Because of this, CodeCache::do_unloading will not populate the 
>>>>>>>> marking stacks, and we can remove the call to drain the stacks 
>>>>>>>> after the calls to CodeCache::do_unloading.
>>>>>>>>
>>>>>>>> This also has the neat effect that we now can verify that the 
>>>>>>>> marking has really completed before we start unloading classes, 
>>>>>>>> which makes the code easier to maintain/understand.
>>>>>>>> ---
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> StefanK
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>



From mikael.gerdin at oracle.com  Mon Apr 29 08:35:09 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 29 Apr 2013 10:35:09 +0200
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <5178F2F8.7020900@oracle.com>
References: <5178F2F8.7020900@oracle.com>
Message-ID: <517E30BD.9030507@oracle.com>

Hi,

If nobody objects I'd like to push this today, it's causing test 
timeouts in our nightly testing and I'd like to get rid of them as soon 
as possible.

/Mikael

On 2013-04-25 11:10, Mikael Gerdin wrote:
> Hi,
>
> Problem:
> We've seen some hangs in the GC nightly testing recently.
> When I looked at the minidump files from some of those hangs they looked
> like safepoint deadlocks where one thread was parked in
> Mutex::lock_without_safepoint_check on one of the "Metaspace allocation
> locks".
>
> Both of the hangs I investigated also had threads trying to lock the
> same Metaspace lock but without eliding safepoint checks because they
> were originating from Metaspace::deallocate.
>
> I believe that since the change to allocate MethodCounters on demand and
> potentially deallocating them when racing this issue was brought to the
> surface because of more frequent calls to Metaspace::deallocate when not
> at a safepoint.
>
> I was able to reproduce the hang after about an hour by running an
> instrumented build where MethodCounters are allocated and then
> unconditionally deallocated on each entry to Method::build_method_counters.
>
> I can't describe the failure mode in detail since I'm not familiar with
> the Mutex code but I can imagine that the locking state machine is
> broken when we take completely different code paths for the same Mutex.
>
> Suggested fix:
> My suggested fix is to change Metaspace::deallocate to take the lock
> with Mutex::_no_safepoint_check_flag.
>
> With my fix I ran the test that managed to reproduce the failure
> overnight without reproducing the hang.
> I also ran the parallel class loading tests and nashorn's
> test262parallel for good measure.
>
> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>
> /Mikael


From thomas.schatzl at oracle.com  Mon Apr 29 10:06:59 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 29 Apr 2013 12:06:59 +0200
Subject: Request for review - 8013032 - CMS: assert(used() ==
	used_after_gc && used_after_gc <= capacity()) failed
In-Reply-To: <517AB5B6.6030909@oracle.com>
References: <51796B42.4080405@oracle.com> <1366979214.2808.84.camel@cirrus>
	<517AB5B6.6030909@oracle.com>
Message-ID: <1367230019.2710.60.camel@cirrus>

Hi,

On Fri, 2013-04-26 at 10:13 -0700, Jon Masamitsu wrote:
> Thomas,
> 
> I can remove the comments.  They are there mostly to explain why the
> assertion checking should be removed for the code reviewer.  I've 
> removed them.

Fine. Thanks.

 Thomas




From mikael.gerdin at oracle.com  Mon Apr 29 10:27:34 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Mon, 29 Apr 2013 10:27:34 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 27 new changesets
Message-ID: <20130429102830.53D4648682@hg.openjdk.java.net>

Changeset: 63e31ce40bdb
Author:    hseigel
Date:      2013-04-17 08:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/63e31ce40bdb

8009928: PSR:PERF Increase default string table size
Summary: Increase default string table size to 60013 for 64-bit platforms.
Reviewed-by: coleenp, dholmes

! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: b80cc96882f7
Author:    zgu
Date:      2013-04-18 10:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b80cc96882f7

8012464: NMT: classes should not derive from _ValueObj, use VALUE_OBJ_CLASS_SPEC instead
Summary: NMT value objects should use VALUE_OBJ_CLASS_SPEC instead of deriving from _ValueObj
Reviewed-by: coleenp, hseigel, dholmes

! src/share/vm/services/memBaseline.hpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTrackWorker.hpp

Changeset: 41ed397cc0cd
Author:    bharadwaj
Date:      2013-04-18 08:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/41ed397cc0cd

8006267: InterfaceMethod_ref should allow invokestatic and invokespecial
Summary: Lambda changes; spec 0.6.2 - Allow static invokestatic and invokespecial calls to InterfaceMethod_ref
Reviewed-by: dholmes, acorn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/genericSignatures.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/prims/methodHandles.cpp

Changeset: 7815eaceaa8c
Author:    bharadwaj
Date:      2013-04-18 14:03 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7815eaceaa8c

Merge


Changeset: 6f817ce50129
Author:    minqi
Date:      2013-04-19 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6f817ce50129

8010992: Remove calls to global ::operator new[] and new
Summary: disable use of global operator new and new[] which could cause unexpected exception and escape from NMT tracking.
Reviewed-by: coleenp, dholmes, zgu
Contributed-by: yumin.qi at oracle.com

! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/opto/idealGraphPrinter.hpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/events.hpp
! src/share/vm/utilities/quickSort.cpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp

Changeset: 17c51f84773a
Author:    dcubed
Date:      2013-04-19 13:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/17c51f84773a

Merge


Changeset: 5b6512efcdc4
Author:    dcubed
Date:      2013-04-19 16:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5b6512efcdc4

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6337ca4dcad8
Author:    sspitsyn
Date:      2013-04-20 04:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6337ca4dcad8

8008511: JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition
Summary: Lazily create and maintain the MemberNameTable to be able to update MemberName's
Reviewed-by: coleenp, jrose, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp

Changeset: a527ddd44e07
Author:    mgronlun
Date:      2013-04-20 19:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a527ddd44e07

6729929: I18N - Taking Heap Dump failed if project path contains multibyte characters
Reviewed-by: dholmes, rbackman
Contributed-by: peter.allwin at oracle.com

! src/share/vm/services/management.cpp

Changeset: 5a9fa2ba85f0
Author:    dcubed
Date:      2013-04-21 20:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5a9fa2ba85f0

8012907: anti-delta fix for 8010992
Summary: anti-delta fix for 8010992 until 8012902 can be fixed
Reviewed-by: acorn, minqi, rdurbin

! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/opto/idealGraphPrinter.hpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/events.hpp
! src/share/vm/utilities/quickSort.cpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp

Changeset: cc12becb22e7
Author:    dcubed
Date:      2013-04-21 21:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cc12becb22e7

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ce6d7e43501c
Author:    bharadwaj
Date:      2013-04-23 08:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ce6d7e43501c

8012961: Do not restrict static interface methods to be private
Summary: Lambda changes; spec 0.6.2 - remove the restriction that was added as part of recent changes made to support upcoming changes to compilation of lambda methods.
Reviewed-by: dholmes, acorn

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

Changeset: 1ea6a35dcbe5
Author:    jiangli
Date:      2013-04-23 12:32 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1ea6a35dcbe5

8012927: 'assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range' in interpreter initialization.
Summary: Change br_null_short() to br_null().
Reviewed-by: coleenp, hseigel

! src/cpu/sparc/vm/interp_masm_sparc.cpp

Changeset: 35c15dad89ea
Author:    roland
Date:      2013-04-16 17:06 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/35c15dad89ea

8011901: Unsafe.getAndAddLong(obj, off, delta) does not work properly with long deltas
Summary: instruct xaddL_no_res shouldn't allow 64 bit constants.
Reviewed-by: kvn

! src/cpu/x86/vm/x86_64.ad
+ test/compiler/8011901/Test8011901.java

Changeset: 6a3629cf7075
Author:    roland
Date:      2013-04-24 09:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6a3629cf7075

8011771: runThese crashed with EAV
Summary: Array bound check elimination's in block motion doesn't always reset its data structures from one step to the other.
Reviewed-by: kvn, twisti

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

Changeset: 47766e2d2527
Author:    jiangli
Date:      2013-04-24 18:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/47766e2d2527

8013041: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset.
Summary: Change jmpb() to jmp().
Reviewed-by: coleenp, rdurbin, dcubed

! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp

Changeset: e8a7a5995e65
Author:    bharadwaj
Date:      2013-04-25 13:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e8a7a5995e65

Merge


Changeset: 3d641132f83b
Author:    twisti
Date:      2013-02-26 16:16 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3d641132f83b

8004336: Better handling of method handle intrinsic frames
Reviewed-by: kvn, jrose, ahgross

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

Changeset: 124ca22437b1
Author:    chegar
Date:      2013-04-12 10:14 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/124ca22437b1

Merge

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

Changeset: 6c560f9ebb3e
Author:    lana
Date:      2013-04-17 10:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6c560f9ebb3e

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: db9c527a1fd8
Author:    lana
Date:      2013-04-17 21:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db9c527a1fd8

Merge


Changeset: d4c266784660
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d4c266784660

Merge


Changeset: d080f5168deb
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d080f5168deb

Added tag jdk8-b87 for changeset d4c266784660

! .hgtags

Changeset: c4af77d20454
Author:    amurillo
Date:      2013-04-26 00:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c4af77d20454

Merge

! .hgtags
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp

Changeset: 8482058e74bc
Author:    amurillo
Date:      2013-04-26 00:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8482058e74bc

Added tag hs25-b30 for changeset c4af77d20454

! .hgtags

Changeset: 57ac6a688ae6
Author:    amurillo
Date:      2013-04-26 00:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/57ac6a688ae6

8013227: new hotspot build - hs25-b31
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: caac22686b17
Author:    mgerdin
Date:      2013-04-29 09:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/caac22686b17

Merge

! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/runtime/thread.cpp



From david.holmes at oracle.com  Mon Apr 29 13:00:55 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 Apr 2013 23:00:55 +1000
Subject: RFR: 8012902: remove use of global operator new - take 2
In-Reply-To: <517A2356.1060606@oracle.com>
References: <517A2356.1060606@oracle.com>
Message-ID: <517E6F07.4050307@oracle.com>

Hi Yumin,

I think we need to pull back on this until we can address the broader 
issues:

a) there are a number of classes that don't obey the rules about 
extending one of the allocation types

b) adding additional operator new/new[] for explicit C-Heap usage 
conflicts with the use of the existing macros/functions documented in 
allocation.hpp (I still think I prefer NEW_C_HEAP_OBJ + global placement 
new to invoke the correct constructor). If you stick with your approach 
then the documentation in allocation.hpp needs rewriting.

c) there seem to be other global array allocations still lurking

d) the effect of the hotspot global operator new on the other libraries 
needs to be better understood and dealt with. If I understand your fix 
as it stands you will abort in product mode, and warn in debug - yet we 
know this problem exists so this will simply force an abort. I would not 
expect to see the ShouldNotReachHere() variants.

This is without a doubt quite a mess, so I think we need to proceed very 
cautiously.

David

PS. I'm going to be on vacation from about 18 hours from now. Back next 
week - no email.


On 26/04/2013 4:48 PM, Yumin Qi wrote:
> HI, all
>
>    This bug is filed after this bug
>    8010992: Remove calls to global ::operator new[] and new
>    was anti-delta'ed due to testing failure on JVMTI. Now it takes both.
>
>    http://cr.openjdk.java.net/~minqi/8012902/webrev/
>
>    ObjectMonitor is an class which should not inherit from any class,
> but is has subclass in Jvmti, JvmtiRawMonitor. In previous changeset,
> ObjectMonitor is created through NEW_C_HEAP_OBJ/ARRAY macros, but
> JvmtiRawMonitor was missed. This is why when it is 'new'ed failed on
> disabled global operator new in debug mode. To prevent using more
> complex form of marco NEW_C_HEAP_OBJ/ARRAY operator new and new[] added
> to ObjectMonitor so JvmtiRawMonitor will inherit for them.
>
>    HandleMark should be a StackObj but we create the first one in Thread
> ctor in heap, so it did not have StackObj as parent. Added oerator new
> and new [] to it though in fact it is  used as StackObj. Same treatment
> for MemRegion too, it is an _ValueObj (in Linux, it did not inherit from
> any). Adding operator new and new[] is mainly avoid using macro
> involving alloc/dealloc and ctor/dtor complexity.
>
>    The make files, vm.make and fastdebug.make  changed under BSD is for
> one problem which is not clear: jdk code called operator new in hotspot
> library. This only happens on Darwin. Exposure of
> CATCH_OPERATOR_NEW_USAGE giving an warning when first time global
> operator new and new [] called.
>
>    Tested with JPRT, vm.quick, jtreg.
>
>    Thanks
>    Yumin


From mikael.gerdin at oracle.com  Mon Apr 29 14:17:47 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 29 Apr 2013 16:17:47 +0200
Subject: Request for review - 8013032 - CMS: assert(used() == used_after_gc
	&& used_after_gc <= capacity()) failed
In-Reply-To: <51796B42.4080405@oracle.com>
References: <51796B42.4080405@oracle.com>
Message-ID: <517E810B.8030403@oracle.com>

Jon,

On 2013-04-25 19:43, Jon Masamitsu wrote:
> CMS: assert(used() == used_after_gc && used_after_gc <= capacity())
> failed: used: 0 used_after_gc: 292080 capacity: 1431699456
>
> The assertion was incorrect so I deleted it.  The assumption that the
> metrics being tested should not be affected by the reset_after_compaction()
> was incorrect.
>
> http://cr.openjdk.java.net/~jmasa/8013032/webrev.00/

This looks good to me.

/Mikael


From jon.masamitsu at oracle.com  Mon Apr 29 14:56:19 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 29 Apr 2013 07:56:19 -0700
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <517E19CC.7040504@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com> <5179A46E.9070605@oracle.com>
	<517A3784.1060701@oracle.com> <517AB4C4.8060509@oracle.com>
	<517E19CC.7040504@oracle.com>
Message-ID: <517E8A13.8000707@oracle.com>


On 4/28/13 11:57 PM, Stefan Karlsson wrote:
> On 04/26/2013 07:09 PM, Jon Masamitsu wrote:
>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.frames.html 
>>
>>
>> I understand that the point of the change was that 
>> CodeCache::do_unloading()
>> cannot not add to the marking stack anymore but the
>> original code was less trusting in that it called for verification
>> when it really thought it was not needed.  For example,
>>
>>> 6047   verify_work_stacks_empty();
>>
>> Any second thoughts on removing the later calls to 
>> verify_work_stacks_empty()?
>> If you think it can never happen and it's not worth checking (and 
>> cluttering
>> the code) no problem.  Either way, looks good.
>
> I wanted to remove the later, unnecessary calls to 
> verify_work_stacks_empty(), to clearly mark the place above where we 
> stop populating the marking stacks.
>

Fair enough.

Jon

> thanks,
> StefanK
>
>>
>> Jon
>>
>>
>>
>> On 4/26/2013 1:15 AM, Stefan Karlsson wrote:
>>> On 04/25/2013 11:47 PM, Coleen Phillimore wrote:
>>>>
>>>> Hi, Sorry Stefan I think I liked your .00 version better. Now 
>>>> there's a level of indirection and it doesn't seem to save any code 
>>>> because the call sites are slightly different.
>>>
>>> It only saves code duplication in four of the collectors, the other 
>>> two still does the unloading differently.
>>>
>>> Could someone else review the .00 version?
>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>
>>> thanks,
>>> StefanK
>>>
>>>>
>>>> Coleen
>>>>
>>>> On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
>>>>> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>>>>>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>>>>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>>>>>
>>>>>>>> Stefan,
>>>>>>>>
>>>>>>>> Is there a common place for this code?
>>>>>>>
>>>>>>> I don't think there's any common place in the GCs for this. I'm 
>>>>>>> open for suggestions if you know a good place in the runtime code.
>>>>>>
>>>>>> memory/genCollectedHeap?   I have no idea...
>>>>>>>
>>>>>>>> It's 4 copies of the similar code, which takes me a while to 
>>>>>>>> find when I set out looking for it.
>>>>>>>
>>>>>>> Yes, I tried to make them look alike so that we/I have an 
>>>>>>> opportunity to extract it out to one function. The fact that CMS 
>>>>>>> does this differently made me hesitant to combine them.
>>>>>>>
>>>>>>>> In the future, I think StringTable::unlink() could be moved 
>>>>>>>> after CLDG::purge() which I thought should be around here too 
>>>>>>>> (but it's not).   The only reason StringTable::unlink() used to 
>>>>>>>> be here was because it used to have Oops in it.
>>>>>>>
>>>>>>> Don't you mean the SymbolTable? I'm OK with moving the 
>>>>>>> SymbolTable, but not the StringTable ...
>>>>>>
>>>>>> I did mean SymbolTable.
>>>>>>
>>>>>>>
>>>>>>>>    Can you unite this duplicated code?
>>>>>>>
>>>>>>> It's easy to unit the code for psMarkSweep, genMarkSweep, 
>>>>>>> g1MarkSweep and psParallelCompact but it's a bit more work to 
>>>>>>> also unify the CMS code. Would it be good enough for this patch 
>>>>>>> if I united the former GCs? And maybe handle CMS when G1 also 
>>>>>>> starts doing class unloading?
>>>>>>
>>>>>> Ok, keep it in mind for future work.  It would be nice to have 
>>>>>> the runtime GC things be called in one place or easy to find.
>>>>>>
>>>>>> I semi-reviewed the code and except for the GC part (which is 
>>>>>> most of the change).   We don't pass the keep_alive closure 
>>>>>> anymore for compiledICHolders so I guess this makes sense if this 
>>>>>> is what the keep_alive closure did. So this is a partial review.
>>>>>
>>>>> I've update the patch to gather the unloading code in a helper 
>>>>> class called GCUnloading. What do you think?
>>>>>
>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>>>>>
>>>>> thanks,
>>>>> StefanK
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>>
>>>>>>> thanks,
>>>>>>> StefanK
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>>>>>
>>>>>>>>> There's some remnants from the PermGen that's confusing in the 
>>>>>>>>> class unloading code. This patch removes the unnecessary code, 
>>>>>>>>> cleans up some comments and unifies the code structure over 
>>>>>>>>> different GCs.
>>>>>>>>>
>>>>>>>>> From the Bug report:
>>>>>>>>> ---
>>>>>>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>>>>>>> objects to C++ objects.
>>>>>>>>>
>>>>>>>>> CodeCache::do_unloading(...) used to take a keep_alive closure 
>>>>>>>>> that was applied to CompiledICHolders deep down in 
>>>>>>>>> nmethod::do_unloading. Since CompileICHolders don't move 
>>>>>>>>> anymore, and we have other ways to keep them alive, we don't 
>>>>>>>>> use the keep_alive closures in these functions anymore.
>>>>>>>>>
>>>>>>>>> Because of this, CodeCache::do_unloading will not populate the 
>>>>>>>>> marking stacks, and we can remove the call to drain the stacks 
>>>>>>>>> after the calls to CodeCache::do_unloading.
>>>>>>>>>
>>>>>>>>> This also has the neat effect that we now can verify that the 
>>>>>>>>> marking has really completed before we start unloading 
>>>>>>>>> classes, which makes the code easier to maintain/understand.
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> StefanK
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>



From mikael.gerdin at oracle.com  Mon Apr 29 15:05:32 2013
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 29 Apr 2013 17:05:32 +0200
Subject: Request for review - 8013184 CMS: Call reset_after_compaction()
	only if a compaction has been done
In-Reply-To: <517984DF.6020108@oracle.com>
References: <517984DF.6020108@oracle.com>
Message-ID: <517E8C3C.2030906@oracle.com>

Jon,

On 2013-04-25 21:32, Jon Masamitsu wrote:
> 8013184: CMS: Call reset_after_compaction() only if a compaction has
> been done
>
> When a System.gc() is done with -XX:-UseCMSCompactAtFullCollection, a
> mark-sweep
> without compaction is done.  In that instance the call to
> reset_after_compaction() is
> not appropriate.
>
> This changeset is built on top of the changeset for 8013032
>
> http://cr.openjdk.java.net/~jmasa/8013184/webrev.00/

Could you change the name of the test to say something about using the 
"foreground" GC?
Maybe "SystemGCOnForegroundCollector"?
I don't think the "three times" is relevant enough to be included in the 
test name.

*_did_compact is only relevant for Full GCs, what would you say about 
changing it to "full_gc_did_compact" to make it obvious that the 
variable is only relevant for Full GCs?

/Mikael


From jon.masamitsu at oracle.com  Mon Apr 29 16:03:15 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 29 Apr 2013 09:03:15 -0700
Subject: RFR (s): JDK-8013129 Possible deadlock with Metaspace locks due
	to mixed usage of safepoint aware and non-safepoint aware locking
In-Reply-To: <517E30BD.9030507@oracle.com>
References: <5178F2F8.7020900@oracle.com> <517E30BD.9030507@oracle.com>
Message-ID: <517E99C3.7050403@oracle.com>

Ship it.

On 4/29/13 1:35 AM, Mikael Gerdin wrote:
> Hi,
>
> If nobody objects I'd like to push this today, it's causing test 
> timeouts in our nightly testing and I'd like to get rid of them as 
> soon as possible.
>
> /Mikael
>
> On 2013-04-25 11:10, Mikael Gerdin wrote:
>> Hi,
>>
>> Problem:
>> We've seen some hangs in the GC nightly testing recently.
>> When I looked at the minidump files from some of those hangs they looked
>> like safepoint deadlocks where one thread was parked in
>> Mutex::lock_without_safepoint_check on one of the "Metaspace allocation
>> locks".
>>
>> Both of the hangs I investigated also had threads trying to lock the
>> same Metaspace lock but without eliding safepoint checks because they
>> were originating from Metaspace::deallocate.
>>
>> I believe that since the change to allocate MethodCounters on demand and
>> potentially deallocating them when racing this issue was brought to the
>> surface because of more frequent calls to Metaspace::deallocate when not
>> at a safepoint.
>>
>> I was able to reproduce the hang after about an hour by running an
>> instrumented build where MethodCounters are allocated and then
>> unconditionally deallocated on each entry to 
>> Method::build_method_counters.
>>
>> I can't describe the failure mode in detail since I'm not familiar with
>> the Mutex code but I can imagine that the locking state machine is
>> broken when we take completely different code paths for the same Mutex.
>>
>> Suggested fix:
>> My suggested fix is to change Metaspace::deallocate to take the lock
>> with Mutex::_no_safepoint_check_flag.
>>
>> With my fix I ran the test that managed to reproduce the failure
>> overnight without reproducing the hang.
>> I also ran the parallel class loading tests and nashorn's
>> test262parallel for good measure.
>>
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8013129/webrev.0/
>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8013129
>> bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013129
>>
>> /Mikael



From mikael.gerdin at oracle.com  Mon Apr 29 16:07:41 2013
From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com)
Date: Mon, 29 Apr 2013 16:07:41 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8013129: Possible deadlock with Metaspace
	locks due to mixed usage of safepoint aware and non-safepoint
	aware locking
Message-ID: <20130429160745.6C99748695@hg.openjdk.java.net>

Changeset: 601183f604b2
Author:    mgerdin
Date:      2013-04-29 13:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/601183f604b2

8013129: Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking
Summary: Change Metaspace::deallocate to take lock with _no_safepoint_check_flag
Reviewed-by: coleenp, jmasa, dholmes

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



From jon.masamitsu at oracle.com  Mon Apr 29 16:31:34 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 29 Apr 2013 09:31:34 -0700
Subject: Review request: 8013160: NPG: Remove unnecessary mark stack
	draining after CodeCache::do_unloading
In-Reply-To: <517E8A13.8000707@oracle.com>
References: <51783E0D.5080408@oracle.com> <5178414C.7090607@oracle.com>
	<5178455A.9000206@oracle.com> <517851C8.50802@oracle.com>
	<51791C94.7070604@oracle.com> <5179A46E.9070605@oracle.com>
	<517A3784.1060701@oracle.com> <517AB4C4.8060509@oracle.com>
	<517E19CC.7040504@oracle.com> <517E8A13.8000707@oracle.com>
Message-ID: <517EA066.5090807@oracle.com>


On 4/29/13 7:56 AM, Jon Masamitsu wrote:
>
> On 4/28/13 11:57 PM, Stefan Karlsson wrote:
>> On 04/26/2013 07:09 PM, Jon Masamitsu wrote:
>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.frames.html 
>>>
>>>
>>> I understand that the point of the change was that 
>>> CodeCache::do_unloading()
>>> cannot not add to the marking stack anymore but the
>>> original code was less trusting in that it called for verification
>>> when it really thought it was not needed.  For example,
>>>
>>>> 6047   verify_work_stacks_empty();
>>>
>>> Any second thoughts on removing the later calls to 
>>> verify_work_stacks_empty()?
>>> If you think it can never happen and it's not worth checking (and 
>>> cluttering
>>> the code) no problem.  Either way, looks good.
>>
>> I wanted to remove the later, unnecessary calls to 
>> verify_work_stacks_empty(), to clearly mark the place above where we 
>> stop populating the marking stacks.
>>
>
> Fair enough.

And the rest looks good.

Jon

>
> Jon
>
>> thanks,
>> StefanK
>>
>>>
>>> Jon
>>>
>>>
>>>
>>> On 4/26/2013 1:15 AM, Stefan Karlsson wrote:
>>>> On 04/25/2013 11:47 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Hi, Sorry Stefan I think I liked your .00 version better. Now 
>>>>> there's a level of indirection and it doesn't seem to save any 
>>>>> code because the call sites are slightly different.
>>>>
>>>> It only saves code duplication in four of the collectors, the other 
>>>> two still does the unloading differently.
>>>>
>>>> Could someone else review the .00 version?
>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>
>>>> thanks,
>>>> StefanK
>>>>
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 04/25/2013 08:07 AM, Stefan Karlsson wrote:
>>>>>> On 04/24/2013 11:42 PM, Coleen Phillimore wrote:
>>>>>>> On 4/24/2013 4:49 PM, Stefan Karlsson wrote:
>>>>>>>> On 4/24/13 10:32 PM, Coleen Phillimore wrote:
>>>>>>>>>
>>>>>>>>> Stefan,
>>>>>>>>>
>>>>>>>>> Is there a common place for this code?
>>>>>>>>
>>>>>>>> I don't think there's any common place in the GCs for this. I'm 
>>>>>>>> open for suggestions if you know a good place in the runtime code.
>>>>>>>
>>>>>>> memory/genCollectedHeap?   I have no idea...
>>>>>>>>
>>>>>>>>> It's 4 copies of the similar code, which takes me a while to 
>>>>>>>>> find when I set out looking for it.
>>>>>>>>
>>>>>>>> Yes, I tried to make them look alike so that we/I have an 
>>>>>>>> opportunity to extract it out to one function. The fact that 
>>>>>>>> CMS does this differently made me hesitant to combine them.
>>>>>>>>
>>>>>>>>> In the future, I think StringTable::unlink() could be moved 
>>>>>>>>> after CLDG::purge() which I thought should be around here too 
>>>>>>>>> (but it's not).   The only reason StringTable::unlink() used 
>>>>>>>>> to be here was because it used to have Oops in it.
>>>>>>>>
>>>>>>>> Don't you mean the SymbolTable? I'm OK with moving the 
>>>>>>>> SymbolTable, but not the StringTable ...
>>>>>>>
>>>>>>> I did mean SymbolTable.
>>>>>>>
>>>>>>>>
>>>>>>>>>    Can you unite this duplicated code?
>>>>>>>>
>>>>>>>> It's easy to unit the code for psMarkSweep, genMarkSweep, 
>>>>>>>> g1MarkSweep and psParallelCompact but it's a bit more work to 
>>>>>>>> also unify the CMS code. Would it be good enough for this patch 
>>>>>>>> if I united the former GCs? And maybe handle CMS when G1 also 
>>>>>>>> starts doing class unloading?
>>>>>>>
>>>>>>> Ok, keep it in mind for future work.  It would be nice to have 
>>>>>>> the runtime GC things be called in one place or easy to find.
>>>>>>>
>>>>>>> I semi-reviewed the code and except for the GC part (which is 
>>>>>>> most of the change).   We don't pass the keep_alive closure 
>>>>>>> anymore for compiledICHolders so I guess this makes sense if 
>>>>>>> this is what the keep_alive closure did. So this is a partial 
>>>>>>> review.
>>>>>>
>>>>>> I've update the patch to gather the unloading code in a helper 
>>>>>> class called GCUnloading. What do you think?
>>>>>>
>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.01/
>>>>>>
>>>>>> thanks,
>>>>>> StefanK
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> StefanK
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Coleen
>>>>>>>>>
>>>>>>>>> On 4/24/2013 4:18 PM, Stefan Karlsson wrote:
>>>>>>>>>> http://cr.openjdk.java.net/~stefank/8013160/webrev.00/
>>>>>>>>>>
>>>>>>>>>> There's some remnants from the PermGen that's confusing in 
>>>>>>>>>> the class unloading code. This patch removes the unnecessary 
>>>>>>>>>> code, cleans up some comments and unifies the code structure 
>>>>>>>>>> over different GCs.
>>>>>>>>>>
>>>>>>>>>> From the Bug report:
>>>>>>>>>> ---
>>>>>>>>>> The PermGen Removal changed CompiledICHolders from being Java 
>>>>>>>>>> objects to C++ objects.
>>>>>>>>>>
>>>>>>>>>> CodeCache::do_unloading(...) used to take a keep_alive 
>>>>>>>>>> closure that was applied to CompiledICHolders deep down in 
>>>>>>>>>> nmethod::do_unloading. Since CompileICHolders don't move 
>>>>>>>>>> anymore, and we have other ways to keep them alive, we don't 
>>>>>>>>>> use the keep_alive closures in these functions anymore.
>>>>>>>>>>
>>>>>>>>>> Because of this, CodeCache::do_unloading will not populate 
>>>>>>>>>> the marking stacks, and we can remove the call to drain the 
>>>>>>>>>> stacks after the calls to CodeCache::do_unloading.
>>>>>>>>>>
>>>>>>>>>> This also has the neat effect that we now can verify that the 
>>>>>>>>>> marking has really completed before we start unloading 
>>>>>>>>>> classes, which makes the code easier to maintain/understand.
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> StefanK
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From jon.masamitsu at oracle.com  Mon Apr 29 17:26:35 2013
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 29 Apr 2013 10:26:35 -0700
Subject: Request for review - 8013184 CMS: Call reset_after_compaction()
	only if a compaction has been done
In-Reply-To: <517E8C3C.2030906@oracle.com>
References: <517984DF.6020108@oracle.com> <517E8C3C.2030906@oracle.com>
Message-ID: <517EAD4B.7050201@oracle.com>


On 4/29/13 8:05 AM, Mikael Gerdin wrote:
> Jon,
>
> On 2013-04-25 21:32, Jon Masamitsu wrote:
>> 8013184: CMS: Call reset_after_compaction() only if a compaction has
>> been done
>>
>> When a System.gc() is done with -XX:-UseCMSCompactAtFullCollection, a
>> mark-sweep
>> without compaction is done.  In that instance the call to
>> reset_after_compaction() is
>> not appropriate.
>>
>> This changeset is built on top of the changeset for 8013032
>>
>> http://cr.openjdk.java.net/~jmasa/8013184/webrev.00/
>
> Could you change the name of the test to say something about using the 
> "foreground" GC?
> Maybe "SystemGCOnForegroundCollector"?
> I don't think the "three times" is relevant enough to be included in 
> the test name.

Yes to "SystemGCOnForegroundCollector"
>
> *_did_compact is only relevant for Full GCs, what would you say about 
> changing it to "full_gc_did_compact" to make it obvious that the 
> variable is only relevant for Full GCs?
Would you say that CMS does anything other than a full GC?   At least in
the general sense of "full GC".  I qualify that because CMS usually
only does a collection of the tenured generation but it's often
referred to as a "full GC".   If you also think of a CMS collection
as a full GC, then I think the "full_gc" in "full_gc_did_compaction"
is implied.  If you don't think that CMS usually does a full GC and
only the compacting GC is a full GC, then "_did_compact" implies
a full GC because that's the only time a compaction is done.

So I'm not keen on changing the name to "_full_gc_did_compact"
because it sounds redundant.  But l'll do it if you think it is
more clear.

Thanks.

Jon


>
> /Mikael



From john.cuthbertson at oracle.com  Mon Apr 29 20:07:24 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Mon, 29 Apr 2013 13:07:24 -0700
Subject: RFR(S/M) [Backports of] 8005032 and 8009536
Message-ID: <517ED2FC.2090309@oracle.com>

Hi Everyone,

Can I have a couple of volunteers review the back ports of the changes 
for these two CRs:

  8005032: G1: Cleanup serial reference processing closures in 
concurrent marking

and:

8009536: G1: Apache Lucene hang during reference processing

The exported changesets did not apply cleanly because of some event 
based tracing changes, namely CMTask::worker_id() being changed to 
CMTask::task_id() and 
ReferenceProcessor::process_discovered_references() returning a value. 
Back porting the changes for 8005032 reduce the number of conflicts when 
importing the changes for 8009536.

Since the cleanup changes expose the problem fixed by 8009536, I'd like 
to push both changesets together.

_8005032: G1: Cleanup serial reference processing closures in concurrent 
marking_
The webrev for the back port of 8005032 can be found at: 
http://cr.openjdk.java.net/~johnc/8005032-hsx24-backport/webrev.0/. The 
original hs25 changes can be found at: 
http://cr.openjdk.java.net/~johnc/8005032/webrev.1/.

Testing: GC test suite (also with ParallelGCThreads=0) and event based 
tracing regression tests.

_8009536: G1: Apache Lucene hang during reference processing_
The webrev for just the hsx24 back port changes (applied on top of 
8005032) can be found at: 
http://cr.openjdk.java.net/~johnc/8009536-hsx24-backport/webrev.1.8009536-hsx-backport/. 
The combined webrev can be found at: 
http://cr.openjdk.java.net/~johnc/8009536-hsx24-backport/webrev.all/

The original changes for hsx25 can be found at: 
http://cr.openjdk.java.net/~johnc/8009536/webrev.2/.

Testing: GC test suite, the Apache Lucene uima tests with 
MarkStackSize=32K entries.

Thanks,

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

From jesper.wilhelmsson at oracle.com  Mon Apr 29 23:20:44 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 30 Apr 2013 01:20:44 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1366977932.2808.73.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus>
	<1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com>
	<1364203467.2703.41.camel@cirrus> <51509569.1020604@oracle.com>
	<1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus>
Message-ID: <517F004C.7060409@oracle.com>

Looks good,
Ship it!
/Jesper

Thomas Schatzl skrev 26/4/13 2:05 PM:
> Hi all,
>
> On Thu, 2013-04-18 at 10:57 -0700, John Cuthbertson wrote:
>> Hi Thomas,
>>
>> [...]
>>
>> Ship it.
>>
>> JohnC
>
>    I still need another reviewer to actually ship this :)
>
> It would also help to have this cleanup for CR-7057939 and CR-8012591.
>
> Thanks,
>    Thomas
>
> On Thu, 2013-04-18 at 10:57 -0700, John Cuthbertson wrote:
>> Hi Thomas,
>>
>> Thanks for the resonse. Inline...
>>
>> On 4/17/2013 12:23 AM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>>     I had the same concerns about inconsistencies with -Xms and
>>> -XX:InitialHeapSize, but -Xms is (apparently) defined to set both
>>> minimum and initial heap size.
>>> I already raised that issue in an earlier discussion.
>>
>> OK. I don't have a problem with it. It just looked 'odd'.
>>>
>>> If you have an official source that states that -Xms only sets minimum
>>> or initial heap size, I will gladly change this. I could not find
>>> anything; actually the documentation (java -X) for -Xms states only that it sets the initial heap size.
>>>
>>> The observations below result from this definition.
>>>
>>> On Mon, 2013-04-15 at 16:29 -0700, John Cuthbertson wrote:
>>>> Hi Thomas,
>>>>
>>>> Why do we treat:
>>>>
>>>> java -Xms8M  -XX:InitialHeapSize=4M...
>>>>
>>>> as an error while accepting:
>>> Because -Xms sets minimum heap size to 8M, and if you then set initial
>>> heap size to 4M there is a conflict in the general condition that
>>> minimum <= initial <= max.
>>>
>>>> java -XX:InitialHeapSize=4M -Xms8M...
>>>>
>>>> It looks inconsistent. In both cases the user has asked for an initial
>>>> heap size less than his requested minimum.
>>> As mentioned, -Xms unfortunately seems to be defined to set both initial
>>> and minimum heap size. So there is no conflict.
>>
>> You're correct. I've looked at the contents of the Xusage.txt file for a
>> couple of really ancient jdks and it says that it sets the initial size.
>>
>>
>>>> In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be
>>>> coalesced into a single line for each? This would make the setting of
>>>> Initial and Min consistent with the code that sets Max on line 87.
>>>>
>>> Done.
>>>
>>> See http://cr.openjdk.java.net/~tschatzl/8006088/webrev.7/ for the new
>>> webrev.
>>>
>>> In addition to this change I fixed the headers of the jprt test cases to
>>> avoid some issues with jtreg. Namely precompile the used classes and
>>> install the whitebox api class into the boot class path.
>>
>> Thanks. collectorPolicy.cpp looks much cleaner.
>>
>> Ship it.
>>
>> JohnC
>
>


From tao.mao at oracle.com  Mon Apr 29 23:40:14 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Mon, 29 Apr 2013 16:40:14 -0700
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <517F004C.7060409@oracle.com>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus>
	<1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com>
	<1364203467.2703.41.camel@cirrus> <51509569.1020604@oracle.com>
	<1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus> <517F004C.7060409@oracle.com>
Message-ID: <517F04DE.4010607@oracle.com>

Wait...have we agreed that we should name gc jtreg tests more 
intuitively rather than putting Bug ID?
https://wikis.oracle.com/display/HotSpotInternals/Naming+HotSpot+JTReg+Tests

Thanks.
Tao

On 4/29/13 4:20 PM, Jesper Wilhelmsson wrote:
> Looks good,
> Ship it!
> /Jesper
>
> Thomas Schatzl skrev 26/4/13 2:05 PM:
>> Hi all,
>>
>> On Thu, 2013-04-18 at 10:57 -0700, John Cuthbertson wrote:
>>> Hi Thomas,
>>>
>>> [...]
>>>
>>> Ship it.
>>>
>>> JohnC
>>
>>    I still need another reviewer to actually ship this :)
>>
>> It would also help to have this cleanup for CR-7057939 and CR-8012591.
>>
>> Thanks,
>>    Thomas
>>
>> On Thu, 2013-04-18 at 10:57 -0700, John Cuthbertson wrote:
>>> Hi Thomas,
>>>
>>> Thanks for the resonse. Inline...
>>>
>>> On 4/17/2013 12:23 AM, Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>>     I had the same concerns about inconsistencies with -Xms and
>>>> -XX:InitialHeapSize, but -Xms is (apparently) defined to set both
>>>> minimum and initial heap size.
>>>> I already raised that issue in an earlier discussion.
>>>
>>> OK. I don't have a problem with it. It just looked 'odd'.
>>>>
>>>> If you have an official source that states that -Xms only sets minimum
>>>> or initial heap size, I will gladly change this. I could not find
>>>> anything; actually the documentation (java -X) for -Xms states only 
>>>> that it sets the initial heap size.
>>>>
>>>> The observations below result from this definition.
>>>>
>>>> On Mon, 2013-04-15 at 16:29 -0700, John Cuthbertson wrote:
>>>>> Hi Thomas,
>>>>>
>>>>> Why do we treat:
>>>>>
>>>>> java -Xms8M  -XX:InitialHeapSize=4M...
>>>>>
>>>>> as an error while accepting:
>>>> Because -Xms sets minimum heap size to 8M, and if you then set initial
>>>> heap size to 4M there is a conflict in the general condition that
>>>> minimum <= initial <= max.
>>>>
>>>>> java -XX:InitialHeapSize=4M -Xms8M...
>>>>>
>>>>> It looks inconsistent. In both cases the user has asked for an 
>>>>> initial
>>>>> heap size less than his requested minimum.
>>>> As mentioned, -Xms unfortunately seems to be defined to set both 
>>>> initial
>>>> and minimum heap size. So there is no conflict.
>>>
>>> You're correct. I've looked at the contents of the Xusage.txt file 
>>> for a
>>> couple of really ancient jdks and it says that it sets the initial 
>>> size.
>>>
>>>
>>>>> In collectorPolicy.cpp, can the code on lines 79-80 and 83-84 be
>>>>> coalesced into a single line for each? This would make the setting of
>>>>> Initial and Min consistent with the code that sets Max on line 87.
>>>>>
>>>> Done.
>>>>
>>>> See http://cr.openjdk.java.net/~tschatzl/8006088/webrev.7/ for the new
>>>> webrev.
>>>>
>>>> In addition to this change I fixed the headers of the jprt test 
>>>> cases to
>>>> avoid some issues with jtreg. Namely precompile the used classes and
>>>> install the whitebox api class into the boot class path.
>>>
>>> Thanks. collectorPolicy.cpp looks much cleaner.
>>>
>>> Ship it.
>>>
>>> JohnC
>>
>>


From kirk at kodewerk.com  Tue Apr 30 04:32:04 2013
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Tue, 30 Apr 2013 06:32:04 +0200
Subject: Request for review - 8013184 CMS: Call reset_after_compaction()
	only if a compaction has been done
In-Reply-To: <517EAD4B.7050201@oracle.com>
References: <517984DF.6020108@oracle.com> <517E8C3C.2030906@oracle.com>
	<517EAD4B.7050201@oracle.com>
Message-ID: <837EA457-742E-47D0-8735-65CAB9E93F75@kodewerk.com>

Hi Jon,

I think you're right in the common misconception is that CMS does a full GC. However I like to make the distinction in that Full GC's work in all memory pools where as partial collections don't. Thus CMS is not a Full GC. I've been working hard in the field to make this distinction and it would be nice if the code read this way also.

Regards,
Kirk

> Would you say that CMS does anything other than a full GC?   At least in
> the general sense of "full GC".  I qualify that because CMS usually
> only does a collection of the tenured generation but it's often
> referred to as a "full GC".   If you also think of a CMS collection
> as a full GC, then I think the "full_gc" in "full_gc_did_compaction"
> is implied.  If you don't think that CMS usually does a full GC and
> only the compacting GC is a full GC, then "_did_compact" implies
> a full GC because that's the only time a compaction is done.
> 
> So I'm not keen on changing the name to "_full_gc_did_compact"
> because it sounds redundant.  But l'll do it if you think it is
> more clear.
> 
> Thanks.
> 
> Jon
> 
> 
>> 
>> /Mikael
> 



From thomas.schatzl at oracle.com  Tue Apr 30 08:33:22 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 10:33:22 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <517F04DE.4010607@oracle.com>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus> <517F004C.7060409@oracle.com>
	<517F04DE.4010607@oracle.com>
Message-ID: <1367310802.2722.52.camel@cirrus>

Hi,

On Mon, 2013-04-29 at 16:40 -0700, Tao Mao wrote:
> Wait...have we agreed that we should name gc jtreg tests more 
> intuitively rather than putting Bug ID?
> https://wikis.oracle.com/display/HotSpotInternals/Naming+HotSpot+JTReg+Tests

The work on this CR predates this process change by far.

However I will move the tests into another directory, do another test
run, and send another request for review in the hope that this final
final version will be reviewed before another change :)

Hth,
Thomas




From vladimir.kempik at oracle.com  Tue Apr 30 10:33:56 2013
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Tue, 30 Apr 2013 14:33:56 +0400
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <517825D4.4020505@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com> <51757C74.9000605@oracle.com>
	<5177B599.3050604@oracle.com> <517825D4.4020505@oracle.com>
Message-ID: <517F9E14.8050707@oracle.com>

Hello.

I have a customer with non-escalated bug that is duplicate of this bug. 
I checked with patch from webrev.03 and can confirm that fixed the bug.

Could you guys approve it if it's fine?

Thanks. Vladimir.
On 24.04.2013 22:35, Tao Mao wrote:
> For 32-bit builds: The current changeset provides the first 
> "protection" of heap size handling. Then comes handling whether we can 
> allocate a certain amount of a heap.
>
> For 64-bit builds: a machine with 512M-1GB memory should fail in many 
> other tests as well, due to inability to lauch jvm.
>
> Anyway, I ran the test and it passed.
>
> --------------------------------------------------
> Simply,
>
> -bash-4.1$ ulimit -v 134217728 (128m for human reading)
> -bash-4.1$ ulimit -m 134217728 (128m FHR)
>
> (cannot limit virtual memory to zero or set vm.swappiness=0, in which 
> case the server would hang immediately w/o even launching jvm. But, 
> the setting should satisfy your question.)
>
> Then, run jtreg. Then, pass.
> --------------------------------------------------
>
> BTW, since you've jumped in this thread ^_^ can you check the way I 
> get system property through "test.java.opts" to set inside jvm 
> process? It's in 
> test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>
> Thank you.
> Tao
>
> On 4/24/13 3:36 AM, Leonid Mesnik wrote:
>> On 04/22/2013 10:07 PM, Tao Mao wrote:
>>> This should be handled by a separate CR (probably by this CR 
>>> https://jbs.oracle.com/bugs/browse/JDK-7112912)
>>>
>> Why this? I mean should your test pass on hosts with *small* amount 
>> of memory.
>>
>> Leonid
>>> Thanks.
>>> Tao
>>>
>>> On 4/22/13 2:46 AM, Leonid Mesnik wrote:
>>>> Tao
>>>>
>>>> This is not review, just question.
>>>>
>>>> Should you test pass on hosts with 512M-1GB memory and no swap?
>>>>
>>>> Leonid
>>>> On 04/19/2013 09:27 PM, Tao Mao wrote:
>>>>> 1. check overflow routine is wrapped up.
>>>>>
>>>>> 2. The reduction of code duplication is adopted.
>>>>>
>>>>> 3. Develop a way to intake 0~multiple external vm options in jtreg 
>>>>> main(). Hope it helps others implement similar functionality.
>>>>>
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>>>>
>>>>> test:
>>>>> JTREG: passed.
>>>>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>>>>> <GC_OPTION>" 
>>>>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>>>
>>>>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>>>>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>>
>>>>>
>>>>> Thanks.
>>>>> Tao
>>>>>
>>>>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>>>>
>>>>>> Hi Tao,
>>>>>>
>>>>>> I agree with John. The changes look fine and I'm ok with them. 
>>>>>> But it would look nicer to add the 
>>>>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>>>>
>>>>>> Also, regarding the test, a couple of minor things.
>>>>>>
>>>>>> First, with the new naming convention I think the test should be 
>>>>>> called something like:
>>>>>>
>>>>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>
>>>>>> Then I think you can reduce the code duplication a bit. You 
>>>>>> create the same ProcessBuilder and OutputAnalyzer in both 32 and 
>>>>>> 64 bit cases. So maybe it could look like this instead:
>>>>>>
>>>>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>>>>   public static void main(String args[]) throws Exception {
>>>>>>     ProcessBuilder pb =
>>>>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>>>> "-Xmx3072m",
>>>>>> "-XX:MaxPermSize=1024m",
>>>>>> "-version");
>>>>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>>>
>>>>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>>>>     if (dataModel.equals("32")) {
>>>>>>       output.shouldContain("The size of the object heap + perm 
>>>>>> gen exceeds the maximum representable size");
>>>>>>       if (output.getExitValue() == 0) {
>>>>>>         throw new RuntimeException("Not expected to get exit 
>>>>>> value 0");
>>>>>>       }
>>>>>>     } else if (dataModel.equals("64")) {
>>>>>>       output.shouldHaveExitValue(0);
>>>>>>     }
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> There is also a small bug in the test. If you run JTreg without 
>>>>>> passing any vmoptions the test will fail. The reason is that 
>>>>>> System.getProperty("test.vm.opts") will evaluate to the empty 
>>>>>> string. This will be passed as the first argument to the Java 
>>>>>> process, which will assume that this is the class name. So, it 
>>>>>> fails to start because it can't load the class <empty string>.
>>>>>>
>>>>>> To reproduce the problem use this command line:
>>>>>>
>>>>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>>>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>
>>>>>> I guess the fix is to check that 
>>>>>> System.getProperty("test.vm.opts") is not empty before passing it 
>>>>>> on to createJavaProcessBuilder().
>>>>>>
>>>>>> Thanks,
>>>>>> Bengt
>>>>>>
>>>>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>>>>> Hi Tao,
>>>>>>>
>>>>>>> This looks OK to me.
>>>>>>>
>>>>>>> I can see what Thomas is saying though. All of the checks 
>>>>>>> involve something like:
>>>>>>>
>>>>>>> total += some_value;
>>>>>>> if (total < some_value) {
>>>>>>>   // We must have overflowed
>>>>>>>   vm_exit(...);
>>>>>>> }
>>>>>>>
>>>>>>> So a function in CollectedHeap (the base class of SharedHeap and 
>>>>>>> ParallelScavengeHeap) might make sense. For example:
>>>>>>>
>>>>>>> total_reserved = 0;
>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>>> max_heap_size);
>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>>> max_perm_size);
>>>>>>>
>>>>>>> Where the function is:
>>>>>>>
>>>>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>>>>   const char* msg = "...";
>>>>>>>   x += y;
>>>>>>>   if (x < y) {
>>>>>>>     vm_exit(msg);
>>>>>>>   }
>>>>>>>   return x;
>>>>>>> }
>>>>>>>
>>>>>>> But I can live with your current changes.
>>>>>>>
>>>>>>> JohnC
>>>>>>>
>>>>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>>>>> Hi Bengt,
>>>>>>>>
>>>>>>>> Thank you for reviewing. A new webrev is updated.
>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Tao
>>>>>>>>
>>>>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>>>>
>>>>>>>>> Hi Tao,
>>>>>>>>>
>>>>>>>>> This change looks good. Thanks for adding the JTReg test, it 
>>>>>>>>> looks good!
>>>>>>>>>
>>>>>>>>> One minor nit:
>>>>>>>>>
>>>>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I 
>>>>>>>>> would suggest to store "(size_t) 
>>>>>>>>> align_size_up(pgs->max_size(), HeapRegion::GrainBytes)" in a 
>>>>>>>>> local variable rather than duplicating the calculation.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Bengt
>>>>>>>>>
>>>>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>>>>
>>>>>>>>>> webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>>>>
>>>>>>>>>> changeset:
>>>>>>>>>> The fix only needs to go to hsx24 since there's no perm gen 
>>>>>>>>>> in hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>>>>
>>>>>>>>>> It provides for 32-bit builds a preventive check of the size 
>>>>>>>>>> of "the object heap + perm gen" before reserving VM memory. 
>>>>>>>>>> The total size should not exceed 4096MB (i.e. 4GB) for 32-bit 
>>>>>>>>>> builds; otherwise, the total doesn't make sense and, what's 
>>>>>>>>>> worse, overflow occurs. It will consequentially trigger 
>>>>>>>>>> anther error of memory access violation, which was not protected.
>>>>>>>>>>
>>>>>>>>>> jtreg testing java code is also written, checking both 32-bit 
>>>>>>>>>> and (trivially) 64-bit builds.
>>>>>>>>>>
>>>>>>>>>> testing:
>>>>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, 
>>>>>>>>>> -XX:+UseG1GC, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, 
>>>>>>>>>> -XX:+UseSerialGC and builds of 32-bit and 64-bit. All passed.
>>>>>>>>>>
>>>>>>>>>> Needs JPRT test when pushing.
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>> -- 
>>>> Leonid Mesnik
>>>> JVM SQE
>>
>>
>> -- 
>> Leonid Mesnik
>> JVM SQE

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

From thomas.schatzl at oracle.com  Tue Apr 30 10:51:19 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 12:51:19 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1367310802.2722.52.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus> <517F004C.7060409@oracle.com>
	<517F04DE.4010607@oracle.com> <1367310802.2722.52.camel@cirrus>
Message-ID: <1367319079.2722.71.camel@cirrus>

Hi all,

  please review the latest changes for this CR, taking jtreg naming
conventions into account.

Differences:
 - moved tests into different directory to conform to the new jtreg
naming conventions
 - updated to latest hotspot-gc (applied cleanly, no changes)

@Tao: I added you to the reviewed-by set for this change. I hope this is
okay with you as you apparently reviewed the previous version already.

Ergonomics behavior reference:
http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/XmsInitialHeapSizeErgo.html

Bugs.sun.com:
http://bugs.sun.com/view_bug.do?bug_id=8006088

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-8006088

Webrev:
http://cr.openjdk.java.net/~tschatzl/8006088/webrev.8/

Testing:
JPRT, manual testing

Thanks,
Thomas




From leonid.mesnik at oracle.com  Tue Apr 30 11:57:00 2013
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 30 Apr 2013 15:57:00 +0400
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1367319079.2722.71.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus>
	<1363954351.2689.50.camel@cirrus> <514CD9F6.3070902@oracle.com>
	<1364203467.2703.41.camel@cirrus> <51509569.1020604@oracle.com>
	<1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus> <517F004C.7060409@oracle.com>
	<517F04DE.4010607@oracle.com> <1367310802.2722.52.camel@cirrus>
	<1367319079.2722.71.camel@cirrus>
Message-ID: <517FB18C.3060308@oracle.com>

There are a couple of comments to your test:
1)You added "test.java.opts" to tested process. Could external options 
break tests?
It think it is needed to ignore any heap and GC sensitive options which 
could affect your tests.


2) Does it make a sense to create separate method which create java with 
enables WhiteBox?
This method could be used in a lot of tests.

Leonid

On 04/30/2013 02:51 PM, Thomas Schatzl wrote:
> Hi all,
>
>    please review the latest changes for this CR, taking jtreg naming
> conventions into account.
>
> Differences:
>   - moved tests into different directory to conform to the new jtreg
> naming conventions
>   - updated to latest hotspot-gc (applied cleanly, no changes)
>
> @Tao: I added you to the reviewed-by set for this change. I hope this is
> okay with you as you apparently reviewed the previous version already.
>
> Ergonomics behavior reference:
> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/XmsInitialHeapSizeErgo.html
>
> Bugs.sun.com:
> http://bugs.sun.com/view_bug.do?bug_id=8006088
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8006088
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8006088/webrev.8/
>
> Testing:
> JPRT, manual testing
>
> Thanks,
> Thomas
>
>


-- 
Leonid Mesnik
JVM SQE



From thomas.schatzl at oracle.com  Tue Apr 30 12:46:56 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 14:46:56 +0200
Subject: Request for review - 8013184 CMS: Call reset_after_compaction()
	only if a compaction has been done
In-Reply-To: <517984DF.6020108@oracle.com>
References: <517984DF.6020108@oracle.com>
Message-ID: <1367326016.2722.82.camel@cirrus>

Hi,

On Thu, 2013-04-25 at 12:32 -0700, Jon Masamitsu wrote:
> 8013184: CMS: Call reset_after_compaction() only if a compaction has been done
> 
> When a System.gc() is done with -XX:-UseCMSCompactAtFullCollection, a 
> mark-sweep
> without compaction is done.  In that instance the call to 
> reset_after_compaction() is
> not appropriate.
> 
> This changeset is built on top of the changeset for 8013032
> 
> http://cr.openjdk.java.net/~jmasa/8013184/webrev.00/


Minor: in the test, instead of hardcoding the class name to call, maybe
you could use something like ThreePlusMSSystemGC.class.getName()
instead.

Hth,
Thomas




From thomas.schatzl at oracle.com  Tue Apr 30 13:00:12 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 15:00:12 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <517FB18C.3060308@oracle.com>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus> <517F004C.7060409@oracle.com>
	<517F04DE.4010607@oracle.com> <1367310802.2722.52.camel@cirrus>
	<1367319079.2722.71.camel@cirrus> <517FB18C.3060308@oracle.com>
Message-ID: <1367326812.2722.85.camel@cirrus>

Hi Leonid,

  thanks for taking the time to review.

On Tue, 2013-04-30 at 15:57 +0400, Leonid Mesnik wrote:
> There are a couple of comments to your test:
> 1)You added "test.java.opts" to tested process. Could external options 
> break tests?
> It think it is needed to ignore any heap and GC sensitive options which 
> could affect your tests.

You mean when invoking the process that calls the whitebox api function
in TestMaxHeapSizeTools.getMinInitialMaxHeap()?

Admittedly this particular code was mostly copy and pasted from other
examples without actually knowing what it does at that time.

In this case, if test.java.opts contains the original test invocation
options, I think it is okay to actually ignore them here. I will remove
that.

> 2) Does it make a sense to create separate method which create java with 
> enables WhiteBox?
>This method could be used in a lot of tests.

I agree. I extracted the invocation into a separate method for now. Can
I move that refactoring to a separate CR? Next to this functionality,
there are other methods that may be reused in other test cases.
Particularly about argument parsing.

I will provide a new webrev shortly.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Tue Apr 30 14:57:20 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 16:57:20 +0200
Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in
	ReferenceHandler thread
Message-ID: <1367333840.2722.118.camel@cirrus>

Hi all,

  the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/
presents a first stab at the CR "7038914: VM could throw uncaught OOME
in ReferenceHandler thread".

The problem is that under very heavy memory pressure, there is the
reference handler throws an exception with the message "Exception:
java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in
thread "Reference Handler".

The change improves handling of out-of-memory conditions in the
ReferenceHandler thread. Instead of crashing the thread, and then
disabling reference processing, it catches this exception and continues.

I'd like to discuss the change as I'm not really familiar with JDK
coding style, handling of such situations and have some questions about
it.

Bugs.sun
http://bugs.sun.com/view_bug.do?bug_id=7038914

JBS:
https://jbs.oracle.com/bugs/browse/JDK-7038914

Proposed webrev:
http://cr.openjdk.java.net/~tschatzl/7038914/webrev/

- first, I could not reliably reproduce the issue using the information
in the CR. Only via code review (and an idea from Bengt Rutisson -
thanks!) I implemented a nice way to reproduce an OOME in the reference
handler. This involves implementing a custom
java.lang.ref.ReferenceQueue and overriding the enqueue() method, and
doing some allocation that causes an OOME within that method.
My current theory is that synchronization/locking allocates some objects
on the java heap, which are very small, so an OOME in that thread can be
caused. I walked the locking code, but could not find a java heap
allocation there (ObjectMonitor seems to be a C heap object) - maybe I
overlooked it. Probably somebody else knows?
It cannot be the invocation of the Cleaner.clean() methods above the
enqueuing since it has it's own try-catch block already.
Anyway, since the reproducer I wrote shows the same symptoms as reported
in the CR, I hope that this test case is sufficient to be regarded as a
reproducer and the change as a fix.

- the actual change in java/lang/ref/Reference as mentioned involves
putting the entire main enqueuing procedure within a try-catch block.
It only catches OOME to decrease the possibility to catch anything that
should not be caught.
The problem is that this fix does not (and cannot) really fix bad
programming in anyone overriding java.lang.ref.ReferenceQueue.enqueue(),
i.e. if the OOME condition is before the actual execution of the
original enqueue() method, i.e. corruption of the queue may be still
possible.
On the other hand, since overriding ReferenceQueue.enqueue() requires
putting the custom ReferenceQueue into the boot class path, I assume
that people doing that are aware of possible issues.

- handling the OOME: in the catch block of the I put a block

                    // avoid crashing the reference handler thread,
                    // but provide for some diagnosability
                    assert false : e.toString();

to provide some diagnosability in the case of an exception (when
running with assertions). I copied that from other code that tries to
catch similar problems in the clean() method of the Cleaners. There are
other variants of managing this in the jdk, some involving calling
system.exit(). I thought that was too drastic, so I didn't do that, but
what is the appropriate way to handle this situation?

- if the use of locks or the synchronization keyword is indeed the
problem, I think it is possible to use nonblocking synchronization that
is known to not allocate any memory for managing the reference queues
instead. However I think to guard against misbehaving ReferenceQueue
implementations you'd still want to have a try-catch block here.

- is the location of the test correct? I.e. in the jdk
test/java/lang/ref directory? Or is the correct place for that the
hotspot test directories?

Since this is (seems to be) a JDK only change, and this is my first time
changing the JDK, I hope core-libs-dev is the right mailing list.
Otherwise please direct me to the the appropriate one.

Thanks,
Thomas



From thomas.schatzl at oracle.com  Tue Apr 30 15:18:17 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 30 Apr 2013 17:18:17 +0200
Subject: RFR (S): 8006088: Incompatible heap size flags accepted by VM
In-Reply-To: <1367326812.2722.85.camel@cirrus>
References: <1363249737.2580.6.camel@cirrus> <5141A3C1.9060500@oracle.com>
	<1363611183.2603.45.camel@cirrus> <1363954351.2689.50.camel@cirrus>
	<514CD9F6.3070902@oracle.com> <1364203467.2703.41.camel@cirrus>
	<51509569.1020604@oracle.com> <1364306183.2847.52.camel@cirrus>
	<1365687182.2594.19.camel@cirrus> <516C8D42.1030207@oracle.com>
	<1366183427.4102.2.camel@cirrus> <5170340B.6020704@oracle.com>
	<1366977932.2808.73.camel@cirrus> <517F004C.7060409@oracle.com>
	<517F04DE.4010607@oracle.com> <1367310802.2722.52.camel@cirrus>
	<1367319079.2722.71.camel@cirrus> <517FB18C.3060308@oracle.com>
	<1367326812.2722.85.camel@cirrus>
Message-ID: <1367335097.2722.127.camel@cirrus>

Hi all,

  please review the latest changes for this CR, taking Leonid's comments
into account.

Differences:
 - changed names of the test cases, since because by moving it from a CR
specific directory into a more generic one, the test names were too
generic.
 - removed the use of test.java.opts for calling the VM that executes
some whitebox method as it may interfere with execution
 - factored out method to execute a VM running a custom class with the
whitebox api enabled. More refactoring later in 8012591.
 - no functional changes

Ergonomics behavior reference:
http://cr.openjdk.java.net/~tschatzl/8006088/webrev.6/XmsInitialHeapSizeErgo.html

Bugs.sun.com:
http://bugs.sun.com/view_bug.do?bug_id=8006088

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-8006088

Webrev:
http://cr.openjdk.java.net/~tschatzl/8006088/webrev.9/

Testing:
JPRT, manual testing

Thanks,
  Thomas




From Alan.Bateman at oracle.com  Tue Apr 30 15:44:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Apr 2013 16:44:42 +0100
Subject: (Preliminary) RFC 7038914: VM could throw uncaught OOME in
	ReferenceHandler thread
In-Reply-To: <1367333840.2722.118.camel@cirrus>
References: <1367333840.2722.118.camel@cirrus>
Message-ID: <517FE6EA.6070907@oracle.com>

On 30/04/2013 15:57, Thomas Schatzl wrote:
> Hi all,
>
>    the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/
> presents a first stab at the CR "7038914: VM could throw uncaught OOME
> in ReferenceHandler thread".
>
> The problem is that under very heavy memory pressure, there is the
> reference handler throws an exception with the message "Exception:
> java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in
> thread "Reference Handler".
>
> The change improves handling of out-of-memory conditions in the
> ReferenceHandler thread. Instead of crashing the thread, and then
> disabling reference processing, it catches this exception and continues.
It's surprising to heard that the Reference Handler thread failed with 
OOME. I wouldn't expect anything in this code path to throw OOME, except 
maybe in fast-path for sun.misc.Cleaner but that will abort the VM be it 
fails. The enqueue method that you override in the test to provoke this 
is package-private so it's unlikely that the test or whatever that 
resulted in this bug report is doing that.

So I'm again this proposed change, rather I'm just trying to understand 
how it happened. Is there instrumentation involved by any chance? It the 
OOME something other than "java heap" or do we know?

-Alan.


From tao.mao at oracle.com  Tue Apr 30 18:11:43 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 30 Apr 2013 11:11:43 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <517F9E14.8050707@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com> <51757C74.9000605@oracle.com>
	<5177B599.3050604@oracle.com> <517825D4.4020505@oracle.com>
	<517F9E14.8050707@oracle.com>
Message-ID: <5180095F.0@oracle.com>

Hi Vladimir,

Can you point me to your bug you think it's associated with?

Thanks.
Tao

On 4/30/13 3:33 AM, Vladimir Kempik wrote:
> Hello.
>
> I have a customer with non-escalated bug that is duplicate of this 
> bug. I checked with patch from webrev.03 and can confirm that fixed 
> the bug.
>
> Could you guys approve it if it's fine?
>
> Thanks. Vladimir.
> On 24.04.2013 22:35, Tao Mao wrote:
>> For 32-bit builds: The current changeset provides the first 
>> "protection" of heap size handling. Then comes handling whether we 
>> can allocate a certain amount of a heap.
>>
>> For 64-bit builds: a machine with 512M-1GB memory should fail in many 
>> other tests as well, due to inability to lauch jvm.
>>
>> Anyway, I ran the test and it passed.
>>
>> --------------------------------------------------
>> Simply,
>>
>> -bash-4.1$ ulimit -v 134217728 (128m for human reading)
>> -bash-4.1$ ulimit -m 134217728 (128m FHR)
>>
>> (cannot limit virtual memory to zero or set vm.swappiness=0, in which 
>> case the server would hang immediately w/o even launching jvm. But, 
>> the setting should satisfy your question.)
>>
>> Then, run jtreg. Then, pass.
>> --------------------------------------------------
>>
>> BTW, since you've jumped in this thread ^_^ can you check the way I 
>> get system property through "test.java.opts" to set inside jvm 
>> process? It's in 
>> test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>
>> Thank you.
>> Tao
>>
>> On 4/24/13 3:36 AM, Leonid Mesnik wrote:
>>> On 04/22/2013 10:07 PM, Tao Mao wrote:
>>>> This should be handled by a separate CR (probably by this CR 
>>>> https://jbs.oracle.com/bugs/browse/JDK-7112912)
>>>>
>>> Why this? I mean should your test pass on hosts with *small* amount 
>>> of memory.
>>>
>>> Leonid
>>>> Thanks.
>>>> Tao
>>>>
>>>> On 4/22/13 2:46 AM, Leonid Mesnik wrote:
>>>>> Tao
>>>>>
>>>>> This is not review, just question.
>>>>>
>>>>> Should you test pass on hosts with 512M-1GB memory and no swap?
>>>>>
>>>>> Leonid
>>>>> On 04/19/2013 09:27 PM, Tao Mao wrote:
>>>>>> 1. check overflow routine is wrapped up.
>>>>>>
>>>>>> 2. The reduction of code duplication is adopted.
>>>>>>
>>>>>> 3. Develop a way to intake 0~multiple external vm options in 
>>>>>> jtreg main(). Hope it helps others implement similar functionality.
>>>>>>
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>>>>>
>>>>>> test:
>>>>>> JTREG: passed.
>>>>>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>>>>>> <GC_OPTION>" 
>>>>>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>>>>
>>>>>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>>>>>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>> Tao
>>>>>>
>>>>>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>>>>>
>>>>>>> Hi Tao,
>>>>>>>
>>>>>>> I agree with John. The changes look fine and I'm ok with them. 
>>>>>>> But it would look nicer to add the 
>>>>>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>>>>>
>>>>>>> Also, regarding the test, a couple of minor things.
>>>>>>>
>>>>>>> First, with the new naming convention I think the test should be 
>>>>>>> called something like:
>>>>>>>
>>>>>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>>
>>>>>>> Then I think you can reduce the code duplication a bit. You 
>>>>>>> create the same ProcessBuilder and OutputAnalyzer in both 32 and 
>>>>>>> 64 bit cases. So maybe it could look like this instead:
>>>>>>>
>>>>>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>>>>>   public static void main(String args[]) throws Exception {
>>>>>>>     ProcessBuilder pb =
>>>>>>>       
>>>>>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>>>>>                                               "-Xmx3072m",
>>>>>>>                                               
>>>>>>> "-XX:MaxPermSize=1024m",
>>>>>>>                                               "-version");
>>>>>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>>>>
>>>>>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>>>>>     if (dataModel.equals("32")) {
>>>>>>>       output.shouldContain("The size of the object heap + perm 
>>>>>>> gen exceeds the maximum representable size");
>>>>>>>       if (output.getExitValue() == 0) {
>>>>>>>         throw new RuntimeException("Not expected to get exit 
>>>>>>> value 0");
>>>>>>>       }
>>>>>>>     } else if (dataModel.equals("64")) {
>>>>>>>       output.shouldHaveExitValue(0);
>>>>>>>     }
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> There is also a small bug in the test. If you run JTreg without 
>>>>>>> passing any vmoptions the test will fail. The reason is that 
>>>>>>> System.getProperty("test.vm.opts") will evaluate to the empty 
>>>>>>> string. This will be passed as the first argument to the Java 
>>>>>>> process, which will assume that this is the class name. So, it 
>>>>>>> fails to start because it can't load the class <empty string>.
>>>>>>>
>>>>>>> To reproduce the problem use this command line:
>>>>>>>
>>>>>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>>>>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>>
>>>>>>> I guess the fix is to check that 
>>>>>>> System.getProperty("test.vm.opts") is not empty before passing 
>>>>>>> it on to createJavaProcessBuilder().
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bengt
>>>>>>>
>>>>>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>>>>>> Hi Tao,
>>>>>>>>
>>>>>>>> This looks OK to me.
>>>>>>>>
>>>>>>>> I can see what Thomas is saying though. All of the checks 
>>>>>>>> involve something like:
>>>>>>>>
>>>>>>>> total += some_value;
>>>>>>>> if (total < some_value) {
>>>>>>>>   // We must have overflowed
>>>>>>>>   vm_exit(...);
>>>>>>>> }
>>>>>>>>
>>>>>>>> So a function in CollectedHeap (the base class of SharedHeap 
>>>>>>>> and ParallelScavengeHeap) might make sense. For example:
>>>>>>>>
>>>>>>>> total_reserved = 0;
>>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>>>> max_heap_size);
>>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>>>> max_perm_size);
>>>>>>>>
>>>>>>>> Where the function is:
>>>>>>>>
>>>>>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>>>>>   const char* msg = "...";
>>>>>>>>   x += y;
>>>>>>>>   if (x < y) {
>>>>>>>>     vm_exit(msg);
>>>>>>>>   }
>>>>>>>>   return x;
>>>>>>>> }
>>>>>>>>
>>>>>>>> But I can live with your current changes.
>>>>>>>>
>>>>>>>> JohnC
>>>>>>>>
>>>>>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>>>>>> Hi Bengt,
>>>>>>>>>
>>>>>>>>> Thank you for reviewing. A new webrev is updated.
>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Tao
>>>>>>>>>
>>>>>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Tao,
>>>>>>>>>>
>>>>>>>>>> This change looks good. Thanks for adding the JTReg test, it 
>>>>>>>>>> looks good!
>>>>>>>>>>
>>>>>>>>>> One minor nit:
>>>>>>>>>>
>>>>>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I 
>>>>>>>>>> would suggest to store "(size_t) 
>>>>>>>>>> align_size_up(pgs->max_size(), HeapRegion::GrainBytes)" in a 
>>>>>>>>>> local variable rather than duplicating the calculation.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Bengt
>>>>>>>>>>
>>>>>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>>>>>
>>>>>>>>>>> webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> changeset:
>>>>>>>>>>> The fix only needs to go to hsx24 since there's no perm gen 
>>>>>>>>>>> in hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>>>>>
>>>>>>>>>>> It provides for 32-bit builds a preventive check of the size 
>>>>>>>>>>> of "the object heap + perm gen" before reserving VM memory. 
>>>>>>>>>>> The total size should not exceed 4096MB (i.e. 4GB) for 
>>>>>>>>>>> 32-bit builds; otherwise, the total doesn't make sense and, 
>>>>>>>>>>> what's worse, overflow occurs. It will consequentially 
>>>>>>>>>>> trigger anther error of memory access violation, which was 
>>>>>>>>>>> not protected.
>>>>>>>>>>>
>>>>>>>>>>> jtreg testing java code is also written, checking both 
>>>>>>>>>>> 32-bit and (trivially) 64-bit builds.
>>>>>>>>>>>
>>>>>>>>>>> testing:
>>>>>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, 
>>>>>>>>>>> -XX:+UseG1GC, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, 
>>>>>>>>>>> -XX:+UseSerialGC and builds of 32-bit and 64-bit. All passed.
>>>>>>>>>>>
>>>>>>>>>>> Needs JPRT test when pushing.
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Leonid Mesnik
>>>>> JVM SQE
>>>
>>>
>>> -- 
>>> Leonid Mesnik
>>> JVM SQE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130430/ffb14166/attachment.htm>

From erik.helin at oracle.com  Tue Apr 30 18:33:34 2013
From: erik.helin at oracle.com (erik.helin at oracle.com)
Date: Tue, 30 Apr 2013 18:33:34 +0000
Subject: hg: hsx/hotspot-gc/hotspot: 8008541: Remove old code in HotSpot that
	supported the jmap -permstat functionality
Message-ID: <20130430183338.A3269486E3@hg.openjdk.java.net>

Changeset: 9075044ed66b
Author:    ehelin
Date:      2013-04-30 16:36 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9075044ed66b

8008541: Remove old code in HotSpot that supported the jmap -permstat functionality
Reviewed-by: sla, brutisso

! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java



From vladimir.kempik at oracle.com  Tue Apr 30 20:22:40 2013
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Wed, 1 May 2013 00:22:40 +0400
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <5180095F.0@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com> <51757C74.9000605@oracle.com>
	<5177B599.3050604@oracle.com> <517825D4.4020505@oracle.com>
	<517F9E14.8050707@oracle.com> <5180095F.0@oracle.com>
Message-ID: <DA4CF70D-8526-4216-9B14-6AEBDC3F4189@oracle.com>

Hi

It has easy reproducer.

In solaris sparc, run 32-bit java

java -Xmx4092M -version

Java6/7 crashes. With patch from webrev.03 it works as it should, saying it has not enough memory .
 Vladimir

30.04.2013, ? 22:11, Tao Mao <tao.mao at oracle.com> ???????(?):

> Hi Vladimir,
> 
> Can you point me to your bug you think it's associated with?
> 
> Thanks.
> Tao
> 
> On 4/30/13 3:33 AM, Vladimir Kempik wrote:
>> 
>> Hello.
>> 
>> I have a customer with non-escalated bug that is duplicate of this bug. I checked with patch from webrev.03 and can confirm that fixed the bug.
>> 
>> Could you guys approve it if it's fine?
>> 
>> Thanks. Vladimir.
>> On 24.04.2013 22:35, Tao Mao wrote:
>>> For 32-bit builds: The current changeset provides the first "protection" of heap size handling. Then comes handling whether we can allocate a certain amount of a heap.
>>> 
>>> For 64-bit builds: a machine with 512M-1GB memory should fail in many other tests as well, due to inability to lauch jvm.
>>> 
>>> Anyway, I ran the test and it passed. 
>>> 
>>> --------------------------------------------------
>>> Simply,
>>> 
>>> -bash-4.1$ ulimit -v 134217728 (128m for human reading)
>>> -bash-4.1$ ulimit -m 134217728 (128m FHR)
>>> 
>>> (cannot limit virtual memory to zero or set vm.swappiness=0, in which case the server would hang immediately w/o even launching jvm. But, the setting should satisfy your question.)
>>> 
>>> Then, run jtreg. Then, pass.
>>> --------------------------------------------------
>>> 
>>> BTW, since you've jumped in this thread ^_^ can you check the way I get system property through "test.java.opts" to set inside jvm process? It's in test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>> 
>>> Thank you.
>>> Tao
>>> 
>>> On 4/24/13 3:36 AM, Leonid Mesnik wrote:
>>>> 
>>>> On 04/22/2013 10:07 PM, Tao Mao wrote:
>>>>> This should be handled by a separate CR (probably by this CR https://jbs.oracle.com/bugs/browse/JDK-7112912)
>>>>> 
>>>> Why this? I mean should your test pass on hosts with *small* amount of memory. 
>>>> 
>>>> Leonid
>>>>> Thanks.
>>>>> Tao
>>>>> 
>>>>> On 4/22/13 2:46 AM, Leonid Mesnik wrote:
>>>>>> 
>>>>>> Tao 
>>>>>> 
>>>>>> This is not review, just question. 
>>>>>> 
>>>>>> Should you test pass on hosts with 512M-1GB memory and no swap? 
>>>>>> 
>>>>>> Leonid
>>>>>> On 04/19/2013 09:27 PM, Tao Mao wrote:
>>>>>>> 1. check overflow routine is wrapped up.
>>>>>>> 
>>>>>>> 2. The reduction of code duplication is adopted.
>>>>>>> 
>>>>>>> 3. Develop a way to intake 0~multiple external vm options in jtreg main(). Hope it helps others implement similar functionality.
>>>>>>> 
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>>>>>> 
>>>>>>> test:
>>>>>>> JTREG: passed.
>>>>>>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao <GC_OPTION>" /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>>>>> 
>>>>>>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks.
>>>>>>> Tao
>>>>>>> 
>>>>>>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Tao,
>>>>>>>> 
>>>>>>>> I agree with John. The changes look fine and I'm ok with them. But it would look nicer to add the CollectedHeap::add_and_verify_no_overflow() method.
>>>>>>>> 
>>>>>>>> Also, regarding the test, a couple of minor things.
>>>>>>>> 
>>>>>>>> First, with the new naming convention I think the test should be called something like:
>>>>>>>> 
>>>>>>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>>> 
>>>>>>>> Then I think you can reduce the code duplication a bit. You create the same ProcessBuilder and OutputAnalyzer in both 32 and 64 bit cases. So maybe it could look like this instead:
>>>>>>>> 
>>>>>>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>>>>>>   public static void main(String args[]) throws Exception {
>>>>>>>>     ProcessBuilder pb =
>>>>>>>>       ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>>>>>>                                               "-Xmx3072m",
>>>>>>>>                                               "-XX:MaxPermSize=1024m",
>>>>>>>>                                               "-version");
>>>>>>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>>>>> 
>>>>>>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>>>>>>     if (dataModel.equals("32")) {
>>>>>>>>       output.shouldContain("The size of the object heap + perm gen exceeds the maximum representable size");
>>>>>>>>       if (output.getExitValue() == 0) {
>>>>>>>>         throw new RuntimeException("Not expected to get exit value 0");
>>>>>>>>       }
>>>>>>>>     } else if (dataModel.equals("64")) {
>>>>>>>>       output.shouldHaveExitValue(0);
>>>>>>>>     }
>>>>>>>>   }
>>>>>>>> }
>>>>>>>> 
>>>>>>>> There is also a small bug in the test. If you run JTreg without passing any vmoptions the test will fail. The reason is that System.getProperty("test.vm.opts") will evaluate to the empty string. This will be passed as the first argument to the Java process, which will assume that this is the class name. So, it fails to start because it can't load the class <empty string>.
>>>>>>>> 
>>>>>>>> To reproduce the problem use this command line:
>>>>>>>> 
>>>>>>>> java  -jar <path_to_jtreg>/lib/jtreg.jar test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>>> 
>>>>>>>> I guess the fix is to check that System.getProperty("test.vm.opts") is not empty before passing it on to createJavaProcessBuilder().
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Bengt
>>>>>>>> 
>>>>>>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>>>>>>> Hi Tao,
>>>>>>>>> 
>>>>>>>>> This looks OK to me.
>>>>>>>>> 
>>>>>>>>> I can see what Thomas is saying though. All of the checks involve something like:
>>>>>>>>> 
>>>>>>>>> total += some_value;
>>>>>>>>> if (total < some_value) {
>>>>>>>>>   // We must have overflowed
>>>>>>>>>   vm_exit(...);
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> So a function in CollectedHeap (the base class of SharedHeap and ParallelScavengeHeap) might make sense. For example:
>>>>>>>>> 
>>>>>>>>> total_reserved = 0;
>>>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, max_heap_size);
>>>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, max_perm_size);
>>>>>>>>> 
>>>>>>>>> Where the function is:
>>>>>>>>> 
>>>>>>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>>>>>>   const char* msg = "...";
>>>>>>>>>   x += y;
>>>>>>>>>   if (x < y) {
>>>>>>>>>     vm_exit(msg);
>>>>>>>>>   }
>>>>>>>>>   return x;
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> But I can live with your current changes.
>>>>>>>>> 
>>>>>>>>> JohnC
>>>>>>>>> 
>>>>>>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>>>>>>> Hi Bengt,
>>>>>>>>>> 
>>>>>>>>>> Thank you for reviewing. A new webrev is updated.
>>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Tao
>>>>>>>>>> 
>>>>>>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi Tao,
>>>>>>>>>>> 
>>>>>>>>>>> This change looks good. Thanks for adding the JTReg test, it looks good!
>>>>>>>>>>> 
>>>>>>>>>>> One minor nit:
>>>>>>>>>>> 
>>>>>>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I would suggest to store "(size_t) align_size_up(pgs->max_size(), HeapRegion::GrainBytes)" in a local variable rather than duplicating the calculation.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Bengt
>>>>>>>>>>> 
>>>>>>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>>>>>> 
>>>>>>>>>>>> webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> changeset:
>>>>>>>>>>>> The fix only needs to go to hsx24 since there's no perm gen in hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>>>>>> 
>>>>>>>>>>>> It provides for 32-bit builds a preventive check of the size of "the object heap + perm gen" before reserving VM memory. The total size should not exceed 4096MB (i.e. 4GB) for 32-bit builds; otherwise, the total doesn't make sense and, what's worse, overflow occurs. It will consequentially trigger anther error of memory access violation, which was not protected.
>>>>>>>>>>>> 
>>>>>>>>>>>> jtreg testing java code is also written, checking both 32-bit and (trivially) 64-bit builds.
>>>>>>>>>>>> 
>>>>>>>>>>>> testing:
>>>>>>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, -XX:+UseG1GC, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, -XX:+UseSerialGC and builds of 32-bit and 64-bit. All passed.
>>>>>>>>>>>> 
>>>>>>>>>>>> Needs JPRT test when pushing.
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Leonid Mesnik
>>>>>> JVM SQE
>>>> 
>>>> 
>>>> -- 
>>>> Leonid Mesnik
>>>> JVM SQE
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130501/242745d0/attachment.htm>

From tao.mao at oracle.com  Tue Apr 30 21:52:48 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 30 Apr 2013 14:52:48 -0700
Subject: Request for review: 6761744 Hotspot crashes if process size limit
	is exceeded
In-Reply-To: <DA4CF70D-8526-4216-9B14-6AEBDC3F4189@oracle.com>
References: <51625424.4050209@oracle.com> <516528C2.8080709@oracle.com>
	<516598D3.1020809@oracle.com> <5168B1AD.7060302@oracle.com>
	<516BBC64.6060509@oracle.com> <51717E6E.4020806@oracle.com>
	<517506EE.5030000@oracle.com> <51757C74.9000605@oracle.com>
	<5177B599.3050604@oracle.com> <517825D4.4020505@oracle.com>
	<517F9E14.8050707@oracle.com> <5180095F.0@oracle.com>
	<DA4CF70D-8526-4216-9B14-6AEBDC3F4189@oracle.com>
Message-ID: <51803D30.6090406@oracle.com>

IMHO, what the customer reported could be a similar but different bug.

What version did they use, and what gc?

Thanks.
Tao

On 4/30/13 1:22 PM, Vladimir Kempik wrote:
> Hi
>
> It has easy reproducer.
>
> In solaris sparc, run 32-bit java
>
> java -Xmx4092M -version
>
> Java6/7 crashes. With patch from webrev.03 it works as it should, 
> saying it has not enough memory .
>  Vladimir
>
> 30.04.2013, ? 22:11, Tao Mao <tao.mao at oracle.com 
> <mailto:tao.mao at oracle.com>> ???????(?):
>
>> Hi Vladimir,
>>
>> Can you point me to your bug you think it's associated with?
>>
>> Thanks.
>> Tao
>>
>> On 4/30/13 3:33 AM, Vladimir Kempik wrote:
>>> Hello.
>>>
>>> I have a customer with non-escalated bug that is duplicate of this 
>>> bug. I checked with patch from webrev.03 and can confirm that fixed 
>>> the bug.
>>>
>>> Could you guys approve it if it's fine?
>>>
>>> Thanks. Vladimir.
>>> On 24.04.2013 22:35, Tao Mao wrote:
>>>> For 32-bit builds: The current changeset provides the first 
>>>> "protection" of heap size handling. Then comes handling whether we 
>>>> can allocate a certain amount of a heap.
>>>>
>>>> For 64-bit builds: a machine with 512M-1GB memory should fail in 
>>>> many other tests as well, due to inability to lauch jvm.
>>>>
>>>> Anyway, I ran the test and it passed.
>>>>
>>>> --------------------------------------------------
>>>> Simply,
>>>>
>>>> -bash-4.1$ ulimit -v 134217728 (128m for human reading)
>>>> -bash-4.1$ ulimit -m 134217728 (128m FHR)
>>>>
>>>> (cannot limit virtual memory to zero or set vm.swappiness=0, in 
>>>> which case the server would hang immediately w/o even launching 
>>>> jvm. But, the setting should satisfy your question.)
>>>>
>>>> Then, run jtreg. Then, pass.
>>>> --------------------------------------------------
>>>>
>>>> BTW, since you've jumped in this thread ^_^ can you check the way I 
>>>> get system property through "test.java.opts" to set inside jvm 
>>>> process? It's in 
>>>> test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>>
>>>> Thank you.
>>>> Tao
>>>>
>>>> On 4/24/13 3:36 AM, Leonid Mesnik wrote:
>>>>> On 04/22/2013 10:07 PM, Tao Mao wrote:
>>>>>> This should be handled by a separate CR (probably by this CR 
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-7112912)
>>>>>>
>>>>> Why this? I mean should your test pass on hosts with *small* 
>>>>> amount of memory.
>>>>>
>>>>> Leonid
>>>>>> Thanks.
>>>>>> Tao
>>>>>>
>>>>>> On 4/22/13 2:46 AM, Leonid Mesnik wrote:
>>>>>>> Tao
>>>>>>>
>>>>>>> This is not review, just question.
>>>>>>>
>>>>>>> Should you test pass on hosts with 512M-1GB memory and no swap?
>>>>>>>
>>>>>>> Leonid
>>>>>>> On 04/19/2013 09:27 PM, Tao Mao wrote:
>>>>>>>> 1. check overflow routine is wrapped up.
>>>>>>>>
>>>>>>>> 2. The reduction of code duplication is adopted.
>>>>>>>>
>>>>>>>> 3. Develop a way to intake 0~multiple external vm options in 
>>>>>>>> jtreg main(). Hope it helps others implement similar functionality.
>>>>>>>>
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.02/
>>>>>>>>
>>>>>>>> test:
>>>>>>>> JTREG: passed.
>>>>>>>> jtreg -jdk:/home/tamao/jdk1.7.0_04-i586 -vmoptions:"-tamao 
>>>>>>>> <GC_OPTION>" 
>>>>>>>> /home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java
>>>>>>>>
>>>>>>>> where GC_OPTION rotates in -XX:+UseParallelGC -XX:+UseG1GC 
>>>>>>>> -XX:+UseSerialGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Tao
>>>>>>>>
>>>>>>>> On 4/15/13 1:37 AM, Bengt Rutisson wrote:
>>>>>>>>>
>>>>>>>>> Hi Tao,
>>>>>>>>>
>>>>>>>>> I agree with John. The changes look fine and I'm ok with them. 
>>>>>>>>> But it would look nicer to add the 
>>>>>>>>> CollectedHeap::add_and_verify_no_overflow() method.
>>>>>>>>>
>>>>>>>>> Also, regarding the test, a couple of minor things.
>>>>>>>>>
>>>>>>>>> First, with the new naming convention I think the test should 
>>>>>>>>> be called something like:
>>>>>>>>>
>>>>>>>>> test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>>>>
>>>>>>>>> Then I think you can reduce the code duplication a bit. You 
>>>>>>>>> create the same ProcessBuilder and OutputAnalyzer in both 32 
>>>>>>>>> and 64 bit cases. So maybe it could look like this instead:
>>>>>>>>>
>>>>>>>>> public class TestHandleExceedingProcessSizeLimitOn32BitSystems {
>>>>>>>>>   public static void main(String args[]) throws Exception {
>>>>>>>>>     ProcessBuilder pb =
>>>>>>>>>       
>>>>>>>>> ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),
>>>>>>>>>                                               "-Xmx3072m",
>>>>>>>>>                                               
>>>>>>>>> "-XX:MaxPermSize=1024m",
>>>>>>>>>                                               "-version");
>>>>>>>>>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>>>>>>>>>
>>>>>>>>>     String dataModel = System.getProperty("sun.arch.data.model");
>>>>>>>>>     if (dataModel.equals("32")) {
>>>>>>>>>       output.shouldContain("The size of the object heap + perm 
>>>>>>>>> gen exceeds the maximum representable size");
>>>>>>>>>       if (output.getExitValue() == 0) {
>>>>>>>>>         throw new RuntimeException("Not expected to get exit 
>>>>>>>>> value 0");
>>>>>>>>>       }
>>>>>>>>>     } else if (dataModel.equals("64")) {
>>>>>>>>>       output.shouldHaveExitValue(0);
>>>>>>>>>     }
>>>>>>>>>   }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> There is also a small bug in the test. If you run JTreg 
>>>>>>>>> without passing any vmoptions the test will fail. The reason 
>>>>>>>>> is that System.getProperty("test.vm.opts") will evaluate to 
>>>>>>>>> the empty string. This will be passed as the first argument to 
>>>>>>>>> the Java process, which will assume that this is the class 
>>>>>>>>> name. So, it fails to start because it can't load the class 
>>>>>>>>> <empty string>.
>>>>>>>>>
>>>>>>>>> To reproduce the problem use this command line:
>>>>>>>>>
>>>>>>>>> java  -jar <path_to_jtreg>/lib/jtreg.jar 
>>>>>>>>> test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java
>>>>>>>>>
>>>>>>>>> I guess the fix is to check that 
>>>>>>>>> System.getProperty("test.vm.opts") is not empty before passing 
>>>>>>>>> it on to createJavaProcessBuilder().
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Bengt
>>>>>>>>>
>>>>>>>>> On 4/13/13 3:15 AM, John Cuthbertson wrote:
>>>>>>>>>> Hi Tao,
>>>>>>>>>>
>>>>>>>>>> This looks OK to me.
>>>>>>>>>>
>>>>>>>>>> I can see what Thomas is saying though. All of the checks 
>>>>>>>>>> involve something like:
>>>>>>>>>>
>>>>>>>>>> total += some_value;
>>>>>>>>>> if (total < some_value) {
>>>>>>>>>>   // We must have overflowed
>>>>>>>>>>   vm_exit(...);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> So a function in CollectedHeap (the base class of SharedHeap 
>>>>>>>>>> and ParallelScavengeHeap) might make sense. For example:
>>>>>>>>>>
>>>>>>>>>> total_reserved = 0;
>>>>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>>>>>> max_heap_size);
>>>>>>>>>> total_reserved = add_and_verify_no_overflow(total_reserved, 
>>>>>>>>>> max_perm_size);
>>>>>>>>>>
>>>>>>>>>> Where the function is:
>>>>>>>>>>
>>>>>>>>>> size_t add_and_verify_no_overflow(size_t x, size_t y) {
>>>>>>>>>>   const char* msg = "...";
>>>>>>>>>>   x += y;
>>>>>>>>>>   if (x < y) {
>>>>>>>>>>     vm_exit(msg);
>>>>>>>>>>   }
>>>>>>>>>>   return x;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> But I can live with your current changes.
>>>>>>>>>>
>>>>>>>>>> JohnC
>>>>>>>>>>
>>>>>>>>>> On 4/10/2013 9:52 AM, Tao Mao wrote:
>>>>>>>>>>> Hi Bengt,
>>>>>>>>>>>
>>>>>>>>>>> Thank you for reviewing. A new webrev is updated.
>>>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Tao
>>>>>>>>>>>
>>>>>>>>>>> On 4/10/13 1:54 AM, Bengt Rutisson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Tao,
>>>>>>>>>>>>
>>>>>>>>>>>> This change looks good. Thanks for adding the JTReg test, 
>>>>>>>>>>>> it looks good!
>>>>>>>>>>>>
>>>>>>>>>>>> One minor nit:
>>>>>>>>>>>>
>>>>>>>>>>>> In src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp I 
>>>>>>>>>>>> would suggest to store "(size_t) 
>>>>>>>>>>>> align_size_up(pgs->max_size(), HeapRegion::GrainBytes)" in 
>>>>>>>>>>>> a local variable rather than duplicating the calculation.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Bengt
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/8/13 7:22 AM, Tao Mao wrote:
>>>>>>>>>>>>> 6761744 Hotspot crashes if process size limit is exceeded
>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6761744
>>>>>>>>>>>>>
>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~tamao/6761744/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> changeset:
>>>>>>>>>>>>> The fix only needs to go to hsx24 since there's no perm 
>>>>>>>>>>>>> gen in hotspot-25. Thus, the webrev is based on hsx24 repo.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It provides for 32-bit builds a preventive check of the 
>>>>>>>>>>>>> size of "the object heap + perm gen" before reserving VM 
>>>>>>>>>>>>> memory. The total size should not exceed 4096MB (i.e. 4GB) 
>>>>>>>>>>>>> for 32-bit builds; otherwise, the total doesn't make sense 
>>>>>>>>>>>>> and, what's worse, overflow occurs. It will 
>>>>>>>>>>>>> consequentially trigger anther error of memory access 
>>>>>>>>>>>>> violation, which was not protected.
>>>>>>>>>>>>>
>>>>>>>>>>>>> jtreg testing java code is also written, checking both 
>>>>>>>>>>>>> 32-bit and (trivially) 64-bit builds.
>>>>>>>>>>>>>
>>>>>>>>>>>>> testing:
>>>>>>>>>>>>> check jtreg tests with flags -XX:+UseParallelGC, 
>>>>>>>>>>>>> -XX:+UseG1GC, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC, 
>>>>>>>>>>>>> -XX:+UseSerialGC and builds of 32-bit and 64-bit. All passed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Needs JPRT test when pushing.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Leonid Mesnik
>>>>>>> JVM SQE
>>>>>
>>>>>
>>>>> -- 
>>>>> Leonid Mesnik
>>>>> JVM SQE
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130430/2103e8ea/attachment.htm>

From tao.mao at oracle.com  Tue Apr 30 23:58:57 2013
From: tao.mao at oracle.com (Tao Mao)
Date: Tue, 30 Apr 2013 16:58:57 -0700
Subject: Request for review: 8010506 Typos and errors in gc-related flags
	in globals.hpp
In-Reply-To: <514B850C.7050709@oracle.com>
References: <514B850C.7050709@oracle.com>
Message-ID: <51805AC1.9040802@oracle.com>

new webrev
http://cr.openjdk.java.net/~tamao/8010506/webrev.01/

It needs reviews.

Changeset:
Thank you for the thorough report of all these typos/errros, Thomas.

I changed most places according to your suggestions (for the rest few, I 
did not change because it may slightly change the meaning of the 
definition). Also, I went through the file to change some similar common 
errors that occurred.

Several issues:

(1) parallel gc should be lower case or upper case?
As I know and, perhaps, someone told me, the term "parallel gc" 
sometimes refers to a more generic terminology rather than ParallelGC or 
ParallelOldGC, if it doesn't imply these two. Basically, any GC 
algorithms that can be parallelized could fall into this category. Right 
now, we probably refer "parallel gc" to ParallelGC or ParallelOldGC. 
But, we reserve the right to change it to something else. That's why 
"fuzziness" exists here. I guess the same way to deal with "concurrent 
gc". So, I didn't make these words upper cased.

(2) Identification:
The general rule is to follow the example (product()'s identification). 
The whole file checked and space adjusted accordingly.

(3) Line breaks
A space should be provided at the line breaks if multiple lines is 
needed. Some lines that are slightly longer than normal length is kept 
untouched as long as they read well.

*(4) Why does the VM option hashCode have lower case initial?
The direct answer is "I don't know". (But it is understandable that 
hashCode is "legacy" such that it has it own style) Anyone knows the answer?

Thanks.
Tao

On 3/21/13 3:09 PM, Tao Mao wrote:
> 8010506 Typos and errors in gc-related flags in globals.hpp
> https://jbs.oracle.com/bugs/browse/JDK-8010506
>
> webrev:
> http://cr.openjdk.java.net/~tamao/8010506/webrev.00/
>
> Changeset:
> NewRatio should defined as
> product(uintx, NewRatio, 
> 2,                                               \
>     "Ratio of old/new generation sizes")                              \
> instead of
> product(uintx, NewRatio, 
> 2,                                               \
>     "Ratio of new/old generation sizes")                              \
>
> PLUS other typos found by Jesper.