From linuxhippy at gmail.com  Fri Jan  2 17:24:33 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 3 Jan 2009 02:24:33 +0100
Subject: Restrictions for lock coarsening?
Message-ID: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>

Hi,

I've created a microbenchmark for some fine-graind locking pattern to
see if my workload can profit from Hotspot's  lock coarsening.
The benchmark itself is single-threaded so no contention occurs at
all, real-world workload might have very little contention.

The benchmark-loop itself looks like: while (true) { for (int i = 0; i
< 1000000; i++) { doItAndTakeTime(); }}
doItAndTakeTime() is one time synchronized, another time its guarded
by an ReentrantLock and for comparison I benchmarked an unsynchronized
version.

These were my results:
> Without synchronization:   48ms
> SunToolkit.awtLock/unLock: 92ms
> Monitor:                   108ms

I hoped to see some improvements when using a monitor because of  lock
coarsening, but with the server-jvm on my Core2Duo it seems
synchronization using a monitor is the slowest path.
I also didn't see any change when specifying -XX:-EliminateLocks, or
when manually unrolling the loop.

PrintCompilation says that the method in question is 106 bytes, but I
guess when inlining all the called methods it easily sums up to
~300bytes of bytecode.

Any idea what could be the reason why lock coarsening does not seem to
be active for this simple case?

Thank you in advance, Clemens


From Y.S.Ramakrishna at Sun.COM  Fri Jan  2 20:50:17 2009
From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna)
Date: Fri, 02 Jan 2009 20:50:17 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
Message-ID: <f836d9637c08.495e7e09@sun.com>

Could you specify what you are doing inside
doItAndTakeTime()? (i.e. what's the code
executed in the synchronized block).

-- ramki
(not a lock coarsening expert, just a by-stander asking questions)

----- Original Message -----
From: Clemens Eisserer <linuxhippy at gmail.com>
Date: Friday, January 2, 2009 5:24 pm
Subject: Restrictions for lock coarsening?
To: hotspot-runtime-dev at openjdk.java.net


> Hi,
> 
> I've created a microbenchmark for some fine-graind locking pattern to
> see if my workload can profit from Hotspot's  lock coarsening.
> The benchmark itself is single-threaded so no contention occurs at
> all, real-world workload might have very little contention.
> 
> The benchmark-loop itself looks like: while (true) { for (int i = 0; i
> < 1000000; i++) { doItAndTakeTime(); }}
> doItAndTakeTime() is one time synchronized, another time its guarded
> by an ReentrantLock and for comparison I benchmarked an unsynchronized
> version.
> 
> These were my results:
> > Without synchronization:   48ms
> > SunToolkit.awtLock/unLock: 92ms
> > Monitor:                   108ms
> 
> I hoped to see some improvements when using a monitor because of  lock
> coarsening, but with the server-jvm on my Core2Duo it seems
> synchronization using a monitor is the slowest path.
> I also didn't see any change when specifying -XX:-EliminateLocks, or
> when manually unrolling the loop.
> 
> PrintCompilation says that the method in question is 106 bytes, but I
> guess when inlining all the called methods it easily sums up to
> ~300bytes of bytecode.
> 
> Any idea what could be the reason why lock coarsening does not seem to
> be active for this simple case?
> 
> Thank you in advance, Clemens


From linuxhippy at gmail.com  Sat Jan  3 01:56:30 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 3 Jan 2009 10:56:30 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <f836d9637c08.495e7e09@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
Message-ID: <194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>

Hi ramki,

> Could you specify what you are doing inside
> doItAndTakeTime()? (i.e. what's the code
> executed in the synchronized block).
Basically only pushing data onto a sun.misc.Unsafe and a little bit of
state-checking (if the buffer still has enough capacity to hold the
next request, as well as if we currently hold the socket):
http://pastebin.com/f4e8a8eec

I accidentially named it _AndTakeTime() in the example, of course I
take the time outside the loop.
Furthermore in the benchmark the socket is always taken and flushing
only re-sets the buffer's position.

Thanks, Clemens


From linuxhippy at gmail.com  Sun Jan  4 15:09:43 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 5 Jan 2009 00:09:43 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
Message-ID: <194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>

Hi Dave,

Thanks again for taking the time to anwer my neverending locking questions ;)

> Locks and monitors have precisely the same semantics with respect to the
> java memory model.
Glad to hear that :)

> Coarsening is a bit tricky.   IIRC we only coarsen abutting or nearly
> abutting critical sections under the same lock but I don't think we'll hoist
> the critical section outside of a loop.   Coarsening is, for the most part,
> an optimization that attempts to avoid CAS / lock:cmpxchg which have a
> _local latency penalty.   In addition it gives the JIT more latitude in the
> fact of the memory model (we can avoid spilling variables back to memory
> with larger critical sections).   That having been said,  you don't really
> want to coarsen critical sections if there's contention.  (Recall that we
> can capture code that's _not part of a critical section inside a coarsened
> section, thus artificially lengthening the critical section).   Ideally we'd
> have runtime feedback and decoarsen contended critical sections but that's
> not implemented as of today, so instead the mechanism is fairly
> conservative.
Well, my benchmark does execute the method in question in a loop,
there's only one monitor in action and the benchmark is
single-threaded so there is no contention. Could it be that coarsening
does not occur because the synchronized method is too large or has too
complex control flow (if/else, maybe even loops)? Or maybe coarening
is limited to non-OSR compilation?

In reallity there won't be contention for almost all of the use-cases,
but the api is specified to be thread-safe and therefor there is no
way arround synchronization. The reason why I am interested in
coarsening is, that CAS means quite a lot of local latency - on my
Core2Duo 50% of the total time is spent in locking. I guess the
problem will vanish with better CAS implementations ;)

Thanks again, Clemens


From David.Holmes at Sun.COM  Sun Jan  4 18:39:08 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Mon, 05 Jan 2009 12:39:08 +1000
Subject: Restrictions for lock coarsening?
In-Reply-To: <194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
Message-ID: <496172CC.6040705@sun.com>

Hi Clemens,

As Dave correctly recalled, locks are not hoisted out of a loop, so that 
kind of coarsening does not occur. Hence your benchmark will not 
experience any lock coarsening.

See callNode.cpp 1378:

Node *LockNode::Ideal(PhaseGVN *phase, bool can_reshape) {

for the code that does the lock elision/coarsening.

Cheers,
David Holmes

Clemens Eisserer said the following on 01/05/09 09:09:
> Hi Dave,
> 
> Thanks again for taking the time to anwer my neverending locking questions ;)
> 
>> Locks and monitors have precisely the same semantics with respect to the
>> java memory model.
> Glad to hear that :)
> 
>> Coarsening is a bit tricky.   IIRC we only coarsen abutting or nearly
>> abutting critical sections under the same lock but I don't think we'll hoist
>> the critical section outside of a loop.   Coarsening is, for the most part,
>> an optimization that attempts to avoid CAS / lock:cmpxchg which have a
>> _local latency penalty.   In addition it gives the JIT more latitude in the
>> fact of the memory model (we can avoid spilling variables back to memory
>> with larger critical sections).   That having been said,  you don't really
>> want to coarsen critical sections if there's contention.  (Recall that we
>> can capture code that's _not part of a critical section inside a coarsened
>> section, thus artificially lengthening the critical section).   Ideally we'd
>> have runtime feedback and decoarsen contended critical sections but that's
>> not implemented as of today, so instead the mechanism is fairly
>> conservative.
> Well, my benchmark does execute the method in question in a loop,
> there's only one monitor in action and the benchmark is
> single-threaded so there is no contention. Could it be that coarsening
> does not occur because the synchronized method is too large or has too
> complex control flow (if/else, maybe even loops)? Or maybe coarening
> is limited to non-OSR compilation?
> 
> In reallity there won't be contention for almost all of the use-cases,
> but the api is specified to be thread-safe and therefor there is no
> way arround synchronization. The reason why I am interested in
> coarsening is, that CAS means quite a lot of local latency - on my
> Core2Duo 50% of the total time is spent in locking. I guess the
> problem will vanish with better CAS implementations ;)
> 
> Thanks again, Clemens


From Dave.Dice at Sun.COM  Sun Jan  4 18:46:31 2009
From: Dave.Dice at Sun.COM (Dave Dice)
Date: Sun, 04 Jan 2009 21:46:31 -0500
Subject: Restrictions for lock coarsening?
In-Reply-To: <194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
Message-ID: <9050762B-3531-4722-A0CD-58E79C696D5B@Sun.COM>


On 2009-1-4, at 6:09 PM, Clemens Eisserer wrote:

> Hi Dave,
>
> Thanks again for taking the time to anwer my neverending locking  
> questions ;)
>
>> Locks and monitors have precisely the same semantics with respect  
>> to the
>> java memory model.
> Glad to hear that :)
>
>> Coarsening is a bit tricky.   IIRC we only coarsen abutting or nearly
>> abutting critical sections under the same lock but I don't think  
>> we'll hoist
>> the critical section outside of a loop.   Coarsening is, for the  
>> most part,
>> an optimization that attempts to avoid CAS / lock:cmpxchg which  
>> have a
>> _local latency penalty.   In addition it gives the JIT more  
>> latitude in the
>> fact of the memory model (we can avoid spilling variables back to  
>> memory
>> with larger critical sections).   That having been said,  you don't  
>> really
>> want to coarsen critical sections if there's contention.  (Recall  
>> that we
>> can capture code that's _not part of a critical section inside a  
>> coarsened
>> section, thus artificially lengthening the critical section).    
>> Ideally we'd
>> have runtime feedback and decoarsen contended critical sections but  
>> that's
>> not implemented as of today, so instead the mechanism is fairly
>> conservative.
> Well, my benchmark does execute the method in question in a loop,
> there's only one monitor in action and the benchmark is
> single-threaded so there is no contention. Could it be that coarsening
> does not occur because the synchronized method is too large or has too
> complex control flow (if/else, maybe even loops)? Or maybe coarening
> is limited to non-OSR compilation?
>
> In reallity there won't be contention for almost all of the use-cases,
> but the api is specified to be thread-safe and therefor there is no
> way arround synchronization. The reason why I am interested in
> coarsening is, that CAS means quite a lot of local latency - on my
> Core2Duo 50% of the total time is spent in locking. I guess the
> problem will vanish with better CAS implementations ;)

Hi Clemens,


Process designers finally seem aware of the issue and the trend is  
toward some improvement.

Regards
Dave



>
>
> Thanks again, Clemens



From Thomas.Rodriguez at Sun.COM  Mon Jan  5 11:19:54 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Mon, 05 Jan 2009 11:19:54 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
Message-ID: <44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>


> Well, my benchmark does execute the method in question in a loop,
> there's only one monitor in action and the benchmark is
> single-threaded so there is no contention. Could it be that coarsening
> does not occur because the synchronized method is too large or has too
> complex control flow (if/else, maybe even loops)? Or maybe coarening
> is limited to non-OSR compilation?

Coarsening won't rearrange control to create opportunities for  
itself.  The basic strategy is to look for straightline control where  
an unlock meets a lock of the same monitor.  If your loop body  
contains only one copy of your locked section then there's nothing  
coarsening can do.  If C2 chooses to unroll your loop body then you  
will end up with multiple copies which could then be coarsened.  It  
sounds like your loop body is probably too large for unrolling to  
trigger so I don't think it can help.

> In reallity there won't be contention for almost all of the use-cases,
> but the api is specified to be thread-safe and therefor there is no
> way arround synchronization. The reason why I am interested in
> coarsening is, that CAS means quite a lot of local latency - on my
> Core2Duo 50% of the total time is spent in locking. I guess the
> problem will vanish with better CAS implementations ;)
>

Hmm.  I would expect biased locking to handle your case perfectly with  
no CAS if things are as you describe.  For startup purposes biased  
locking disabled at the beginning of the VM and is enabled after about  
4 seconds.  This means that objects created during that time period  
aren't allowed to use biased locking.  Is it possible your test case  
is short enough to fall into this?  -XX:BiasedLockingStartupDelay= can  
be use to set the delay in milliseconds.  Also note that there's an  
oddity with OSR and locking where any locks that are held at the OSR  
point are inflated and end up using heavyweight locking until the lock  
is deflated.

tom


From linuxhippy at gmail.com  Tue Jan  6 09:47:13 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 6 Jan 2009 18:47:13 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
Message-ID: <194f62550901060947g764013dar614ae31419febd4@mail.gmail.com>

Hello Tom,

> The basic strategy is to look for straightline control where an unlock meets a
> lock of the same monitor.  If your loop body contains only one copy of your
> locked section then there's nothing coarsening can do.
Ah, thanks for the explanation.
I guess coarsening won't work anyway for my type of code, there is
probably too much code between unlock/lock and too complicated call
stacks.

> Hmm.  I would expect biased locking to handle your case perfectly with no
> CAS if things are as you describe.  For startup purposes biased locking
> disabled at the beginning of the VM and is enabled after about 4 seconds.
Yes, with BiasedLocking the overhead is almost reduced to noise ...
and I guess it would be the perfect fit :)
Unfourtunatly the stuff integrates as part of the JRE and is almost
always created at startup.
I guess however disabling the biased-locking startup delay by default
would have some other negative impacts :-/

Thanks again, Clemens


From karen.kinnear at sun.com  Tue Jan  6 09:53:32 2009
From: karen.kinnear at sun.com (karen.kinnear at sun.com)
Date: Tue, 06 Jan 2009 17:53:32 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 4670071: loadClassInternal is too
	restrictive.
Message-ID: <20090106175334.99781D13B@hg.openjdk.java.net>

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

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

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



From christian.thalinger at gmail.com  Tue Jan  6 10:01:14 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Tue, 06 Jan 2009 19:01:14 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
Message-ID: <1231264874.3075.15.camel@localhost.localdomain>

[Slightly off-topic.]
	
On Mon, 2009-01-05 at 11:19 -0800, Tom Rodriguez wrote:
> Hmm.  I would expect biased locking to handle your case perfectly with  
> no CAS if things are as you describe.  For startup purposes biased  
> locking disabled at the beginning of the VM and is enabled after about  
> 4 seconds.

This already came up once and I wanted to ask the following question
back then (but forgot):

Why is it an absolute time value and not some definite point in the VM
startup sequence?

> This means that objects created during that time period  
> aren't allowed to use biased locking.

Throughout the whole lifetime?

- Christian



From Thomas.Rodriguez at Sun.COM  Tue Jan  6 10:30:52 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Tue, 06 Jan 2009 10:30:52 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231264874.3075.15.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
Message-ID: <85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>

> This already came up once and I wanted to ask the following question
> back then (but forgot):
>
> Why is it an absolute time value and not some definite point in the VM
> startup sequence?

The delay in enabling biased locking is basically just a workaround  
for startup issues that were encountered with enabling biased locking  
by default.  4 seconds was an empirically derived number that gave us  
the startup behaviour we wanted and it's well after the JVM has  
finished starting up so it couldn't be part of our startup since it's  
already done.

>
>
>> This means that objects created during that time period
>> aren't allowed to use biased locking.
>
> Throughout the whole lifetime?

Throughout the whole lifetime of that object.  Biased locking  
maintains state in the header of an object which says whether it can  
be biased or not.  The initial state is read from its the class  
object's Klass::_prototype_header field at allocation time and is  
written into the header word.  The biased locking startup delay works  
by having every classes initial state be not biasable and then after  
the delay expires they are all marked as biasable.  Every object  
allocated after that point will be biasable.  It's definitely an  
unsatisfying solution.

tom

>
>
> - Christian
>



From christian.thalinger at gmail.com  Tue Jan  6 10:46:56 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Tue, 06 Jan 2009 19:46:56 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
Message-ID: <1231267616.3075.27.camel@localhost.localdomain>

On Tue, 2009-01-06 at 10:30 -0800, Tom Rodriguez wrote:
> >> This means that objects created during that time period
> >> aren't allowed to use biased locking.
> >
> > Throughout the whole lifetime?
> 
> Throughout the whole lifetime of that object.  Biased locking  
> maintains state in the header of an object which says whether it can  
> be biased or not.  The initial state is read from its the class  
> object's Klass::_prototype_header field at allocation time and is  
> written into the header word.  The biased locking startup delay works  
> by having every classes initial state be not biasable and then after  
> the delay expires they are all marked as biasable.  Every object  
> allocated after that point will be biasable.  It's definitely an  
> unsatisfying solution.

It's already some time ago I looked at the biased-locking code... is it
possible at all to revoke contented locks (or CAS-based locks) to be
biasable?  If yes, is the "not-biasable" state different to CAS-based
locks?

- Christian



From linuxhippy at gmail.com  Tue Jan  6 11:54:13 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 6 Jan 2009 20:54:13 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231267616.3075.27.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
Message-ID: <194f62550901061154j6dafd368k2f88258110a29f87@mail.gmail.com>

>  It's definitely an unsatisfying solution.
Well, at least in my case it is - eliminating the possibility to
benefit of biased locking at all :-/
Are there ideas how the current behaviour could be changed to remove
that restriction while not negativly influcencing startup?

Thanks, Clemens


From Thomas.Rodriguez at Sun.COM  Tue Jan  6 15:27:11 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Tue, 06 Jan 2009 15:27:11 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231267616.3075.27.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
Message-ID: <578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>

> It's already some time ago I looked at the biased-locking code... is  
> it
> possible at all to revoke contented locks (or CAS-based locks) to be
> biasable?  If yes, is the "not-biasable" state different to CAS-based
> lock?

It's been a while for me too so my answers aren't the final word but I  
don't think there's any implementation reason why a previously  
unbiasable object couldn't be converted back to a biasable one.  I  
think it's mainly a matter of policy and performance.  The better  
solution would be to remove the startup delay all together but I don't  
think anyone has a good idea one what it would take to do that.  The  
original decision was motivated by not allowing any regression, not  
matter how small, in the startup benchmarks.  It's possible it's not a  
big deal now but I don't think anyone has done the investigation to  
know one way or another.

tom

>
>
> - Christian
>



From Thomas.Rodriguez at Sun.COM  Tue Jan  6 15:51:57 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Tue, 06 Jan 2009 15:51:57 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <194f62550901061154j6dafd368k2f88258110a29f87@mail.gmail.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<194f62550901061154j6dafd368k2f88258110a29f87@mail.gmail.com>
Message-ID: <5062754A-9489-42DF-9E22-856BE791F2D3@sun.com>


On Jan 6, 2009, at 11:54 AM, Clemens Eisserer wrote:

>> It's definitely an unsatisfying solution.
> Well, at least in my case it is - eliminating the possibility to
> benefit of biased locking at all :-/
> Are there ideas how the current behaviour could be changed to remove
> that restriction while not negativly influcencing startup?

I think we'd need to revisit the reason for the startup delay in the  
first place.  It's possible that other changes in biased locking have  
reduced or eliminated the penalty that the startup delay attempts to  
work around.  No one is currently looking at it and I don't believe  
our startup benchmarks are open source so external developers can't  
really run them to investigate it.  So it's a warm body problem  
tangled with some process problems.

Maybe, as I think Christian was implying, some mechanism to take  
unbiasable objects that turn out to be accessed by a single thread and  
convert them into biasable objects would be a good technical  
solution.  The basic machinery of biased locking is very much complete  
but there a still some unanswered questions policy wise that might  
result in better performance.  It would require a lot of investigation  
on someone's part though.

tom


From christian.thalinger at gmail.com  Thu Jan  8 02:41:40 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 11:41:40 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
Message-ID: <1231411300.16494.42.camel@localhost.localdomain>

On Tue, 2009-01-06 at 15:27 -0800, Tom Rodriguez wrote:
> It's been a while for me too so my answers aren't the final word but I  
> don't think there's any implementation reason why a previously  
> unbiasable object couldn't be converted back to a biasable one.  I  
> think it's mainly a matter of policy and performance.  The better  
> solution would be to remove the startup delay all together but I don't  
> think anyone has a good idea one what it would take to do that.  The  
> original decision was motivated by not allowing any regression, not  
> matter how small, in the startup benchmarks.  It's possible it's not a  
> big deal now but I don't think anyone has done the investigation to  
> know one way or another.

Have there been any regressions back then?  Or was the delay added
conservatively?

- Christian



From Thomas.Rodriguez at Sun.COM  Thu Jan  8 10:11:49 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 08 Jan 2009 10:11:49 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231411300.16494.42.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
Message-ID: <6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>

It was definitely done as a result of benchmarking and there were  
definitely regressions.  I don't have any information about which  
benchmarks showed problems though.  I think it was done early enough  
that other changes and improvements to biased locking might have  
helped.  Maybe that's just wishful thinking on my part.

tom

On Jan 8, 2009, at 2:41 AM, Christian Thalinger wrote:

> On Tue, 2009-01-06 at 15:27 -0800, Tom Rodriguez wrote:
>> It's been a while for me too so my answers aren't the final word  
>> but I
>> don't think there's any implementation reason why a previously
>> unbiasable object couldn't be converted back to a biasable one.  I
>> think it's mainly a matter of policy and performance.  The better
>> solution would be to remove the startup delay all together but I  
>> don't
>> think anyone has a good idea one what it would take to do that.  The
>> original decision was motivated by not allowing any regression, not
>> matter how small, in the startup benchmarks.  It's possible it's  
>> not a
>> big deal now but I don't think anyone has done the investigation to
>> know one way or another.
>
> Have there been any regressions back then?  Or was the delay added
> conservatively?
>
> - Christian
>



From christian.thalinger at gmail.com  Thu Jan  8 10:24:23 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 19:24:23 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
Message-ID: <1231439063.16494.66.camel@localhost.localdomain>

On Thu, 2009-01-08 at 10:11 -0800, Tom Rodriguez wrote:
> It was definitely done as a result of benchmarking and there were  
> definitely regressions.  I don't have any information about which  
> benchmarks showed problems though.  I think it was done early enough  
> that other changes and improvements to biased locking might have  
> helped.  Maybe that's just wishful thinking on my part.

I try to have a look at it.  Does setting BiasedLockingStartupDelay=0
use biased locking for all locks?  I'm not sure:

$ gamma -XX:+TraceBiasedLocking -XX:BiasedLockingStartupDelay=0 x
VM option '+TraceBiasedLocking'
VM option 'BiasedLockingStartupDelay=0'
Aligned thread 0x0000000000446418 to 0x0000000000446800
Aligned thread 0x0000000000453fc8 to 0x0000000000454000
Aligned thread 0x0000000000455d18 to 0x0000000000456000
Aligned thread 0x0000000000597968 to 0x0000000000598000
Aligned thread 0x000000000059d448 to 0x000000000059d800
Aligned thread 0x000000000059f658 to 0x000000000059f800
Aligned thread 0x00000000005d5688 to 0x00000000005d5800
Aligned thread 0x00000000005d7f08 to 0x00000000005d8000
Aligned thread 0x00000000005db198 to 0x00000000005db800
Aligned thread 0x00000000005df558 to 0x00000000005df800
Biased locking enabled
Aligned thread 0x00000000005eb5a8 to 0x00000000005eb800
Exception in thread "main" java.lang.NoClassDefFoundError: x
Caused by: java.lang.ClassNotFoundException: x
	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)

- Christian



From Vladimir.Kozlov at Sun.COM  Thu Jan  8 10:59:33 2009
From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov)
Date: Thu, 08 Jan 2009 10:59:33 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
Message-ID: <49664D15.70800@sun.com>

It was volano benchmark and startup benchmarks set.
For example, the regression for NetBeans startup was about 50%.

Vladimir

Tom Rodriguez wrote:
> It was definitely done as a result of benchmarking and there were 
> definitely regressions.  I don't have any information about which 
> benchmarks showed problems though.  I think it was done early enough 
> that other changes and improvements to biased locking might have 
> helped.  Maybe that's just wishful thinking on my part.
> 
> tom
> 
> On Jan 8, 2009, at 2:41 AM, Christian Thalinger wrote:
> 
>> On Tue, 2009-01-06 at 15:27 -0800, Tom Rodriguez wrote:
>>> It's been a while for me too so my answers aren't the final word but I
>>> don't think there's any implementation reason why a previously
>>> unbiasable object couldn't be converted back to a biasable one.  I
>>> think it's mainly a matter of policy and performance.  The better
>>> solution would be to remove the startup delay all together but I don't
>>> think anyone has a good idea one what it would take to do that.  The
>>> original decision was motivated by not allowing any regression, not
>>> matter how small, in the startup benchmarks.  It's possible it's not a
>>> big deal now but I don't think anyone has done the investigation to
>>> know one way or another.
>>
>> Have there been any regressions back then?  Or was the delay added
>> conservatively?
>>
>> - Christian
>>
> 


From Thomas.Rodriguez at Sun.COM  Thu Jan  8 11:06:57 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 08 Jan 2009 11:06:57 -0800
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231439063.16494.66.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
	<1231439063.16494.66.camel@localhost.localdomain>
Message-ID: <29067AB7-D2D8-4684-9BEB-33CE8A8A808E@Sun.COM>

The delay is actually a timeout for a periodic one-shot task so I  
don't think it triggers until the initial jvm bootstrap finishes.  It  
before main runs though so it should get everything interesting.  A  
absolutely accurate comparison would require modifying the VM.

tom

On Jan 8, 2009, at 10:24 AM, Christian Thalinger wrote:

> On Thu, 2009-01-08 at 10:11 -0800, Tom Rodriguez wrote:
>> It was definitely done as a result of benchmarking and there were
>> definitely regressions.  I don't have any information about which
>> benchmarks showed problems though.  I think it was done early enough
>> that other changes and improvements to biased locking might have
>> helped.  Maybe that's just wishful thinking on my part.
>
> I try to have a look at it.  Does setting BiasedLockingStartupDelay=0
> use biased locking for all locks?  I'm not sure:
>
> $ gamma -XX:+TraceBiasedLocking -XX:BiasedLockingStartupDelay=0 x
> VM option '+TraceBiasedLocking'
> VM option 'BiasedLockingStartupDelay=0'
> Aligned thread 0x0000000000446418 to 0x0000000000446800
> Aligned thread 0x0000000000453fc8 to 0x0000000000454000
> Aligned thread 0x0000000000455d18 to 0x0000000000456000
> Aligned thread 0x0000000000597968 to 0x0000000000598000
> Aligned thread 0x000000000059d448 to 0x000000000059d800
> Aligned thread 0x000000000059f658 to 0x000000000059f800
> Aligned thread 0x00000000005d5688 to 0x00000000005d5800
> Aligned thread 0x00000000005d7f08 to 0x00000000005d8000
> Aligned thread 0x00000000005db198 to 0x00000000005db800
> Aligned thread 0x00000000005df558 to 0x00000000005df800
> Biased locking enabled
> Aligned thread 0x00000000005eb5a8 to 0x00000000005eb800
> Exception in thread "main" java.lang.NoClassDefFoundError: x
> Caused by: java.lang.ClassNotFoundException: x
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
>
> - Christian
>



From christian.thalinger at gmail.com  Thu Jan  8 11:39:12 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 20:39:12 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <29067AB7-D2D8-4684-9BEB-33CE8A8A808E@Sun.COM>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
	<1231439063.16494.66.camel@localhost.localdomain>
	<29067AB7-D2D8-4684-9BEB-33CE8A8A808E@Sun.COM>
Message-ID: <1231443552.16494.120.camel@localhost.localdomain>

On Thu, 2009-01-08 at 11:06 -0800, Tom Rodriguez wrote:
> The delay is actually a timeout for a periodic one-shot task so I  
> don't think it triggers until the initial jvm bootstrap finishes.  It  
> before main runs though so it should get everything interesting.  A  
> absolutely accurate comparison would require modifying the VM.

When using zero as timeout, BiasedLocking::init() instantiates
VM_EnableBiasedLocking right away without using the one-shot task:

    if (BiasedLockingStartupDelay > 0) {
      EnableBiasedLockingTask* task = new EnableBiasedLockingTask(BiasedLockingStartupDelay);
      task->enroll();
    } else {
      VM_EnableBiasedLocking op(false);
      VMThread::execute(&op);
    }

But the BiasedLocking::init() call is almost the last call in
Thread::create_vm().  So, some locks may have already been created.  But
this is just a guess.

- Christian



From christian.thalinger at gmail.com  Thu Jan  8 11:52:58 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 20:52:58 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <49664D15.70800@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM> <49664D15.70800@sun.com>
Message-ID: <1231444378.16494.134.camel@localhost.localdomain>

On Thu, 2009-01-08 at 10:59 -0800, Vladimir Kozlov wrote:
> It was volano benchmark and startup benchmarks set.
> For example, the regression for NetBeans startup was about 50%.

Wow!  50% is a lot.  I wonder what happens that the slowdown is that
big.

- Christian



From mcneill at streambase.com  Thu Jan  8 12:22:43 2009
From: mcneill at streambase.com (Keith McNeill)
Date: Thu, 08 Jan 2009 15:22:43 -0500
Subject: deadlock with jni NewDirectByteBuffer called from multiple threads
	introduced in JDK 1.6.0_04
Message-ID: <49666093.6080802@streambase.com>

Our software has a C++ network layer using a large java runtime via 
JNI.  When new clients connect to our server we make some 
NewDirectByteBuffer calls so that we can pass data from the c++ network 
layer to the the java runtime system.   We use the JVM invocation JNI 
interface (i.e. we startup with our own exe rather than java.exe).  This 
same basic setup has been running for several years.

We have recently found that we can get what appears to be deadlock 
within calls to NewDirectByteBuffer.   Debugging we can see multiple 
threads down in the guts of NewDirectByteBuffer blocked.    Once the 
deadlock occurs the JVM is hosed.  We can't get stack dumps from it, 
can't do anything with it. 
This problem is complicated to reproduce but we can do it reliably.
We have been able to reproduce this with JDK 1.6.0_04 through JDK 
1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03 down 
through JDK 1.5.

Any suggestions on the best way to debug this JDK problem?

Keith




From David.Holmes at Sun.COM  Thu Jan  8 14:27:46 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 09 Jan 2009 08:27:46 +1000
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231444378.16494.134.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM> <49664D15.70800@sun.com>
	<1231444378.16494.134.camel@localhost.localdomain>
Message-ID: <49667DE2.9080303@sun.com>

Christian Thalinger said the following on 01/09/09 05:52:
> On Thu, 2009-01-08 at 10:59 -0800, Vladimir Kozlov wrote:
>> It was volano benchmark and startup benchmarks set.
>> For example, the regression for NetBeans startup was about 50%.
> 
> Wow!  50% is a lot.  I wonder what happens that the slowdown is that
> big.

During startup a lot of locks get touched by many threads so a lot of 
bias revocation occurs and that requires a safepoint each time. So 
basically the system spends a lot of time at safepoints and that adds a 
lot of overhead.

Also note, as I understand from work I did late in the Java 6 cycle, 
once an object has its biased revoked it remains revoked ie it will not 
participate in biased-locking again. This was done to prevent 
"thrashing" and it also makes things easier to reason about.

David Holmes


From David.Holmes at Sun.COM  Thu Jan  8 14:46:05 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 09 Jan 2009 08:46:05 +1000
Subject: deadlock with jni NewDirectByteBuffer called from multiple threads
	introduced in JDK 1.6.0_04
In-Reply-To: <49666093.6080802@streambase.com>
References: <49666093.6080802@streambase.com>
Message-ID: <4966822D.3080300@sun.com>

Hi Keith,

What platform are you on? Can you see where threads block inside 
NewDirectByteBuffer?

On Solaris pstack would show you what state the process in. I think 
linux has similar functionality, but don't know about Windows.

David Holmes

Keith McNeill said the following on 01/09/09 06:22:
> Our software has a C++ network layer using a large java runtime via 
> JNI.  When new clients connect to our server we make some 
> NewDirectByteBuffer calls so that we can pass data from the c++ network 
> layer to the the java runtime system.   We use the JVM invocation JNI 
> interface (i.e. we startup with our own exe rather than java.exe).  This 
> same basic setup has been running for several years.
> 
> We have recently found that we can get what appears to be deadlock 
> within calls to NewDirectByteBuffer.   Debugging we can see multiple 
> threads down in the guts of NewDirectByteBuffer blocked.    Once the 
> deadlock occurs the JVM is hosed.  We can't get stack dumps from it, 
> can't do anything with it. This problem is complicated to reproduce but 
> we can do it reliably.
> We have been able to reproduce this with JDK 1.6.0_04 through JDK 
> 1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03 down 
> through JDK 1.5.
> 
> Any suggestions on the best way to debug this JDK problem?
> 
> Keith
> 
> 


From mcneill at streambase.com  Thu Jan  8 15:15:52 2009
From: mcneill at streambase.com (Keith McNeill)
Date: Thu, 08 Jan 2009 18:15:52 -0500
Subject: deadlock with jni NewDirectByteBuffer called from multiple threads
	introduced in JDK 1.6.0_04
In-Reply-To: <4966822D.3080300@sun.com>
References: <49666093.6080802@streambase.com> <4966822D.3080300@sun.com>
Message-ID: <49668928.7050606@streambase.com>

Here is a gdb stack dump from linux64.  Look for NewDirectByteBuffer to 
find the calls.

David Holmes - Sun Microsystems wrote:
> Hi Keith,
>
> What platform are you on? Can you see where threads block inside 
> NewDirectByteBuffer?
>
> On Solaris pstack would show you what state the process in. I think 
> linux has similar functionality, but don't know about Windows.
>
> David Holmes
>
> Keith McNeill said the following on 01/09/09 06:22:
>> Our software has a C++ network layer using a large java runtime via 
>> JNI.  When new clients connect to our server we make some 
>> NewDirectByteBuffer calls so that we can pass data from the c++ 
>> network layer to the the java runtime system.   We use the JVM 
>> invocation JNI interface (i.e. we startup with our own exe rather 
>> than java.exe).  This same basic setup has been running for several 
>> years.
>>
>> We have recently found that we can get what appears to be deadlock 
>> within calls to NewDirectByteBuffer.   Debugging we can see multiple 
>> threads down in the guts of NewDirectByteBuffer blocked.    Once the 
>> deadlock occurs the JVM is hosed.  We can't get stack dumps from it, 
>> can't do anything with it. This problem is complicated to reproduce 
>> but we can do it reliably.
>> We have been able to reproduce this with JDK 1.6.0_04 through JDK 
>> 1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03 down 
>> through JDK 1.5.
>>
>> Any suggestions on the best way to debug this JDK problem?
>>
>> Keith
>>
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stack.txt
Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090108/5e4a5e14/attachment.txt 

From christian.thalinger at gmail.com  Thu Jan  8 15:33:03 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Fri, 09 Jan 2009 00:33:03 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <49667DE2.9080303@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM> <49664D15.70800@sun.com>
	<1231444378.16494.134.camel@localhost.localdomain>
	<49667DE2.9080303@sun.com>
Message-ID: <1231457583.16494.188.camel@localhost.localdomain>

On Fri, 2009-01-09 at 08:27 +1000, David Holmes - Sun Microsystems
wrote:
> During startup a lot of locks get touched by many threads so a lot of 
> bias revocation occurs and that requires a safepoint each time. So 
> basically the system spends a lot of time at safepoints and that adds a 
> lot of overhead.
> 
> Also note, as I understand from work I did late in the Java 6 cycle, 
> once an object has its biased revoked it remains revoked ie it will not 
> participate in biased-locking again. This was done to prevent 
> "thrashing" and it also makes things easier to reason about.

Looking at bulk_revoke_or_rebias_at_safepoint(), it seems you're right.
Even worse.  All future instances of a class cannot use biased locking,
as this comment states:

    // Disable biased locking for this data type. Not only will this
    // cause future instances to not be biased, but existing biased
    // instances will notice that this implicitly caused their biases
    // to be revoked.

Or am I wrong?

- Christian



From Thomas.Rodriguez at Sun.COM  Thu Jan  8 15:39:08 2009
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 08 Jan 2009 15:39:08 -0800
Subject: deadlock with jni NewDirectByteBuffer called from multiple threads
	introduced in JDK 1.6.0_04
In-Reply-To: <49668928.7050606@streambase.com>
References: <49666093.6080802@streambase.com> <4966822D.3080300@sun.com>
	<49668928.7050606@streambase.com>
Message-ID: <A5268EB9-181E-4D8B-A3EF-E7BDD9D730F7@sun.com>

It looks to me like initializeDirectBufferSupport doesn't respect our  
normal rules for blocking with safepoint checks.  If another thread  
gets in there first the other threads can block in here:

} else {
     ThreadInVMfromNative tivn(thread); // set state as yield_all can  
call os:sleep
     while (!directBufferSupportInitializeEnded && ! 
directBufferSupportInitializeFailed) {
       os::yield_all();
     }
   }

Thread 4 below is inside lookupDirectBufferClasses and has induced a  
safepoint to invalidate some code but some of the threads are in the  
loop above which doesn't include any safepoint checks so the whole  
thing will deadlock, unable to come to a safepoint.  You could  
workaround this if you force the loading of the DirectBuffer classes  
before this code executes.

I think initializeDirectBufferSupport would work better if the VM  
transition was inside the yield_all loop so that we repeatedly checked  
for safepoints.  The comment there says the transition is needed for  
the yield_all call but I'm not sure that's true.  Removing the  
transition completely would allow it to work as well since we'd be in  
native and the safepointing logic would consider the thread stopped.   
Anyway, it does look like a bug.

tom

On Jan 8, 2009, at 3:15 PM, Keith McNeill wrote:

> Here is a gdb stack dump from linux64.  Look for NewDirectByteBuffer  
> to find the calls.
>
> David Holmes - Sun Microsystems wrote:
>> Hi Keith,
>>
>> What platform are you on? Can you see where threads block inside  
>> NewDirectByteBuffer?
>>
>> On Solaris pstack would show you what state the process in. I think  
>> linux has similar functionality, but don't know about Windows.
>>
>> David Holmes
>>
>> Keith McNeill said the following on 01/09/09 06:22:
>>> Our software has a C++ network layer using a large java runtime  
>>> via JNI.  When new clients connect to our server we make some  
>>> NewDirectByteBuffer calls so that we can pass data from the c++  
>>> network layer to the the java runtime system.   We use the JVM  
>>> invocation JNI interface (i.e. we startup with our own exe rather  
>>> than java.exe).  This same basic setup has been running for  
>>> several years.
>>>
>>> We have recently found that we can get what appears to be deadlock  
>>> within calls to NewDirectByteBuffer.   Debugging we can see  
>>> multiple threads down in the guts of NewDirectByteBuffer  
>>> blocked.    Once the deadlock occurs the JVM is hosed.  We can't  
>>> get stack dumps from it, can't do anything with it. This problem  
>>> is complicated to reproduce but we can do it reliably.
>>> We have been able to reproduce this with JDK 1.6.0_04 through JDK  
>>> 1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03  
>>> down through JDK 1.5.
>>>
>>> Any suggestions on the best way to debug this JDK problem?
>>>
>>> Keith
>>>
>>>
> GNU gdb Red Hat Linux (6.3.0.0-1.63rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and  
> you are
> welcome to change it and/or distribute copies of it under certain  
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for  
> details.
> This GDB was configured as "x86_64-redhat-linux-gnu"...Using host  
> libthread_db library "/lib64/tls/libthread_db.so.1".
>
> Attaching to program: /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/bin/sbd, process 6476
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/jdk/jre/lib/amd64/libzip.so...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/jdk/jre/lib/amd64/libzip.so
> Reading symbols from /lib64/libdl.so.2...done.
> Loaded symbols for /lib64/libdl.so.2
> Reading symbols from /lib64/libnsl.so.1...done.
> Loaded symbols for /lib64/libnsl.so.1
> Reading symbols from /usr/lib64/libz.so.1...done.
> Loaded symbols for /usr/lib64/libz.so.1
> Reading symbols from /lib64/tls/libpthread.so.0...done.
> [Thread debugging using libthread_db enabled]
> [New Thread 182915427360 (LWP 6476)]
> [New Thread 1104243040 (LWP 6509)]
> [New Thread 1102141792 (LWP 6508)]
> [New Thread 1100040544 (LWP 6507)]
> [New Thread 1097939296 (LWP 6496)]
> [New Thread 1095838048 (LWP 6495)]
> [New Thread 1094785376 (LWP 6494)]
> [New Thread 1093732704 (LWP 6493)]
> [New Thread 1092680032 (LWP 6492)]
> [New Thread 1091627360 (LWP 6491)]
> [New Thread 1090574688 (LWP 6490)]
> [New Thread 1089522016 (LWP 6489)]
> [New Thread 1087420768 (LWP 6488)]
> [New Thread 1085319520 (LWP 6487)]
> [New Thread 1084266848 (LWP 6486)]
> [New Thread 1083214176 (LWP 6485)]
> [New Thread 1082161504 (LWP 6484)]
> [New Thread 1081108832 (LWP 6483)]
> [New Thread 1080056160 (LWP 6482)]
> [New Thread 1079003488 (LWP 6481)]
> [New Thread 1077950816 (LWP 6480)]
> [New Thread 1076898144 (LWP 6479)]
> [New Thread 1075845472 (LWP 6478)]
> [New Thread 1074792800 (LWP 6477)]
> Loaded symbols for /lib64/tls/libpthread.so.0
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/lib64/libsbserver.so.8...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/bin/../lib64/libsbserver.so.8
> Reading symbols from /usr/lib64/libstdc++.so.6...done.
> Loaded symbols for /usr/lib64/libstdc++.so.6
> Reading symbols from /lib64/tls/libm.so.6...done.
> Loaded symbols for /lib64/tls/libm.so.6
> Reading symbols from /lib64/tls/libc.so.6...done.
> Loaded symbols for /lib64/tls/libc.so.6
> Reading symbols from /lib64/libgcc_s.so.1...done.
> Loaded symbols for /lib64/libgcc_s.so.1
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/jdk/jre/lib/amd64/server/libjvm.so...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/jdk/jre/lib/amd64/server/libjvm.so
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/jdk/jre/lib/amd64/libjava.so...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/jdk/jre/lib/amd64/libjava.so
> Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/jdk/jre/lib/amd64/libverify.so...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/jdk/jre/lib/amd64/libverify.so
> Reading symbols from /lib64/libnss_files.so.2...done.
> Loaded symbols for /lib64/libnss_files.so.2
> Reading symbols from /lib64/tls/librt.so.1...done.
> Loaded symbols for /lib64/tls/librt.so.1
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/jdk/jre/lib/amd64/native_threads/libhpi.so...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/jdk/jre/lib/amd64/native_threads/libhpi.so
> Reading symbols from /lib64/libnss_hesiod.so.2...done.
> Loaded symbols for /lib64/libnss_hesiod.so.2
> Reading symbols from /lib64/libresolv.so.2...done.
> Loaded symbols for /lib64/libresolv.so.2
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/lib64/libsbserverrt.so.8.0.0...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/lib64/libsbserverrt.so.8.0.0
> Reading symbols from /mnt/local/home/campbell/sandboxes/hynes/ 
> install/streambase/jdk/jre/lib/amd64/libnet.so...done.
> Loaded symbols for /mnt/local/home/campbell/sandboxes/hynes/install/ 
> streambase/jdk/jre/lib/amd64/libnet.so
> 0x00000038e1206f2b in pthread_join () from /lib64/tls/libpthread.so.0
> (gdb) (gdb)
> Thread 24 (Thread 1074792800 (LWP 6477)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c7e2 in Monitor::IWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cfae in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a96124c15 in GCTaskManager::get_task ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a96125ec3 in GCTaskThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #8  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #9  0x0000000000000000 in ?? ()
>
> Thread 23 (Thread 1075845472 (LWP 6478)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c7e2 in Monitor::IWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cfae in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a96124c15 in GCTaskManager::get_task ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a96125ec3 in GCTaskThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #8  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #9  0x0000000000000000 in ?? ()
>
> Thread 22 (Thread 1076898144 (LWP 6479)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c7e2 in Monitor::IWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cfae in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963ab8ad in SafepointSynchronize::begin ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a9646e2c8 in VMThread::loop ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a9646ddce in VMThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #9  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #10 0x0000000000000000 in ?? ()
>
> Thread 21 (Thread 1077950816 (LWP 6480)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a963f39ba in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a96d2e852 in ?? ()
> #6  0x00000000404029b8 in ?? ()
> #7  0x00000000005abc00 in ?? ()
> #8  0x0000000040402890 in ?? ()
> #9  0x0000000040402868 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> Thread 20 (Thread 1079003488 (LWP 6481)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a963f39ba in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a96d2e852 in ?? ()
> #6  0x0000000040503c08 in ?? ()
> #7  0x00000000005ad800 in ?? ()
> #8  0x0000002ab6748410 in ?? ()
> #9  0x0000000040503bf8 in ?? ()
> #10 0x0000000040503b80 in ?? ()
> #11 0x0000000000000000 in ?? ()
>
> Thread 19 (Thread 1080056160 (LWP 6482)):
> #0  0x00000038e120a57f in sem_wait () from /lib64/tls/libpthread.so.0
> #1  0x0000002a96348315 in check_pending_signals ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a96341a97 in signal_thread_entry ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a964232c1 in JavaThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #6  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #7  0x0000000000000000 in ?? ()
>
> Thread 18 (Thread 1081108832 (LWP 6483)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c7e2 in Monitor::IWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632ce4a in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a960a8f93 in CompileQueue::get ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a960aaa32 in CompileBroker::compiler_thread_loop ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a964293b9 in compiler_thread_entry ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a964232c1 in JavaThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #9  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #10 0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #11 0x0000000000000000 in ?? ()
>
> Thread 17 (Thread 1082161504 (LWP 6484)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c7e2 in Monitor::IWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632ce4a in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a960a8f93 in CompileQueue::get ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a960aaa32 in CompileBroker::compiler_thread_loop ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a964293b9 in compiler_thread_entry ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a964232c1 in JavaThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #9  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #10 0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #11 0x0000000000000000 in ?? ()
>
> Thread 16 (Thread 1083214176 (LWP 6485)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c7e2 in Monitor::IWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cfae in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a962f6e62 in  
> LowMemoryDetector::low_memory_detector_thread_entry ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a964232c1 in JavaThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #8  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #9  0x0000000000000000 in ?? ()
>
> Thread 15 (Thread 1084266848 (LWP 6486)):
> #0  0x00000038e1208acf in pthread_cond_timedwait@@GLIBC_2.3.2 ()  
> from /lib64/tls/libpthread.so.0
> #1  0x0000002a96347836 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a96345abd in os::sleep ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9642251b in WatcherThread::run ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a96347f6a in java_start ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #6  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #7  0x0000000000000000 in ?? ()
>
> Thread 14 (Thread 1085319520 (LWP 6487)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a963f39ba in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a96d2e852 in ?? ()
> #6  0x00000000005fd400 in ?? ()
> #7  0x00000000005fd7d8 in ?? ()
> #8  0x0000002ac302f000 in ?? ()
> #9  0x0000000040b09828 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> Thread 13 (Thread 1087420768 (LWP 6488)):
> #0  0x00000038e1208acf in pthread_cond_timedwait@@GLIBC_2.3.2 ()  
> from /lib64/tls/libpthread.so.0
> #1  0x0000002a9586ad79 in  
> sb_internal::StreamBaseServer::runSystemMonitorThread (this=0x523fa0)
>    at nmstl/NMSTL/thread.hpp:216
> #2  0x0000002a95a0c449 in NMSTL::Thread::launch (pthis=) at nmstl/ 
> NMSTL/ptr.hpp:346
> #3  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #4  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #5  0x0000000000000000 in ?? ()
>
> Thread 12 (Thread 1089522016 (LWP 6489)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a958646b3 in  
> sb_internal::StreamBaseServer::runShutdownSignalThread (this=0x523fa0)
>    at nmstl/NMSTL/thread.hpp:205
> #2  0x0000002a95a0c449 in NMSTL::Thread::launch (pthis=) at nmstl/ 
> NMSTL/ptr.hpp:346
> #3  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #4  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #5  0x0000000000000000 in ?? ()
>
> Thread 11 (Thread 1090574688 (LWP 6490)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a963f3968 in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96d2e852 in ?? ()
> #9  0x0000002a99ea7968 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> Thread 10 (Thread 1091627360 (LWP 6491)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a963f3968 in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96d2e852 in ?? ()
> #9  0x0000002ab5a4f910 in ?? ()
> #10 0x000000004110dc90 in ?? ()
> #11 0x000000004110dc70 in ?? ()
> #12 0x000000004110dc18 in ?? ()
> #13 0x0000000000000000 in ?? ()
>
> Thread 9 (Thread 1092680032 (LWP 6492)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a963f3968 in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96d2e852 in ?? ()
> #9  0x000000004966879d in ?? ()
> #10 0x00000000000f020e in ?? ()
> #11 0x0000011eb881c11f in ?? ()
> #12 0x000000004120eb38 in ?? ()
> #13 0x0000000000000000 in ?? ()
>
> Thread 8 (Thread 1093732704 (LWP 6493)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a963f3968 in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96d2e852 in ?? ()
> #9  0x0000000049668799 in ?? ()
> #10 0x00000000000ece86 in ?? ()
> #11 0x0000011eb881b172 in ?? ()
> #12 0x0000002a961ddd27 in JVM_CurrentTimeMillis ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #13 0x0000002a96d23322 in ?? ()
> #14 0x0000000000000000 in ?? ()
>
> Thread 7 (Thread 1094785376 (LWP 6494)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a963f3968 in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96d2e852 in ?? ()
> #9  0x0000002a99ea7968 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> Thread 6 (Thread 1095838048 (LWP 6495)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a963f3968 in ObjectMonitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a963f0f43 in ObjectSynchronizer::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a961df9bb in JVM_MonitorWait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a96d2e852 in ?? ()
> #9  0x0000002ab5cfba30 in ?? ()
> #10 0x0000000041511a90 in ?? ()
> #11 0x0000000041511a70 in ?? ()
> #12 0x0000000041511a18 in ?? ()
> #13 0x0000000000000000 in ?? ()
>
> Thread 5 (Thread 1097939296 (LWP 6496)):
> #0  0x00000038e120b2ef in __accept_nocancel () from /lib64/tls/ 
> libpthread.so.0
> #1  0x0000002a95a234ed in NMSTL::Socket::accept (this=0x523fb0,  
> a=@0x41712f90)
>    at nmstl/NMSTL/io.hpp:537
> #2  0x0000002a95a14757 in NMSTL::TServerBase::run (this=0x523fa0) at  
> nmstl/tserver.cpp:160
> #3  0x0000002a95a0c449 in NMSTL::Thread::launch (pthis=) at nmstl/ 
> NMSTL/ptr.hpp:346
> #4  0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #5  0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #6  0x0000000000000000 in ?? ()
>
> Thread 4 (Thread 1100040544 (LWP 6507)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a963abf3a in SafepointSynchronize::block ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a9632cf68 in Monitor::wait ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #6  0x0000002a9646e8d9 in VMThread::execute ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #7  0x0000002a9643d83d in Universe::flush_dependents_on ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #8  0x0000002a963f8fdf in SystemDictionary::define_instance_class ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #9  0x0000002a963f9477 in  
> SystemDictionary::find_or_define_instance_class ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #10 0x0000002a963f8b61 in SystemDictionary::load_instance_class ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #11 0x0000002a963f75b2 in  
> SystemDictionary::resolve_instance_class_or_null ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #12 0x0000002a963f64b1 in SystemDictionary::resolve_or_null ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #13 0x0000002a963f6143 in SystemDictionary::resolve_or_fail ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #14 0x0000002a961f9a99 in find_class_from_class_loader ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #15 0x0000002a961af94c in lookupOne ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #16 0x0000002a961ae137 in lookupDirectBufferClasses ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #17 0x0000002a961afb08 in initializeDirectBufferSupport ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #18 0x0000002a961ae2c2 in jni_NewDirectByteBuffer ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #19 0x0000002a95857387 in  
> sb_internal::DirectBufferRef::DirectBufferRef ()
>    at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/ 
> 3.4.6/bits/stl_tree.h:1227
> #20 0x0000002a958576d9 in sb_internal::JavaIOBuffer::reserveCapacity  
> (this=)
>    at runtime/IOBuffer.hpp:24
> #21 0x0000002a958955c4 in  
> sb_internal::StreamBaseClientHandler::reserveIOBufferCapacity (
>    this=0x2ac44ebe80, buffer={cnt = 0x2ac3029b60, rep =  
> 0x2ac3035c70}, newSize=)
>    at nmstl/NMSTL/ptr.hpp:346
> #22 0x0000002a9589571c in  
> sb_internal::StreamBaseClientHandler::newIOBuffer (this=0x2ac44ebe80,
>    initial_size=1024) at nmstl/NMSTL/atomic.hpp:98
> #23 0x0000002a9589d71b in  
> sb_internal::StreamBaseClientHandler::doRun (this=0x2ac44ebe80)
>    at runtime/StreamBaseClientHandler.cpp:225
> #24 0x0000002a958a075a in sb_internal::StreamBaseClientHandler::run  
> (this=0x2ac44ebe80)
>    at runtime/StreamBaseClientHandler.cpp:189
> #25 0x0000002a95870488 in  
> sb_internal::StreamBaseServer::MyConnection::handleRequest (
>    this=0x999710, req=) at nmstl/NMSTL/ptr.hpp:339
> #26 0x0000002a9599849f in sb_internal::HTTPConnection::run  
> (this=0x999710)
>    at util/HTTPServer.cpp:123
> #27 0x0000002a95a168f3 in NMSTL::TServerBase::ConnectionRunner::run  
> (this=0x83c340)
>    at nmstl/NMSTL/ptr.hpp:346
> #28 0x0000002a95a0c449 in NMSTL::Thread::launch (pthis=) at nmstl/ 
> NMSTL/ptr.hpp:346
> #29 0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #30 0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #31 0x0000000000000000 in ?? ()
>
> Thread 3 (Thread 1102141792 (LWP 6508)):
> #0  0x00000038e05ae7c9 in sched_yield () from /lib64/tls/libc.so.6
> #1  0x0000002a96345b59 in os::yield_all ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a961afa27 in initializeDirectBufferSupport ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a961ae2c2 in jni_NewDirectByteBuffer ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a95857387 in  
> sb_internal::DirectBufferRef::DirectBufferRef ()
>    at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/ 
> 3.4.6/bits/stl_tree.h:1227
> #5  0x0000002a958576d9 in sb_internal::JavaIOBuffer::reserveCapacity  
> (this=)
>    at runtime/IOBuffer.hpp:24
> #6  0x0000002a958955c4 in  
> sb_internal::StreamBaseClientHandler::reserveIOBufferCapacity (
>    this=0x2ac30d6900, buffer={cnt = 0x123c5c0, rep = 0x123c580},  
> newSize=)
>    at nmstl/NMSTL/ptr.hpp:346
> #7  0x0000002a9589571c in  
> sb_internal::StreamBaseClientHandler::newIOBuffer (this=0x2ac30d6900,
>    initial_size=1024) at nmstl/NMSTL/atomic.hpp:98
> #8  0x0000002a9589d71b in  
> sb_internal::StreamBaseClientHandler::doRun (this=0x2ac30d6900)
>    at runtime/StreamBaseClientHandler.cpp:225
> #9  0x0000002a958a075a in sb_internal::StreamBaseClientHandler::run  
> (this=0x2ac30d6900)
>    at runtime/StreamBaseClientHandler.cpp:189
> #10 0x0000002a95870488 in  
> sb_internal::StreamBaseServer::MyConnection::handleRequest (
>    this=0x683cf0, req=) at nmstl/NMSTL/ptr.hpp:339
> #11 0x0000002a9599849f in sb_internal::HTTPConnection::run  
> (this=0x683cf0)
>    at util/HTTPServer.cpp:123
> #12 0x0000002a95a168f3 in NMSTL::TServerBase::ConnectionRunner::run  
> (this=0x176e350)
>    at nmstl/NMSTL/ptr.hpp:346
> #13 0x0000002a95a0c449 in NMSTL::Thread::launch (pthis=) at nmstl/ 
> NMSTL/ptr.hpp:346
> #14 0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #15 0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #16 0x0000000000000000 in ?? ()
>
> Thread 2 (Thread 1104243040 (LWP 6509)):
> #0  0x00000038e12088da in pthread_cond_wait@@GLIBC_2.3.2 () from / 
> lib64/tls/libpthread.so.0
> #1  0x0000002a963476e7 in os::PlatformEvent::park ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #2  0x0000002a9632c449 in Monitor::ILock ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #3  0x0000002a9632cb80 in Monitor::lock_without_safepoint_check ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #4  0x0000002a961afcee in attach_current_thread ()
>   from /mnt/local/home/campbell/sandboxes/hynes/install/streambase/ 
> jdk/jre/lib/amd64/server/libjvm.so
> #5  0x0000002a95852637 in Context (this=)
>    at /usr/local/sbdeps/jdk15/jdk15-1_5_0_15-x86_64-linux/include/ 
> jni.h:1906
> #6  0x0000002a9585fb9c in sb_internal::SBEnv::getJVMEnv () at  
> runtime/SBJVM.hpp:31
> #7  0x0000002a9586da2f in  
> sb_internal::StreamBaseServer::processXmlRpcRequest (this=)
>    at runtime/StreamBaseServer.cpp:791
> #8  0x0000002a9586f1f1 in  
> sb_internal::StreamBaseServer::MyConnection::handleRequest (
>    this=0x12f1b70, req=@0x41d14f40, resp=@0x41d14fa0) at runtime/ 
> StreamBaseServer.cpp:427
> #9  0x0000002a9599849f in sb_internal::HTTPConnection::run  
> (this=0x12f1b70)
>    at util/HTTPServer.cpp:123
> #10 0x0000002a95a168f3 in NMSTL::TServerBase::ConnectionRunner::run  
> (this=0x121ae80)
>    at nmstl/NMSTL/ptr.hpp:346
> #11 0x0000002a95a0c449 in NMSTL::Thread::launch (pthis=) at nmstl/ 
> NMSTL/ptr.hpp:346
> #12 0x00000038e12060aa in start_thread () from /lib64/tls/ 
> libpthread.so.0
> #13 0x00000038e05c5b43 in clone () from /lib64/tls/libc.so.6
> #14 0x0000000000000000 in ?? ()
>
> Thread 1 (Thread 182915427360 (LWP 6476)):
> #0  0x00000038e1206f2b in pthread_join () from /lib64/tls/ 
> libpthread.so.0
> #1  0x0000002a95a0d382 in NMSTL::Thread::join (this=0x2ac44ed3d0) at  
> nmstl/thread.cpp:197
> #2  0x0000002a95a11167 in NMSTL::TServerBase::join (this=0x523fa0)  
> at nmstl/NMSTL/ptr.hpp:346
> #3  0x0000002a95869cac in sb_internal::StreamBaseServer::xRun  
> (this=0x523fa0)
>    at runtime/StreamBaseServer.cpp:364
> #4  0x000000000040adc2 in cppsbdmain (argc=) at nmstl/NMSTL/ptr.hpp: 
> 346
> #5  0x000000000040eff0 in main (argc=2, argv=0x7fbffff878) at apps/ 
> sbd.cpp:659
> (gdb) Detaching from program: /mnt/local/home/campbell/sandboxes/ 
> hynes/install/streambase/bin/sbd, process 6476



From David.Holmes at Sun.COM  Thu Jan  8 15:43:18 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 09 Jan 2009 09:43:18 +1000
Subject: Restrictions for lock coarsening?
In-Reply-To: <1231457583.16494.188.camel@localhost.localdomain>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM> <49664D15.70800@sun.com>
	<1231444378.16494.134.camel@localhost.localdomain>
	<49667DE2.9080303@sun.com>
	<1231457583.16494.188.camel@localhost.localdomain>
Message-ID: <49668F96.4050005@sun.com>

Christian Thalinger said the following on 01/09/09 09:33:
> On Fri, 2009-01-09 at 08:27 +1000, David Holmes - Sun Microsystems
> wrote:
>> Also note, as I understand from work I did late in the Java 6 cycle, 
>> once an object has its biased revoked it remains revoked ie it will not 
>> participate in biased-locking again. This was done to prevent 
>> "thrashing" and it also makes things easier to reason about.
> 
> Looking at bulk_revoke_or_rebias_at_safepoint(), it seems you're right.
> Even worse.  All future instances of a class cannot use biased locking,
> as this comment states:
> 
>     // Disable biased locking for this data type. Not only will this
>     // cause future instances to not be biased, but existing biased
>     // instances will notice that this implicitly caused their biases
>     // to be revoked.
> 
> Or am I wrong?

I read that comment the same way, but I never did get a full grip on the 
biased locking lifecycle. Perhaps a re-read of the technical 
descriptions will shed more light - see the linke to the Detlefs & 
Russell paper in Dave Dice's blog:

http://blogs.sun.com/dave/entry/biased_locking_in_hotspot

David Holmes


From David.Holmes at Sun.COM  Thu Jan  8 15:43:42 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 09 Jan 2009 09:43:42 +1000
Subject: deadlock with jni NewDirectByteBuffer called from multiple threads
	introduced in JDK 1.6.0_04
In-Reply-To: <49668928.7050606@streambase.com>
References: <49666093.6080802@streambase.com> <4966822D.3080300@sun.com>
	<49668928.7050606@streambase.com>
Message-ID: <49668FAE.2070605@sun.com>

Keith,

I can see the problem - in fact I think I was involved in the code 
change that has triggered the deadlock. :(

Two threads are concurrently try to use direct buffers and they are 
racing to initialize direct buffer support. The first thread has got the 
job of doing the initialization and is looking up classes which leads to 
one thing then another and ultimately a safepoint is requested. 
Meanwhile the other thread that lost the initialization race enters a 
polling loop waiting for the first thread to complete the initialization.

The problem is that while in this polling loop (a sched_yield() call) 
the thread is marked as ThreadInVM, which means that the VMThread will 
wait for it to reach the safepoint. As it never does anything to 
encounter the safepoint then VMThread keeps waiting; so the 
initialization thread keeps waiting, and so the second thread keeps 
waiting - deadlock.

The code change that caused this was the change of the thread's state to 
ThreadInVM. This was done because on Solaris the os::yield_all call can 
turn into an os_sleep call and that requires the thread to be 
ThreadInVM. On linux the os::yield_all call is just sched_yield and so 
the state change is not only not needed but dangerous.

I will file a bug for this immediately.

There should be a workaround however: don't have a race to initialize 
the direct buffers. If you can insert a call to create a NewDirectBuffer 
early in the apps lifetime, from one thread, then initialization will be 
able to occur with no race and this problem won't occur.

David Holmes

Keith McNeill said the following on 01/09/09 09:15:
> Here is a gdb stack dump from linux64.  Look for NewDirectByteBuffer to 
> find the calls.
> 
> David Holmes - Sun Microsystems wrote:
>> Hi Keith,
>>
>> What platform are you on? Can you see where threads block inside 
>> NewDirectByteBuffer?
>>
>> On Solaris pstack would show you what state the process in. I think 
>> linux has similar functionality, but don't know about Windows.
>>
>> David Holmes
>>
>> Keith McNeill said the following on 01/09/09 06:22:
>>> Our software has a C++ network layer using a large java runtime via 
>>> JNI.  When new clients connect to our server we make some 
>>> NewDirectByteBuffer calls so that we can pass data from the c++ 
>>> network layer to the the java runtime system.   We use the JVM 
>>> invocation JNI interface (i.e. we startup with our own exe rather 
>>> than java.exe).  This same basic setup has been running for several 
>>> years.
>>>
>>> We have recently found that we can get what appears to be deadlock 
>>> within calls to NewDirectByteBuffer.   Debugging we can see multiple 
>>> threads down in the guts of NewDirectByteBuffer blocked.    Once the 
>>> deadlock occurs the JVM is hosed.  We can't get stack dumps from it, 
>>> can't do anything with it. This problem is complicated to reproduce 
>>> but we can do it reliably.
>>> We have been able to reproduce this with JDK 1.6.0_04 through JDK 
>>> 1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03 down 
>>> through JDK 1.5.
>>>
>>> Any suggestions on the best way to debug this JDK problem?
>>>
>>> Keith
>>>
>>>


From karen.kinnear at sun.com  Thu Jan  8 15:46:52 2009
From: karen.kinnear at sun.com (karen.kinnear at sun.com)
Date: Thu, 08 Jan 2009 23:46:52 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6791656: nsk defclass0 asserts
	handles.hpp
Message-ID: <20090108234654.C3B8BD2D5@hg.openjdk.java.net>

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

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

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



From linuxhippy at gmail.com  Thu Jan  8 16:00:21 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 9 Jan 2009 01:00:21 +0100
Subject: Restrictions for lock coarsening?
In-Reply-To: <49667DE2.9080303@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM>
	<49664D15.70800@sun.com>
	<1231444378.16494.134.camel@localhost.localdomain>
	<49667DE2.9080303@sun.com>
Message-ID: <194f62550901081600s78b056d3rd0a4e16265691f88@mail.gmail.com>

> Also note, as I understand from work I did late in the Java 6 cycle, once an
> object has its biased revoked it remains revoked ie it will not participate
> in biased-locking again. This was done to prevent "thrashing" and it also
> makes things easier to reason about.

A quick-and-dirty solution would probably be a Sun-internal Api which
would allow some control over biased locking. Maybe just a method
which sets an object to a biasable state which has never been locked
before, which could be used for framework-classes where biased-locking
could be benefitial.
Another idea would be lock-profiling done by the interpreter, maybe on
a per-class basis. But I guess that would be a lot of work, and I am
not sure wether per-class is too coarse grained.

I did some analysis and it seems most swing applications access Java2D
from two different threads:
1. The EDT to draw content to the backbuffer
2. The XAWT thread to draw the back-buffer, always having the same stack-trace.

I inserted some trace-code into java2d and with netbeans I got:
Java2D accessed by different threads. Old: AWT-EventQueue-0 new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 4136
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 9665
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 5
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 15621
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 4
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 11815
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 3
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 33087
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 3

So until painting the backbuffer is not done on the EDT too, I guess a
few thousand CAS don't justify waiting on safepoints :-/
On the other side, if that would be possible to do the XAWT work on
the EDT too (which probably would conflict the gray-rect fix), all
accesses to Java2D done by swing would really be from one single
thread.

After all, my project is in a very early state of development, and
although I see great speedup with biased locking for synthetic
microbenchmarks I am not sure its woth any troubles. With real-world
workload I don't expect the locking to account for more than 2-3% of
cycles spent.

- Clemens


From Dave.Dice at Sun.COM  Thu Jan  8 16:05:46 2009
From: Dave.Dice at Sun.COM (Dave Dice)
Date: Thu, 08 Jan 2009 19:05:46 -0500
Subject: Restrictions for lock coarsening?
In-Reply-To: <49668F96.4050005@sun.com>
References: <194f62550901021724j276d659cqeeeaba8ae5776bbb@mail.gmail.com>
	<f836d9637c08.495e7e09@sun.com>
	<194f62550901030156m6661d3f5y239583280c18b5a9@mail.gmail.com>
	<90A689DA-7C82-45FE-945C-C91C2810B4BF@sun.com>
	<194f62550901041509s7b08cb93g4b9a89506ba7c655@mail.gmail.com>
	<44A87D93-AC34-4511-ADE0-6EC28C93B50C@sun.com>
	<1231264874.3075.15.camel@localhost.localdomain>
	<85ED9D8F-ACCD-4198-9103-1E7F0954F78B@Sun.COM>
	<1231267616.3075.27.camel@localhost.localdomain>
	<578A0DE9-8838-4521-92BE-AE620CEB6559@Sun.COM>
	<1231411300.16494.42.camel@localhost.localdomain>
	<6A3F2451-DD4A-4CB2-9596-BEE223663B37@Sun.COM> <49664D15.70800@sun.com>
	<1231444378.16494.134.camel@localhost.localdomain>
	<49667DE2.9080303@sun.com>
	<1231457583.16494.188.camel@localhost.localdomain>
	<49668F96.4050005@sun.com>
Message-ID: <E773D3A7-F213-4357-A8D1-20CF2B5E8DBB@sun.com>


On 2009-1-8, at 6:43 PM, David Holmes - Sun Microsystems wrote:

> Christian Thalinger said the following on 01/09/09 09:33:
>> On Fri, 2009-01-09 at 08:27 +1000, David Holmes - Sun Microsystems
>> wrote:
>>> Also note, as I understand from work I did late in the Java 6  
>>> cycle, once an object has its biased revoked it remains revoked ie  
>>> it will not participate in biased-locking again. This was done to  
>>> prevent "thrashing" and it also makes things easier to reason about.
>> Looking at bulk_revoke_or_rebias_at_safepoint(), it seems you're  
>> right.
>> Even worse.  All future instances of a class cannot use biased  
>> locking,
>> as this comment states:
>>    // Disable biased locking for this data type. Not only will this
>>    // cause future instances to not be biased, but existing biased
>>    // instances will notice that this implicitly caused their biases
>>    // to be revoked.
>> Or am I wrong?
>
> I read that comment the same way, but I never did get a full grip on  
> the biased locking lifecycle. Perhaps a re-read of the technical  
> descriptions will shed more light - see the linke to the Detlefs &  
> Russell paper in Dave Dice's blog:
>
> http://blogs.sun.com/dave/entry/biased_locking_in_hotspot
>

There's a subtle baked-in assumption in a number of places in hotspot  
that once an object has had biased revoked that it'll remain that way,  
at least over certain intervals.   That constraint could be relaxed,  
of course.

Dave



From David.Holmes at Sun.COM  Thu Jan  8 19:09:16 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 09 Jan 2009 13:09:16 +1000
Subject: deadlock with jni NewDirectByteBuffer called from multiple threads
	introduced in JDK 1.6.0_04
In-Reply-To: <49668FAE.2070605@sun.com>
References: <49666093.6080802@streambase.com> <4966822D.3080300@sun.com>
	<49668928.7050606@streambase.com> <49668FAE.2070605@sun.com>
Message-ID: <4966BFDC.3050705@sun.com>

Bug 6791815 has been filed.

David

David Holmes - Sun Microsystems said the following on 01/09/09 09:43:
> Keith,
> 
> I can see the problem - in fact I think I was involved in the code 
> change that has triggered the deadlock. :(
> 
> Two threads are concurrently try to use direct buffers and they are 
> racing to initialize direct buffer support. The first thread has got the 
> job of doing the initialization and is looking up classes which leads to 
> one thing then another and ultimately a safepoint is requested. 
> Meanwhile the other thread that lost the initialization race enters a 
> polling loop waiting for the first thread to complete the initialization.
> 
> The problem is that while in this polling loop (a sched_yield() call) 
> the thread is marked as ThreadInVM, which means that the VMThread will 
> wait for it to reach the safepoint. As it never does anything to 
> encounter the safepoint then VMThread keeps waiting; so the 
> initialization thread keeps waiting, and so the second thread keeps 
> waiting - deadlock.
> 
> The code change that caused this was the change of the thread's state to 
> ThreadInVM. This was done because on Solaris the os::yield_all call can 
> turn into an os_sleep call and that requires the thread to be 
> ThreadInVM. On linux the os::yield_all call is just sched_yield and so 
> the state change is not only not needed but dangerous.
> 
> I will file a bug for this immediately.
> 
> There should be a workaround however: don't have a race to initialize 
> the direct buffers. If you can insert a call to create a NewDirectBuffer 
> early in the apps lifetime, from one thread, then initialization will be 
> able to occur with no race and this problem won't occur.
> 
> David Holmes
> 
> Keith McNeill said the following on 01/09/09 09:15:
>> Here is a gdb stack dump from linux64.  Look for NewDirectByteBuffer 
>> to find the calls.
>>
>> David Holmes - Sun Microsystems wrote:
>>> Hi Keith,
>>>
>>> What platform are you on? Can you see where threads block inside 
>>> NewDirectByteBuffer?
>>>
>>> On Solaris pstack would show you what state the process in. I think 
>>> linux has similar functionality, but don't know about Windows.
>>>
>>> David Holmes
>>>
>>> Keith McNeill said the following on 01/09/09 06:22:
>>>> Our software has a C++ network layer using a large java runtime via 
>>>> JNI.  When new clients connect to our server we make some 
>>>> NewDirectByteBuffer calls so that we can pass data from the c++ 
>>>> network layer to the the java runtime system.   We use the JVM 
>>>> invocation JNI interface (i.e. we startup with our own exe rather 
>>>> than java.exe).  This same basic setup has been running for several 
>>>> years.
>>>>
>>>> We have recently found that we can get what appears to be deadlock 
>>>> within calls to NewDirectByteBuffer.   Debugging we can see multiple 
>>>> threads down in the guts of NewDirectByteBuffer blocked.    Once the 
>>>> deadlock occurs the JVM is hosed.  We can't get stack dumps from it, 
>>>> can't do anything with it. This problem is complicated to reproduce 
>>>> but we can do it reliably.
>>>> We have been able to reproduce this with JDK 1.6.0_04 through JDK 
>>>> 1.6.0_11.  We haven't been able to reproduce with JDK 1.6.0_03 down 
>>>> through JDK 1.5.
>>>>
>>>> Any suggestions on the best way to debug this JDK problem?
>>>>
>>>> Keith
>>>>
>>>>


From coleen.phillimore at sun.com  Mon Jan 12 20:23:53 2009
From: coleen.phillimore at sun.com (coleen.phillimore at sun.com)
Date: Tue, 13 Jan 2009 04:23:53 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 10 new changesets
Message-ID: <20090113042413.024BDD4FD@hg.openjdk.java.net>

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

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

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

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

Added tag jdk7-b42 for changeset ad8c8ca4ab0f

! .hgtags

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

Merge

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

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

Merge

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

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

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

! make/hotspot_version

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

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

! make/hotspot_version

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

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

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

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

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

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

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

Merge


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

Merge

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



From coleen.phillimore at sun.com  Tue Jan 13 14:46:35 2009
From: coleen.phillimore at sun.com (coleen.phillimore at sun.com)
Date: Tue, 13 Jan 2009 22:46:35 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6791168: Fix invalid code in
	bytecodeInterpreter that can cause gcc ICE
Message-ID: <20090113224638.5C85CD5E6@hg.openjdk.java.net>

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

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

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



From xiaobin.lu at sun.com  Tue Jan 13 17:13:15 2009
From: xiaobin.lu at sun.com (xiaobin.lu at sun.com)
Date: Wed, 14 Jan 2009 01:13:15 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20090114011321.6CA03D5EF@hg.openjdk.java.net>

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

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

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

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

Merge


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

Merge




From xiaobin.lu at sun.com  Tue Jan 13 20:06:23 2009
From: xiaobin.lu at sun.com (xiaobin.lu at sun.com)
Date: Wed, 14 Jan 2009 04:06:23 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6792301: StackAlignmentInBytes not
	honored for compiled native methods
Message-ID: <20090114040629.9A2D8D63C@hg.openjdk.java.net>

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

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

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



From sun.newsgroup at gmail.com  Wed Jan 14 20:54:41 2009
From: sun.newsgroup at gmail.com (Chenguang Sun)
Date: Wed, 14 Jan 2009 23:54:41 -0500
Subject: Which part of the source code tree is related to program control flow?
Message-ID: <496EC191.1090109@gmail.com>

Hi,

I'm reading Openjdk's source code. Could anybody tell me which part of 
the source code tree is related to program's control flow? Is there any 
document that can give a whole graph of the interpreter's structure?

Thanks,
Chenguang


From coleen.phillimore at sun.com  Thu Jan 15 12:08:03 2009
From: coleen.phillimore at sun.com (coleen.phillimore at sun.com)
Date: Thu, 15 Jan 2009 20:08:03 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6793825: Missing include dependancies
	for GCC without predefined headers
Message-ID: <20090115200805.2CC75D879@hg.openjdk.java.net>

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

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

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



From swamy.venkataramanappa at sun.com  Thu Jan 15 15:50:42 2009
From: swamy.venkataramanappa at sun.com (swamy.venkataramanappa at sun.com)
Date: Thu, 15 Jan 2009 23:50:42 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20090115235046.D3F0ED8DE@hg.openjdk.java.net>

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

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

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

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

Merge




From john.coomes at sun.com  Fri Jan 16 01:28:30 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:28:30 +0000
Subject: hg: jdk7/hotspot-rt: Added tag jdk7-b43 for changeset 848e684279d2
Message-ID: <20090116092831.0A934DA8E@hg.openjdk.java.net>

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

Added tag jdk7-b43 for changeset 848e684279d2

! .hgtags



From john.coomes at sun.com  Fri Jan 16 01:30:37 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:30:37 +0000
Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b43 for changeset
	9cd740d48a48
Message-ID: <20090116093039.02D61DA93@hg.openjdk.java.net>

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

Added tag jdk7-b43 for changeset 9cd740d48a48

! .hgtags



From john.coomes at sun.com  Fri Jan 16 01:34:54 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:34:54 +0000
Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b43 for changeset
	96fe28d4a913
Message-ID: <20090116093457.441C1DA98@hg.openjdk.java.net>

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

Added tag jdk7-b43 for changeset 96fe28d4a913

! .hgtags



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

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

Added tag jdk7-b43 for changeset 1ad2f51564db

! .hgtags



From john.coomes at sun.com  Fri Jan 16 01:42:04 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 09:42:04 +0000
Subject: hg: jdk7/hotspot-rt/jdk: 53 new changesets
Message-ID: <20090116095234.8B263DAA2@hg.openjdk.java.net>

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge


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

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

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

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

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

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

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

Merge


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

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

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

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

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

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

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

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

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

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

Merge


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

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

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

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

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

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

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

Merge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge


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

Merge

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

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

Added tag jdk7-b43 for changeset 50c67678b0d1

! .hgtags



From john.coomes at sun.com  Fri Jan 16 02:00:14 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 16 Jan 2009 10:00:14 +0000
Subject: hg: jdk7/hotspot-rt/langtools: 4 new changesets
Message-ID: <20090116100020.DC966DAA7@hg.openjdk.java.net>

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

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

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

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

Merge


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

Merge


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

Added tag jdk7-b43 for changeset e2f8f6daee9d

! .hgtags



From keith.mcguigan at sun.com  Wed Jan 21 11:11:41 2009
From: keith.mcguigan at sun.com (keith.mcguigan at sun.com)
Date: Wed, 21 Jan 2009 19:11:41 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6792705: Add JAR file to bootclasspath
	when using AggressiveOpts
Message-ID: <20090121191143.5C27BDD3F@hg.openjdk.java.net>

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

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

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



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

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

Added tag jdk7-b44 for changeset a395e3aac474

! .hgtags



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

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

Added tag jdk7-b44 for changeset 9803dac72540

! .hgtags



From john.coomes at sun.com  Thu Jan 22 22:01:27 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 06:01:27 +0000
Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b44 for changeset
	b203df0741af
Message-ID: <20090123060130.A07D6DF6B@hg.openjdk.java.net>

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

Added tag jdk7-b44 for changeset b203df0741af

! .hgtags



From john.coomes at sun.com  Thu Jan 22 22:03:57 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 06:03:57 +0000
Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b44 for changeset
	344485a03674
Message-ID: <20090123060359.3F0D3DF70@hg.openjdk.java.net>

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

Added tag jdk7-b44 for changeset 344485a03674

! .hgtags



From john.coomes at sun.com  Thu Jan 22 22:06:51 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 06:06:51 +0000
Subject: hg: jdk7/hotspot-rt/jdk: 17 new changesets
Message-ID: <20090123061025.2D7D7DF7B@hg.openjdk.java.net>

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

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

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

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

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

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

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

Merge


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

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

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

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

Merge


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

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

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

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

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

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

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

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

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

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

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

! make/docs/Makefile

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

Merge


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

Merge


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

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

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

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

Merge


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

Merge


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

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

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

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

Merge

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

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

Added tag jdk7-b44 for changeset d8eb2738db6b

! .hgtags



From john.coomes at sun.com  Thu Jan 22 22:12:49 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 23 Jan 2009 06:12:49 +0000
Subject: hg: jdk7/hotspot-rt/langtools: 9 new changesets
Message-ID: <20090123061304.9A61DDF82@hg.openjdk.java.net>

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

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

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

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

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

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

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

Merge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge


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

Added tag jdk7-b44 for changeset 28f0b10d6c1a

! .hgtags



From coleen.phillimore at sun.com  Mon Jan 26 08:56:38 2009
From: coleen.phillimore at sun.com (coleen.phillimore at sun.com)
Date: Mon, 26 Jan 2009 16:56:38 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 7 new changesets
Message-ID: <20090126165651.5BC0BE1A4@hg.openjdk.java.net>

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

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

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/space.cpp
! src/share/vm/memory/space.hpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/services/heapDumper.cpp

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

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

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

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

Merge

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

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

Merge


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

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

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

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

Merge


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

Merge

! src/share/vm/gc_implementation/includeDB_gc_g1



From xiaobin.lu at sun.com  Mon Jan 26 14:31:41 2009
From: xiaobin.lu at sun.com (xiaobin.lu at sun.com)
Date: Mon, 26 Jan 2009 22:31:41 +0000
Subject: hg: jdk7/hotspot-rt/hotspot: 6795913: A few remaining wrong casts
	need to be fixed for building hotspot successfully on Mac OS.
Message-ID: <20090126223143.D3FB2E1C5@hg.openjdk.java.net>

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

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

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



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

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

Added tag jdk7-b45 for changeset 99846f001ca2

! .hgtags



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

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

Added tag jdk7-b45 for changeset 68814aa5b44b

! .hgtags



From john.coomes at sun.com  Thu Jan 29 22:01:40 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 06:01:40 +0000
Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b45 for changeset
	0f113667880d
Message-ID: <20090130060142.7E6B1E549@hg.openjdk.java.net>

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

Added tag jdk7-b45 for changeset 0f113667880d

! .hgtags



From john.coomes at sun.com  Thu Jan 29 22:04:06 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 06:04:06 +0000
Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b45 for changeset
	dea7753d7139
Message-ID: <20090130060408.65CD2E54E@hg.openjdk.java.net>

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

Added tag jdk7-b45 for changeset dea7753d7139

! .hgtags



From john.coomes at sun.com  Thu Jan 29 22:06:39 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 06:06:39 +0000
Subject: hg: jdk7/hotspot-rt/jdk: Added tag jdk7-b45 for changeset 527b426497a2
Message-ID: <20090130060707.BE9DDE553@hg.openjdk.java.net>

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

Added tag jdk7-b45 for changeset 527b426497a2

! .hgtags



From john.coomes at sun.com  Thu Jan 29 22:09:33 2009
From: john.coomes at sun.com (john.coomes at sun.com)
Date: Fri, 30 Jan 2009 06:09:33 +0000
Subject: hg: jdk7/hotspot-rt/langtools: Added tag jdk7-b45 for changeset
	30db5e0aaf83
Message-ID: <20090130060936.BD220E558@hg.openjdk.java.net>

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

Added tag jdk7-b45 for changeset 30db5e0aaf83

! .hgtags