From david.holmes at oracle.com  Sun Dec  2 17:55:04 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 03 Dec 2012 11:55:04 +1000
Subject: Profiles update to jdk8-b65
Message-ID: <50BC0678.1040300@oracle.com>

Just FYI the Profiles forest has been updated to the jdk8-b65 level. I 
hope to catch up to b66 this week.

There is no new functionality here. The builds are still officially 
limited to linux only and I will soon add a check for that to allow this 
to be merged with the mainline repos.

David
-----

From glewis at eyesbeyond.com  Sun Dec  2 23:00:19 2012
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Sun, 2 Dec 2012 23:00:19 -0800
Subject: Getting HotSpot from JDK8 to compile on non-MacOS X BSD systems
Message-ID: <20121203070019.GA98553@misty.eyesbeyond.com>

I'm working on getting jdk8 to compile on FreeBSD.  The HotSpot build was
actually pretty close.  I had a few small changes I've posted in a webrev
here:

http://people.freebsd.org/~glewis/openjdk8/webrev.freebsd.hotspot.1/

Is there someone I can work with to review and get them into the tree?

I also had to override AS like so:

gmake NEWBUILD=true AS="gcc -c -x assembler-with-cpp -m32 -march=i586"

That's a bit of a gross hack since ARCH and ARCH_DATA_MODEL are embedded
in there directly.  Ideally the build would detect this as part of
configure rather than me overriding it directly like this.  I'm not quite
sure would to modify for that though since its already set up like that
in make/bsd/makefiles/gcc.make.  Any guidance on that?

I haven't been able to test the resulting libjvm.so yet since I'm still
slogging through the jdk build.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org

From david.holmes at oracle.com  Sun Dec  2 23:33:15 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 03 Dec 2012 17:33:15 +1000
Subject: Getting HotSpot from JDK8 to compile on non-MacOS X BSD systems
In-Reply-To: <20121203070019.GA98553@misty.eyesbeyond.com>
References: <20121203070019.GA98553@misty.eyesbeyond.com>
Message-ID: <50BC55BB.1060505@oracle.com>

Hi Greg,

FYI the hotspot make system is not configure aware so for now you have 
to modify the <os>/makefiles/*.make files, or else override variables 
directly.

David

On 3/12/2012 5:00 PM, Greg Lewis wrote:
> I'm working on getting jdk8 to compile on FreeBSD.  The HotSpot build was
> actually pretty close.  I had a few small changes I've posted in a webrev
> here:
>
> http://people.freebsd.org/~glewis/openjdk8/webrev.freebsd.hotspot.1/
>
> Is there someone I can work with to review and get them into the tree?
>
> I also had to override AS like so:
>
> gmake NEWBUILD=true AS="gcc -c -x assembler-with-cpp -m32 -march=i586"
>
> That's a bit of a gross hack since ARCH and ARCH_DATA_MODEL are embedded
> in there directly.  Ideally the build would detect this as part of
> configure rather than me overriding it directly like this.  I'm not quite
> sure would to modify for that though since its already set up like that
> in make/bsd/makefiles/gcc.make.  Any guidance on that?
>
> I haven't been able to test the resulting libjvm.so yet since I'm still
> slogging through the jdk build.
>

From staffan.larsen at oracle.com  Mon Dec  3 03:32:41 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 3 Dec 2012 12:32:41 +0100
Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167)
Message-ID: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>

All,

This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change.

The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/
The JEP is here: http://openjdk.java.net/jeps/167

The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events. 

To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty.

These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag.

Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser 

Comments, questions and suggestions are welcome!

Thanks,
/Staffan

From david.holmes at oracle.com  Mon Dec  3 04:06:41 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 03 Dec 2012 22:06:41 +1000
Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167)
In-Reply-To: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
References: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
Message-ID: <50BC95D1.6090007@oracle.com>

Staffan,

Is there any documentation describing the overall architecture and 
mechanisms being used here?

Thanks,
David

On 3/12/2012 9:32 PM, Staffan Larsen wrote:
> All,
>
> This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change.
>
> The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/
> The JEP is here: http://openjdk.java.net/jeps/167
>
> The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events.
>
> To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty.
>
> These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag.
>
> Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser
>
> Comments, questions and suggestions are welcome!
>
> Thanks,
> /Staffan

From staffan.larsen at oracle.com  Mon Dec  3 04:16:33 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 3 Dec 2012 13:16:33 +0100
Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167)
In-Reply-To: <50BC95D1.6090007@oracle.com>
References: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
	<50BC95D1.6090007@oracle.com>
Message-ID: <338EB5E2-7210-47BA-8F06-7E520FB0064A@oracle.com>

David,

There is no such documentation today. The easiest way to follow the code is to first compile it so that you have access to the generated classes. Then browse the code under src/share/vm/trace together with the code under build/<platform>/generated/tracefiles. The generated code is created from src/share/vm/trace/trace.xml and the associated .xsl files in the same directory. 

Thanks,
/Staffan

On 3 dec 2012, at 13:06, David Holmes <David.Holmes at oracle.com> wrote:

> Staffan,
> 
> Is there any documentation describing the overall architecture and mechanisms being used here?
> 
> Thanks,
> David
> 
> On 3/12/2012 9:32 PM, Staffan Larsen wrote:
>> All,
>> 
>> This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change.
>> 
>> The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/
>> The JEP is here: http://openjdk.java.net/jeps/167
>> 
>> The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events.
>> 
>> To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty.
>> 
>> These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag.
>> 
>> Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser
>> 
>> Comments, questions and suggestions are welcome!
>> 
>> Thanks,
>> /Staffan


From coleen.phillimore at oracle.com  Mon Dec  3 06:26:42 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 03 Dec 2012 09:26:42 -0500
Subject: Result: New hsx Committer: Harold Seigel
Message-ID: <50BCB6A2.4080503@oracle.com>


Voting for Harold Seigel [1] is now closed.

Yes: 15
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Coleen Phillimore
|*

* [1] 
*http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007248.html*|


From mark.reinhold at oracle.com  Mon Dec  3 09:31:22 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon,  3 Dec 2012 09:31:22 -0800 (PST)
Subject: JEP 171: Fence Intrinsics
Message-ID: <20121203173122.95966787@eggemoggin.niobe.net>

Posted: http://openjdk.java.net/jeps/171

- Mark

From david.r.chase at oracle.com  Mon Dec  3 09:45:54 2012
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 3 Dec 2012 12:45:54 -0500
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <20121203173122.95966787@eggemoggin.niobe.net>
References: <20121203173122.95966787@eggemoggin.niobe.net>
Message-ID: <002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>

Is this the right place to comment on this?
I think these should not go in Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.

My reasoning is that there are some lock- or obstruction-free algorithms that do require CAS and (in some cases) fences, but do not require anything that is actually unsafe, and do not require the security clearance that goes with being allowed access to Unsafe.

On 2012-12-03, at 12:31 PM, mark.reinhold at oracle.com wrote:

> Posted: http://openjdk.java.net/jeps/171
> 
> - Mark


From dl at cs.oswego.edu  Mon Dec  3 09:54:11 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 03 Dec 2012 12:54:11 -0500
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
Message-ID: <50BCE743.10705@cs.oswego.edu>

On 12/03/12 12:45, David Chase wrote:
> Is this the right place to comment on this? I think these should not go in
> Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.

They cannot. The methods cannot be spec'ed using only the concepts
in the JLS/JMM. So they are not "Java methods", but "JVM methods".
(This is the same rationale for placing @Contended in sun.misc.)
Someday, a serious effort is needed to enable rigorous specs
of core intrinsics along these lines (possible even with a
Java-level JMM memory model overhaul). But I don't think anyone
wants to hold these methods hostage for years until this happens.

-Doug




From david.r.chase at oracle.com  Mon Dec  3 10:25:06 2012
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 3 Dec 2012 13:25:06 -0500
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <50BCE743.10705@cs.oswego.edu>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
Message-ID: <9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>

I'll defer to your judgement on the JMM issues, but from a user (programmer) POV, does this distinction make a difference?  I think their (in)ability to write "portable" code (across style checkers, across class loaders) would be a big deal.

How about "sun.misc.VM" instead?  Unsafe seems to be booby-trapped against use by non-system classloaders; I don't see how that is necessary here.

David

On 2012-12-03, at 12:54 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/03/12 12:45, David Chase wrote:
>> Is this the right place to comment on this? I think these should not go in
>> Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.
> 
> They cannot. The methods cannot be spec'ed using only the concepts
> in the JLS/JMM. So they are not "Java methods", but "JVM methods".
> (This is the same rationale for placing @Contended in sun.misc.)
> Someday, a serious effort is needed to enable rigorous specs
> of core intrinsics along these lines (possible even with a
> Java-level JMM memory model overhaul). But I don't think anyone
> wants to hold these methods hostage for years until this happens.
> 
> -Doug
> 
> 
> 


From forax at univ-mlv.fr  Mon Dec  3 10:26:40 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 03 Dec 2012 19:26:40 +0100
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <50BCE743.10705@cs.oswego.edu>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
Message-ID: <50BCEEE0.3060702@univ-mlv.fr>

On 12/03/2012 06:54 PM, Doug Lea wrote:
> On 12/03/12 12:45, David Chase wrote:
>> Is this the right place to comment on this? I think these should not 
>> go in
>> Unsafe; fence intrinsics belong with compareAndSet in 
>> j.u.concurrent.atomic.
>
> They cannot. The methods cannot be spec'ed using only the concepts
> in the JLS/JMM. So they are not "Java methods", but "JVM methods".
> (This is the same rationale for placing @Contended in sun.misc.)
> Someday, a serious effort is needed to enable rigorous specs
> of core intrinsics along these lines (possible even with a
> Java-level JMM memory model overhaul). But I don't think anyone
> wants to hold these methods hostage for years until this happens.

as stated in the JEP, this methods are not unsafe, so while I think they 
belong to sun.misc,
I would prefer have them in sun.misc.Fences as static methods instead of 
putting them
in sun.misc.Unsafe because getting the sun.misc.Unsafe instance requires 
some privileges.

>
> -Doug
>

R?mi


From forax at univ-mlv.fr  Mon Dec  3 10:28:16 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 03 Dec 2012 19:28:16 +0100
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
	<9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>
Message-ID: <50BCEF40.1040108@univ-mlv.fr>

On 12/03/2012 07:25 PM, David Chase wrote:
> I'll defer to your judgement on the JMM issues, but from a user (programmer) POV, does this distinction make a difference?  I think their (in)ability to write "portable" code (across style checkers, across class loaders) would be a big deal.
>
> How about "sun.misc.VM" instead?  Unsafe seems to be booby-trapped against use by non-system classloaders; I don't see how that is necessary here.
>
> David

I fully agree, I've just sent a mail with the very same idea.

R?mi

>
> On 2012-12-03, at 12:54 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>
>> On 12/03/12 12:45, David Chase wrote:
>>> Is this the right place to comment on this? I think these should not go in
>>> Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.
>> They cannot. The methods cannot be spec'ed using only the concepts
>> in the JLS/JMM. So they are not "Java methods", but "JVM methods".
>> (This is the same rationale for placing @Contended in sun.misc.)
>> Someday, a serious effort is needed to enable rigorous specs
>> of core intrinsics along these lines (possible even with a
>> Java-level JMM memory model overhaul). But I don't think anyone
>> wants to hold these methods hostage for years until this happens.
>>
>> -Doug
>>
>>
>>


From staffan.larsen at oracle.com  Mon Dec  3 11:14:05 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 3 Dec 2012 20:14:05 +0100
Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167)
In-Reply-To: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
References: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
Message-ID: <2EA32DB8-118A-4780-8B72-453A4073BAD2@oracle.com>

Forgot to include serviceability-dev at openjdk.java.net which is the designated list for JEP 167.

/Staffan

On 3 dec 2012, at 12:32, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> All,
> 
> This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change.
> 
> The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/
> The JEP is here: http://openjdk.java.net/jeps/167
> 
> The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events. 
> 
> To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty.
> 
> These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag.
> 
> Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser 
> 
> Comments, questions and suggestions are welcome!
> 
> Thanks,
> /Staffan


From dl at cs.oswego.edu  Mon Dec  3 12:00:12 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 03 Dec 2012 15:00:12 -0500
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
	<9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>
Message-ID: <50BD04CC.5020905@cs.oswego.edu>

On 12/03/12 13:25, David Chase wrote:
> I'll defer to your judgement on the JMM issues, but from a user (programmer)
> POV, does this distinction make a difference?  I think their (in)ability to
> write "portable" code (across style checkers, across class loaders) would be
> a big deal.
>
> How about "sun.misc.VM" instead?  Unsafe seems to be booby-trapped against
> use by non-system classloaders; I don't see how that is necessary here.
>

Placing in Unsafe is in the tradition of the "voids your warranty".
The moral-hazard faction (to which I'm a little sympathetic)
really don't want ANY programmers accidentally using such methods.
And rather than scrapping fences for yet another JDK release,
my hope is that establishing in a way that completely precludes this,
even at the expense of usability in other contexts, is
uncontroversial enough to accept.

I'm also hoping that for JDK9, there will be some nicer way to
support all memory-model-related special operations
without Unsafe. If nothing else, keeping it painful to use for
now might hasten efforts to improve this situation.

-Doug

From glewis at eyesbeyond.com  Mon Dec  3 18:48:24 2012
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 3 Dec 2012 18:48:24 -0800
Subject: Getting HotSpot from JDK8 to compile on non-MacOS X BSD systems
In-Reply-To: <50BC55BB.1060505@oracle.com>
References: <20121203070019.GA98553@misty.eyesbeyond.com>
	<50BC55BB.1060505@oracle.com>
Message-ID: <20121204024824.GA11956@misty.eyesbeyond.com>

Thanks David,

make/bsd/makefiles/gcc.make already has the right setting for AS.  I guess
I'll just need to figure out where the setting that is taking precedence
is coming from.

Are you able to shepherd the other changes that I put into the webrev into
the HotSpot tree?  Do we need a corresponding bug?

-- Greg

On Mon, Dec 03, 2012 at 05:33:15PM +1000, David Holmes wrote:
> Hi Greg,
> 
> FYI the hotspot make system is not configure aware so for now you have 
> to modify the <os>/makefiles/*.make files, or else override variables 
> directly.
> 
> David
> 
> On 3/12/2012 5:00 PM, Greg Lewis wrote:
> > I'm working on getting jdk8 to compile on FreeBSD.  The HotSpot build was
> > actually pretty close.  I had a few small changes I've posted in a webrev
> > here:
> >
> > http://people.freebsd.org/~glewis/openjdk8/webrev.freebsd.hotspot.1/
> >
> > Is there someone I can work with to review and get them into the tree?
> >
> > I also had to override AS like so:
> >
> > gmake NEWBUILD=true AS="gcc -c -x assembler-with-cpp -m32 -march=i586"
> >
> > That's a bit of a gross hack since ARCH and ARCH_DATA_MODEL are embedded
> > in there directly.  Ideally the build would detect this as part of
> > configure rather than me overriding it directly like this.  I'm not quite
> > sure would to modify for that though since its already set up like that
> > in make/bsd/makefiles/gcc.make.  Any guidance on that?
> >
> > I haven't been able to test the resulting libjvm.so yet since I'm still
> > slogging through the jdk build.
> >

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org

From david.holmes at oracle.com  Mon Dec  3 19:20:46 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 04 Dec 2012 13:20:46 +1000
Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167)
In-Reply-To: <338EB5E2-7210-47BA-8F06-7E520FB0064A@oracle.com>
References: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
	<50BC95D1.6090007@oracle.com>
	<338EB5E2-7210-47BA-8F06-7E520FB0064A@oracle.com>
Message-ID: <50BD6C0E.5030501@oracle.com>

On 3/12/2012 10:16 PM, Staffan Larsen wrote:
> David,
>
> There is no such documentation today. The easiest way to follow the code is to first compile it so that you have access to the generated classes. Then browse the code under src/share/vm/trace together with the code under build/<platform>/generated/tracefiles. The generated code is created from src/share/vm/trace/trace.xml and the associated .xsl files in the same directory.

I was hoping for a higher level description of how this is supposed to 
hang together and the mechanisms in use. Whenever I see anyone using 
signal-based suspend/resume (especially when we went a long way down the 
road to eradicating its use!) I get very nervous.

David
-----

> Thanks,
> /Staffan
>
> On 3 dec 2012, at 13:06, David Holmes<David.Holmes at oracle.com>  wrote:
>
>> Staffan,
>>
>> Is there any documentation describing the overall architecture and mechanisms being used here?
>>
>> Thanks,
>> David
>>
>> On 3/12/2012 9:32 PM, Staffan Larsen wrote:
>>> All,
>>>
>>> This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change.
>>>
>>> The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/
>>> The JEP is here: http://openjdk.java.net/jeps/167
>>>
>>> The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events.
>>>
>>> To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty.
>>>
>>> These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag.
>>>
>>> Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser
>>>
>>> Comments, questions and suggestions are welcome!
>>>
>>> Thanks,
>>> /Staffan
>

From david.holmes at oracle.com  Mon Dec  3 20:12:39 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 04 Dec 2012 14:12:39 +1000
Subject: Getting HotSpot from JDK8 to compile on non-MacOS X BSD systems
In-Reply-To: <20121204024824.GA11956@misty.eyesbeyond.com>
References: <20121203070019.GA98553@misty.eyesbeyond.com>
	<50BC55BB.1060505@oracle.com>
	<20121204024824.GA11956@misty.eyesbeyond.com>
Message-ID: <50BD7837.30805@oracle.com>

On 4/12/2012 12:48 PM, Greg Lewis wrote:
> Thanks David,
>
> make/bsd/makefiles/gcc.make already has the right setting for AS.  I guess
> I'll just need to figure out where the setting that is taking precedence
> is coming from.

Are you using the new build system for this? If so it is likely coming 
from the configure step. Check all the generated *spec*.gmk files to see 
if anything is being set that should not be.

> Are you able to shepherd the other changes that I put into the webrev into
> the HotSpot tree?  Do we need a corresponding bug?

You will need a corresponding bug, but I'm afraid I can't pick this one 
up at this time.

David
-----

>
> -- Greg
>
> On Mon, Dec 03, 2012 at 05:33:15PM +1000, David Holmes wrote:
>> Hi Greg,
>>
>> FYI the hotspot make system is not configure aware so for now you have
>> to modify the<os>/makefiles/*.make files, or else override variables
>> directly.
>>
>> David
>>
>> On 3/12/2012 5:00 PM, Greg Lewis wrote:
>>> I'm working on getting jdk8 to compile on FreeBSD.  The HotSpot build was
>>> actually pretty close.  I had a few small changes I've posted in a webrev
>>> here:
>>>
>>> http://people.freebsd.org/~glewis/openjdk8/webrev.freebsd.hotspot.1/
>>>
>>> Is there someone I can work with to review and get them into the tree?
>>>
>>> I also had to override AS like so:
>>>
>>> gmake NEWBUILD=true AS="gcc -c -x assembler-with-cpp -m32 -march=i586"
>>>
>>> That's a bit of a gross hack since ARCH and ARCH_DATA_MODEL are embedded
>>> in there directly.  Ideally the build would detect this as part of
>>> configure rather than me overriding it directly like this.  I'm not quite
>>> sure would to modify for that though since its already set up like that
>>> in make/bsd/makefiles/gcc.make.  Any guidance on that?
>>>
>>> I haven't been able to test the resulting libjvm.so yet since I'm still
>>> slogging through the jdk build.
>>>
>

From nils.eliasson at oracle.com  Tue Dec  4 03:05:03 2012
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 04 Dec 2012 12:05:03 +0100
Subject: RFR(S):  Fix generation of malformed options for Projectcreator
In-Reply-To: <50AF7457.1050209@oracle.com>
References: <50AF363E.9090108@oracle.com> <50AF7457.1050209@oracle.com>
Message-ID: <50BDD8DF.8020206@oracle.com>

Still missing reviews.

//N

Nils Eliasson skrev 2012-11-23 14:04:
> Slight change. Moving placement of escaping tokens for a more 
> enjoyable experience.
>
> http://cr.openjdk.java.net/~neliasso/8003934/webrev.02/
>
> //N
>
> Nils Eliasson skrev 2012-11-23 09:39:
>> Preferably reviewed by someone with a little nmake experience.
>>
>> This fixes a bug which causes visual studio to throw errors when 
>> trying to build hotspot.
>>
>> make/windows/projectfiles/common/Make sets up some options that is 
>> passed as a string to ProjectCreator.java. That string gets unmatched 
>> pairs of escaped quotation marks around the hotspot release version. 
>> After closer examination that happens when a number of vars and 
>> escaped quotation marks are appended together on a multi line string 
>> append.
>>
>> This fixes removes unnecessary (and potentially bad) quotation marks, 
>> simplifies the option creation and creates the options with escaping 
>> characters on the same line.
>>
>> http://cr.openjdk.java.net/~neliasso/8003934/webrev.01/
>>
>> Thanks,
>> Nils Eliasson
>


From jesper.wilhelmsson at oracle.com  Tue Dec  4 03:44:56 2012
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 04 Dec 2012 12:44:56 +0100
Subject: RFR(S):  Fix generation of malformed options for Projectcreator
In-Reply-To: <50BDD8DF.8020206@oracle.com>
References: <50AF363E.9090108@oracle.com> <50AF7457.1050209@oracle.com>
	<50BDD8DF.8020206@oracle.com>
Message-ID: <50BDE238.9090106@oracle.com>

I was hoping to never have to look at nmake-files again...

Your changes looks good. I have not verified by building vcproj-files 
though.
Ship it!
/Jesper


On 4/12/12 12:05 PM, Nils Eliasson wrote:
> Still missing reviews.
>
> //N
>
> Nils Eliasson skrev 2012-11-23 14:04:
>> Slight change. Moving placement of escaping tokens for a more 
>> enjoyable experience.
>>
>> http://cr.openjdk.java.net/~neliasso/8003934/webrev.02/
>>
>> //N
>>
>> Nils Eliasson skrev 2012-11-23 09:39:
>>> Preferably reviewed by someone with a little nmake experience.
>>>
>>> This fixes a bug which causes visual studio to throw errors when 
>>> trying to build hotspot.
>>>
>>> make/windows/projectfiles/common/Make sets up some options that is 
>>> passed as a string to ProjectCreator.java. That string gets 
>>> unmatched pairs of escaped quotation marks around the hotspot 
>>> release version. After closer examination that happens when a number 
>>> of vars and escaped quotation marks are appended together on a multi 
>>> line string append.
>>>
>>> This fixes removes unnecessary (and potentially bad) quotation 
>>> marks, simplifies the option creation and creates the options with 
>>> escaping characters on the same line.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8003934/webrev.01/
>>>
>>> Thanks,
>>> Nils Eliasson
>>
>


From staffan.larsen at oracle.com  Tue Dec  4 04:34:34 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 4 Dec 2012 13:34:34 +0100
Subject: Request for review (XL): Event-Based JVM Tracing (JEP 167)
In-Reply-To: <50BD6C0E.5030501@oracle.com>
References: <83B08058-5B23-4005-8611-6C97586E5C9A@oracle.com>
	<50BC95D1.6090007@oracle.com>
	<338EB5E2-7210-47BA-8F06-7E520FB0064A@oracle.com>
	<50BD6C0E.5030501@oracle.com>
Message-ID: <7C2C46D3-C7C0-4C28-899F-0A5E32C8B31C@oracle.com>


On 4 dec 2012, at 04:20, David Holmes <David.Holmes at oracle.com> wrote:

> On 3/12/2012 10:16 PM, Staffan Larsen wrote:
>> David,
>> 
>> There is no such documentation today. The easiest way to follow the code is to first compile it so that you have access to the generated classes. Then browse the code under src/share/vm/trace together with the code under build/<platform>/generated/tracefiles. The generated code is created from src/share/vm/trace/trace.xml and the associated .xsl files in the same directory.
> 
> I was hoping for a higher level description of how this is supposed to hang together and the mechanisms in use. Whenever I see anyone using signal-based suspend/resume (especially when we went a long way down the road to eradicating its use!) I get very nervous.

The signal-based suspend/resume is only used for sampling-based profiling. For this use case the requirements are loose, meaning that we have a high tolerance for missing a sample if we aren't able to suspend properly.

/Staffan

> 
> David
> -----
> 
>> Thanks,
>> /Staffan
>> 
>> On 3 dec 2012, at 13:06, David Holmes<David.Holmes at oracle.com>  wrote:
>> 
>>> Staffan,
>>> 
>>> Is there any documentation describing the overall architecture and mechanisms being used here?
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 3/12/2012 9:32 PM, Staffan Larsen wrote:
>>>> All,
>>>> 
>>>> This is a request for review of the implementation for JEP 167: Event-Based JVM Tracing. It is a rather large change.
>>>> 
>>>> The webrev is available here: http://cr.openjdk.java.net/~sla/jep167/webrev.01/
>>>> The JEP is here: http://openjdk.java.net/jeps/167
>>>> 
>>>> The base changes are in src/share/vm/trace. This is where events are defined (trace.xml) and this is where the XSLT transforms that convert these definitions into classes are. The rest of the changes are related to instrumenting the code to capture the data for the events.
>>>> 
>>>> To enabled the tracing events in a build use -XX:+EnableTracing. This will produce a ton of information in a standard format to tty.
>>>> 
>>>> These changes are slated for hs24 in the 7u12 release and will be ported to hs25 in jdk8 later. The diff is against the jdk7u/jdk7u forest at the jdk7u12-b03 tag.
>>>> 
>>>> Contributed-by: acorn, brutisso, ccheung, egahlin, ehelin, jwilhelm, kamg, mattias.tobiasson at oracle.com, mgronlun, mikael.auno at oracle.com, neliasso, nloodin, rbackman, sla, stefank, ykantser
>>>> 
>>>> Comments, questions and suggestions are welcome!
>>>> 
>>>> Thanks,
>>>> /Staffan
>> 


From aleksey.shipilev at oracle.com  Tue Dec  4 13:26:25 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 05 Dec 2012 01:26:25 +0400
Subject: RFR (M) #2 CR 8003985: Support @Contended annotation
Message-ID: <50BE6A81.4060900@oracle.com>

Hi,

This is the revamp of JEP-142 aka @Contended, taking into the account
the feedbacks of Christian, Coleen and others:
  http://shipilev.net/pub/jdk/hotspot/contended/webrev-5/

The bottom line for most of the changes is dealing with footprint. I
think I've managed to squeeze into the same footprint by reusing
InstanceKlass::misc_flags to store class-level flag, and tagged field in
FieldInfo (as the side effect, cleaning up the mess with "temporarily
store type into offset field") to store per-field info.

Testing:
  - built and tested on Linux x86_64
  - Test8003985 is passing on Linux x86_64

Please take a look while I'm getting this through acceptance checks on
other platforms.

-Aleksey

From vitalyd at gmail.com  Tue Dec  4 14:10:12 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 4 Dec 2012 17:10:12 -0500
Subject: RFR (M) #2 CR 8003985: Support @Contended annotation
In-Reply-To: <50BE6A81.4060900@oracle.com>
References: <50BE6A81.4060900@oracle.com>
Message-ID: <CAHjP37Fa5+uSBTVfk=3JMK6foGNeHNTiOrwy51NK-TwJGP+0fw@mail.gmail.com>

PrintFieldLayout is still notproduct :) - did someone object to making it
diagnostic/product?

Thanks

Sent from my phone
On Dec 4, 2012 4:27 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> Hi,
>
> This is the revamp of JEP-142 aka @Contended, taking into the account
> the feedbacks of Christian, Coleen and others:
>   http://shipilev.net/pub/jdk/hotspot/contended/webrev-5/
>
> The bottom line for most of the changes is dealing with footprint. I
> think I've managed to squeeze into the same footprint by reusing
> InstanceKlass::misc_flags to store class-level flag, and tagged field in
> FieldInfo (as the side effect, cleaning up the mess with "temporarily
> store type into offset field") to store per-field info.
>
> Testing:
>   - built and tested on Linux x86_64
>   - Test8003985 is passing on Linux x86_64
>
> Please take a look while I'm getting this through acceptance checks on
> other platforms.
>
> -Aleksey
>

From aleksey.shipilev at oracle.com  Tue Dec  4 14:15:06 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 05 Dec 2012 02:15:06 +0400
Subject: RFR (M) #2 CR 8003985: Support @Contended annotation
In-Reply-To: <CAHjP37Fa5+uSBTVfk=3JMK6foGNeHNTiOrwy51NK-TwJGP+0fw@mail.gmail.com>
References: <50BE6A81.4060900@oracle.com>
	<CAHjP37Fa5+uSBTVfk=3JMK6foGNeHNTiOrwy51NK-TwJGP+0fw@mail.gmail.com>
Message-ID: <50BE75EA.9070309@oracle.com>

Frankly, I don't see the upsides, you can get the same level of
diagnostics at Java level; on any VM, any time you want. Is the a use
case which does not fit the bill of, say, java-field-layout [1]?

-Aleksey.

[1] https://github.com/shipilev/java-field-layout

On 12/05/2012 02:10 AM, Vitaly Davidovich wrote:
> PrintFieldLayout is still notproduct :) - did someone object to making
> it diagnostic/product?
> 
> Thanks
> 
> Sent from my phone
> 
> On Dec 4, 2012 4:27 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com
> <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     Hi,
> 
>     This is the revamp of JEP-142 aka @Contended, taking into the account
>     the feedbacks of Christian, Coleen and others:
>       http://shipilev.net/pub/jdk/hotspot/contended/webrev-5/
> 
>     The bottom line for most of the changes is dealing with footprint. I
>     think I've managed to squeeze into the same footprint by reusing
>     InstanceKlass::misc_flags to store class-level flag, and tagged field in
>     FieldInfo (as the side effect, cleaning up the mess with "temporarily
>     store type into offset field") to store per-field info.
> 
>     Testing:
>       - built and tested on Linux x86_64
>       - Test8003985 is passing on Linux x86_64
> 
>     Please take a look while I'm getting this through acceptance checks on
>     other platforms.
> 
>     -Aleksey
> 


From vitalyd at gmail.com  Tue Dec  4 14:54:12 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 4 Dec 2012 17:54:12 -0500
Subject: RFR (M) #2 CR 8003985: Support @Contended annotation
In-Reply-To: <50BE75EA.9070309@oracle.com>
References: <50BE6A81.4060900@oracle.com>
	<CAHjP37Fa5+uSBTVfk=3JMK6foGNeHNTiOrwy51NK-TwJGP+0fw@mail.gmail.com>
	<50BE75EA.9070309@oracle.com>
Message-ID: <CAHjP37ERvwJwgT2_MEHBWk_8MPLEiQk57LUmOdTfqYZXN3pjbw@mail.gmail.com>

Well, I think we agreed that using unsafe to get estimates is just that -
estimates.  I'd much rather have the VM report it precisely 100% of the
time reliably.  Plus, the code is already written by you; this is one bool
field and some extra code in the text section of the binary - is that
really too much footprint overhead?

If you and others are keen on keeping it notproduct then OK, no biggie -
unsafe it is then.

Sent from my phone
On Dec 4, 2012 5:15 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> Frankly, I don't see the upsides, you can get the same level of
> diagnostics at Java level; on any VM, any time you want. Is the a use
> case which does not fit the bill of, say, java-field-layout [1]?
>
> -Aleksey.
>
> [1] https://github.com/shipilev/java-field-layout
>
> On 12/05/2012 02:10 AM, Vitaly Davidovich wrote:
> > PrintFieldLayout is still notproduct :) - did someone object to making
> > it diagnostic/product?
> >
> > Thanks
> >
> > Sent from my phone
> >
> > On Dec 4, 2012 4:27 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com
> > <mailto:aleksey.shipilev at oracle.com>> wrote:
> >
> >     Hi,
> >
> >     This is the revamp of JEP-142 aka @Contended, taking into the account
> >     the feedbacks of Christian, Coleen and others:
> >       http://shipilev.net/pub/jdk/hotspot/contended/webrev-5/
> >
> >     The bottom line for most of the changes is dealing with footprint. I
> >     think I've managed to squeeze into the same footprint by reusing
> >     InstanceKlass::misc_flags to store class-level flag, and tagged
> field in
> >     FieldInfo (as the side effect, cleaning up the mess with "temporarily
> >     store type into offset field") to store per-field info.
> >
> >     Testing:
> >       - built and tested on Linux x86_64
> >       - Test8003985 is passing on Linux x86_64
> >
> >     Please take a look while I'm getting this through acceptance checks
> on
> >     other platforms.
> >
> >     -Aleksey
> >
>
>

From john.cuthbertson at oracle.com  Tue Dec  4 14:55:14 2012
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 04 Dec 2012 14:55:14 -0800
Subject: RFR(XXS): 8001028: Improve GC option handling
Message-ID: <50BE7F52.6040404@oracle.com>

Hi Everyone,

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

Summary:
When the JVM is starting up on a system that is out of native resources 
(perhaps as the result of the user specifying too large a number of GC 
threads), the creation of the Finalizer thread can fail. When this 
happens the JVM attempts to throw an out of memory error which can lead 
to assertion failures and crashes because the class for java.lang.Class 
has not yet been initialized. Changing the initialization order so that 
the initialization of java.lang.Class comes before 
java.lang.ref.Finalizer allows the JVM to exit in a more orderly fashion.

Testing:
Command line testing with some code inserted into the thread creation 
code to force ENOMEM returns; jprt; nsk gc, jit, regression tests.

This change has already been reviewed internally so I'm interested in 
hearing from folks who might be affected by the change in initialization 
order.

Thanks,

JohnC


From john.r.rose at oracle.com  Tue Dec  4 15:46:16 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 4 Dec 2012 15:46:16 -0800
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <50B4A569.8000707@cs.oswego.edu>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
Message-ID: <809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>

On Nov 27, 2012, at 3:35 AM, Doug Lea wrote:

> And, as someone else noted, sun.misc (where Unsafe lives) is even
> more exotic, and has the audience of low-level/core developers
> that this targets. Placing it there would get us past all the
> concerns (that I honestly think are wrong) about sending the
> wrong message or precluding miraculous automation. So, how
> about we just live with it as follows:

I don't mean to add insult to injury, but I think there is yet another restriction that we should place this annotation under, in its current residence of sun.misc.

The annotation must be documented as being a no-op when it occurs inside class files that are loaded outside the boot class path.

This is consistent with comments made by several other people, that these tools are intended, at least at first, for developers of core classes.  This is also consistent with Unsafe, which (however popular it is) is designed to be used core classes only, on the BCP (boot class path).[1]

For JSR 292 we are likely to introduce @ForceInline, @Stable, and some other annotations into sun.misc.  They will be restricted to BCP classes only, and may go away in the future.  How fast do you think people would pollute their code with @ForceInline if it was effective outside of core classes?  We need hooks for system-specific tuning (when the JIT is part of the tuned system) but we do not want a "register" keyword[2] to become part of Java lore.

At the same time the annotation is sufficiently understood to be exported more widely, it can be enabled off the BCP.  I think we need a module system in place to do a good job of this.  (And, yes, Unsafe should also be importable as a module of some sort.)

The bottom line is that sun.misc is a good place for vetting experimental annotations.  And, unless there is a strong reason otherwise, they should be no-ops outside of the core classes (i.e., the BCP).

I now don my asbestos smoking jacket.

? John

[1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible hack.  Which is an implementation artifact that could easily break by accident.  If you use that hack, you should move your code to BCP.

[2] http://www.cplusplus.com/forum/general/8225/

From dl at cs.oswego.edu  Tue Dec  4 16:08:43 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 04 Dec 2012 19:08:43 -0500
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
Message-ID: <50BE908B.3040305@cs.oswego.edu>

On 12/04/12 18:46, John Rose wrote:

> I don't mean to add insult to injury, but I think there is yet another
> restriction that we should place this annotation under, in its current residence
> of sun.misc.
>
> The annotation must be documented as being a no-op when it occurs inside class
> files that are loaded outside the boot class path.
>
> This is consistent with comments made by several other people, that these tools
> are intended, at least at first, for developers of core classes.  This is also
> consistent with Unsafe, which (however popular it is) is designed to be used
> core classes only, on the BCP (boot class path).[1]

I'm basically OK with this.
(Which in juxtaposition with Kirk's post says: Yes, some of
us need these things so desperately that we are willing to
live with ridiculous restrictions.)

I do worry about the tiny community of "external" low-level
Java hackers that I should stick up for though. (Examples:
The Disrupter and Akka folks, those doing in-house financials and
analytics.) Experience shows that they are also willing to go
through ridiculous hurdles so they can write high-performance
software on JVMs. But a *guarantee* of no effect might be crossing
that line. Any ideas?


> [1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible hack.
>   Which is an implementation artifact that could easily break by accident.  If
> you use that hack, you should move your code to BCP.
>

Which is the trick we use to put out our pre-openjdk-integration
preview packages. So we'd have to find another trick...

-Doug



From vitalyd at gmail.com  Tue Dec  4 16:24:27 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 4 Dec 2012 19:24:27 -0500
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
Message-ID: <CAHjP37HePiGW7wFpc1kht6Pi95Huo+CEJTFzb+OjboTU49Pspw@mail.gmail.com>

John,

What is driving this eagerness to hide away this feature? Is it Oracle
support concern? Is it fear of having to support this in future versions?
I'm a bit puzzled on the concerns expressed here and on other threads given
this is being put into sun.misc, which already comes with a "you're on your
own" label (including no promise of source or binary backwards
compatibility).  What am I missing? Can anyone actually describe a
realistic scenario where this will cause grave harm if allowed in sun.misc?

Thanks

Sent from my phone
On Dec 4, 2012 6:47 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 27, 2012, at 3:35 AM, Doug Lea wrote:
>
> > And, as someone else noted, sun.misc (where Unsafe lives) is even
> > more exotic, and has the audience of low-level/core developers
> > that this targets. Placing it there would get us past all the
> > concerns (that I honestly think are wrong) about sending the
> > wrong message or precluding miraculous automation. So, how
> > about we just live with it as follows:
>
> I don't mean to add insult to injury, but I think there is yet another
> restriction that we should place this annotation under, in its current
> residence of sun.misc.
>
> The annotation must be documented as being a no-op when it occurs inside
> class files that are loaded outside the boot class path.
>
> This is consistent with comments made by several other people, that these
> tools are intended, at least at first, for developers of core classes.
>  This is also consistent with Unsafe, which (however popular it is) is
> designed to be used core classes only, on the BCP (boot class path).[1]
>
> For JSR 292 we are likely to introduce @ForceInline, @Stable, and some
> other annotations into sun.misc.  They will be restricted to BCP classes
> only, and may go away in the future.  How fast do you think people would
> pollute their code with @ForceInline if it was effective outside of core
> classes?  We need hooks for system-specific tuning (when the JIT is part of
> the tuned system) but we do not want a "register" keyword[2] to become part
> of Java lore.
>
> At the same time the annotation is sufficiently understood to be exported
> more widely, it can be enabled off the BCP.  I think we need a module
> system in place to do a good job of this.  (And, yes, Unsafe should also be
> importable as a module of some sort.)
>
> The bottom line is that sun.misc is a good place for vetting experimental
> annotations.  And, unless there is a strong reason otherwise, they should
> be no-ops outside of the core classes (i.e., the BCP).
>
> I now don my asbestos smoking jacket.
>
> ? John
>
> [1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible
> hack.  Which is an implementation artifact that could easily break by
> accident.  If you use that hack, you should move your code to BCP.
>
> [2] http://www.cplusplus.com/forum/general/8225/

From mikael.vidstedt at oracle.com  Tue Dec  4 16:32:13 2012
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 04 Dec 2012 16:32:13 -0800
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <20121203173122.95966787@eggemoggin.niobe.net>
References: <20121203173122.95966787@eggemoggin.niobe.net>
Message-ID: <50BE960D.80805@oracle.com>


Two minor suggestions:

I think the "Scope:" should be "JDK" and the "Component:" should 
probably be "vm/--".

Cheers,
Mikael

On 2012-12-03 09:31, mark.reinhold at oracle.com wrote:
> Posted: http://openjdk.java.net/jeps/171
>
> - Mark


From forax at univ-mlv.fr  Tue Dec  4 16:36:31 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 05 Dec 2012 01:36:31 +0100
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
Message-ID: <50BE970F.20603@univ-mlv.fr>

On 12/05/2012 12:46 AM, John Rose wrote:
> On Nov 27, 2012, at 3:35 AM, Doug Lea wrote:
>
>> And, as someone else noted, sun.misc (where Unsafe lives) is even
>> more exotic, and has the audience of low-level/core developers
>> that this targets. Placing it there would get us past all the
>> concerns (that I honestly think are wrong) about sending the
>> wrong message or precluding miraculous automation. So, how
>> about we just live with it as follows:
> I don't mean to add insult to injury, but I think there is yet another restriction that we should place this annotation under, in its current residence of sun.misc.
>
> The annotation must be documented as being a no-op when it occurs inside class files that are loaded outside the boot class path.

I will agree if it's a way to be sure that the boot class path will not 
be cut in small pieces by jigsaw.
What we really want here is a way to say that a module is tainted (like 
the linux kernel), and only tainted module have access to sun.misc.

>
> This is consistent with comments made by several other people, that these tools are intended, at least at first, for developers of core classes.  This is also consistent with Unsafe, which (however popular it is) is designed to be used core classes only, on the BCP (boot class path).[1]

I strongly disagree, dynamic langage runtimes are used from command line 
(so they can control the BCP) but also in JEE containers (no control).
I see your proposal as a way to create work for a lot of support team to 
figure out why there is performance regression when users they don't 
start their favourite languages using the command line.
>
> For JSR 292 we are likely to introduce @ForceInline, @Stable, and some other annotations into sun.misc.  They will be restricted to BCP classes only, and may go away in the future.  How fast do you think people would pollute their code with @ForceInline if it was effective outside of core classes?  We need hooks for system-specific tuning (when the JIT is part of the tuned system) but we do not want a "register" keyword[2] to become part of Java lore.

You can already force inlining using a text file. I show that to my 
students and they don't use it after the lab because it's so easy to 
reach the max number of nodes that you can not use it on a large scale. 
Microsoft as introduced this feature in their latest version .Net [1] 
and nobody cares.
Being in sun.misc is in my opinion enough.

>
> At the same time the annotation is sufficiently understood to be exported more widely, it can be enabled off the BCP.  I think we need a module system in place to do a good job of this.  (And, yes, Unsafe should also be importable as a module of some sort.)
>
> The bottom line is that sun.misc is a good place for vetting experimental annotations.  And, unless there is a strong reason otherwise, they should be no-ops outside of the core classes (i.e., the BCP).
>
> I now don my asbestos smoking jacket.
>
> ? John
>
> [1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible hack.  Which is an implementation artifact that could easily break by accident.  If you use that hack, you should move your code to BCP.
>
> [2] http://www.cplusplus.com/forum/general/8225/

R?mi

[1] 
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions%28v=vs.110%29.aspx


From david.holmes at oracle.com  Tue Dec  4 21:25:50 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 05 Dec 2012 15:25:50 +1000
Subject: Profiles update to jdk8-b66
In-Reply-To: <50BC0678.1040300@oracle.com>
References: <50BC0678.1040300@oracle.com>
Message-ID: <50BEDADE.40301@oracle.com>

Just FYI the Profiles forest has been updated to the jdk8-b66 level.

Aside from that, recent changes include:

- javac support for -profile flag
- keytool is now part of profile compact1
- Fix for FDS to ensure configure settings make their way through to hotspot

David

From david.holmes at oracle.com  Tue Dec  4 21:42:33 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 05 Dec 2012 15:42:33 +1000
Subject: RFR(XXS): 8001028: Improve GC option handling
In-Reply-To: <50BE7F52.6040404@oracle.com>
References: <50BE7F52.6040404@oracle.com>
Message-ID: <50BEDEC9.3030509@oracle.com>

Thanks John, I've officially Reviewed it.

As I've said internally I won't be surprised if there is some 
obscure/unusual use of flags or agents or some other debugging thing 
that is affected by this. But it seems unlikely and it is much nicer to 
have the VM fail cleanly than crash bizarrely. For the reader another 
way this easily manifest this is if you have a low "maximum number of 
user processes" limit on linux and are near that limit when you try to 
launch the VM.

David

On 5/12/2012 8:55 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple volunteers review the changes for this CR? The
> webrev can be found at: http://cr.openjdk.java.net/~johnc/8001028/webrev.0/
>
> Summary:
> When the JVM is starting up on a system that is out of native resources
> (perhaps as the result of the user specifying too large a number of GC
> threads), the creation of the Finalizer thread can fail. When this
> happens the JVM attempts to throw an out of memory error which can lead
> to assertion failures and crashes because the class for java.lang.Class
> has not yet been initialized. Changing the initialization order so that
> the initialization of java.lang.Class comes before
> java.lang.ref.Finalizer allows the JVM to exit in a more orderly fashion.
>
> Testing:
> Command line testing with some code inserted into the thread creation
> code to force ENOMEM returns; jprt; nsk gc, jit, regression tests.
>
> This change has already been reviewed internally so I'm interested in
> hearing from folks who might be affected by the change in initialization
> order.
>
> Thanks,
>
> JohnC
>

From mikeb01 at gmail.com  Tue Dec  4 23:20:47 2012
From: mikeb01 at gmail.com (Michael Barker)
Date: Wed, 5 Dec 2012 07:20:47 +0000
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <50BE908B.3040305@cs.oswego.edu>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
Message-ID: <CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>

>> I don't mean to add insult to injury, but I think there is yet another
>> restriction that we should place this annotation under, in its current
>> residence
>> of sun.misc.
>>
>> The annotation must be documented as being a no-op when it occurs inside
>> class
>> files that are loaded outside the boot class path.
>>
>> This is consistent with comments made by several other people, that these
>> tools
>> are intended, at least at first, for developers of core classes.  This is
>> also
>> consistent with Unsafe, which (however popular it is) is designed to be
>> used
>> core classes only, on the BCP (boot class path).[1]

*sigh*.

> I'm basically OK with this.
> (Which in juxtaposition with Kirk's post says: Yes, some of
> us need these things so desperately that we are willing to
> live with ridiculous restrictions.)
>
> I do worry about the tiny community of "external" low-level
> Java hackers that I should stick up for though. (Examples:
> The Disrupter and Akka folks, those doing in-house financials and
> analytics.) Experience shows that they are also willing to go
> through ridiculous hurdles so they can write high-performance
> software on JVMs. But a *guarantee* of no effect might be crossing
> that line. Any ideas?

As part of the tiny community (I'm the current lead developer of the
Disruptor), I would really like this tool to be made available
directly (don't really care what package it's in*, I use the Unsafe
already).  If this annotation was unavailable to me, then a
significant portion of my use cases would be covered if the value
field in AtomicLong was marked @Contended.  For the rest I'd fall back
to doing the padding manually and just pray that Hotspot doesn't
remove my additional fields or pay the cost of the indirection off to
an array (or switch to C#[1] ;-).

Here's were I'm confused by the idea of restricting it's use to core
libraries:  I'm going to do it anyway!  And I'll do it in horrible
ways that the VM has no chance of optimising, because it has no idea
about the intent.  I'll pessimistically add additional padding to
cover the worst case as we don't know the cache line size nor can I
allocate the field aligned on a cache line boundary.  If only there
was a way to tell the VM what I really wanted...

Mike.

*Personally I don't think that sun.misc means anything at all.
There's nothing in the name that suggests to me that it shouldn't be
used.  It's the "Unsafe" part of sun.misc.Unsafe that provides the big
hint to the user.

[1] http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute.aspx

From david.holmes at oracle.com  Tue Dec  4 23:54:13 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 05 Dec 2012 17:54:13 +1000
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
Message-ID: <50BEFDA5.2090904@oracle.com>

 > *Personally I don't think that sun.misc means anything at all.
 > There's nothing in the name that suggests to me that it shouldn't be
 > used.

It's the sun. part that says "don't use this". You get a warning 
everytime you compile against it and you have to force the compiler to 
let you access it.

David

On 5/12/2012 5:20 PM, Michael Barker wrote:
>>> I don't mean to add insult to injury, but I think there is yet another
>>> restriction that we should place this annotation under, in its current
>>> residence
>>> of sun.misc.
>>>
>>> The annotation must be documented as being a no-op when it occurs inside
>>> class
>>> files that are loaded outside the boot class path.
>>>
>>> This is consistent with comments made by several other people, that these
>>> tools
>>> are intended, at least at first, for developers of core classes.  This is
>>> also
>>> consistent with Unsafe, which (however popular it is) is designed to be
>>> used
>>> core classes only, on the BCP (boot class path).[1]
>
> *sigh*.
>
>> I'm basically OK with this.
>> (Which in juxtaposition with Kirk's post says: Yes, some of
>> us need these things so desperately that we are willing to
>> live with ridiculous restrictions.)
>>
>> I do worry about the tiny community of "external" low-level
>> Java hackers that I should stick up for though. (Examples:
>> The Disrupter and Akka folks, those doing in-house financials and
>> analytics.) Experience shows that they are also willing to go
>> through ridiculous hurdles so they can write high-performance
>> software on JVMs. But a *guarantee* of no effect might be crossing
>> that line. Any ideas?
>
> As part of the tiny community (I'm the current lead developer of the
> Disruptor), I would really like this tool to be made available
> directly (don't really care what package it's in*, I use the Unsafe
> already).  If this annotation was unavailable to me, then a
> significant portion of my use cases would be covered if the value
> field in AtomicLong was marked @Contended.  For the rest I'd fall back
> to doing the padding manually and just pray that Hotspot doesn't
> remove my additional fields or pay the cost of the indirection off to
> an array (or switch to C#[1] ;-).
>
> Here's were I'm confused by the idea of restricting it's use to core
> libraries:  I'm going to do it anyway!  And I'll do it in horrible
> ways that the VM has no chance of optimising, because it has no idea
> about the intent.  I'll pessimistically add additional padding to
> cover the worst case as we don't know the cache line size nor can I
> allocate the field aligned on a cache line boundary.  If only there
> was a way to tell the VM what I really wanted...
>
> Mike.
>
> *Personally I don't think that sun.misc means anything at all.
> There's nothing in the name that suggests to me that it shouldn't be
> used.  It's the "Unsafe" part of sun.misc.Unsafe that provides the big
> hint to the user.
>
> [1] http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute.aspx

From dl at cs.oswego.edu  Wed Dec  5 03:16:40 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 05 Dec 2012 06:16:40 -0500
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
Message-ID: <50BF2D18.1090702@cs.oswego.edu>

On 12/05/12 02:20, Michael Barker wrote:

>> But a *guarantee* of no effect might be crossing
>> that line. Any ideas?
>
> As part of the tiny community (I'm the current lead developer of the
> Disruptor), I would really like this tool to be made available
> directly (don't really care what package it's in*, I use the Unsafe
> already).  If this annotation was unavailable to me, then a
> significant portion of my use cases would be covered if the value
> field in AtomicLong was marked @Contended.

Mostly as an aside: We wouldn't do this by default for
AtomicInteger etc, to avoid surprises for existing users,
but would make available alternate classes that do.

>
> Here's were I'm confused by the idea of restricting it's use to core
> libraries:

I think John's point/view is that if you have components
that are explicitly in JVMese, not Java (i.e., that use sun.misc),
then you are by definition providing a "core library" and
users should be forced to be aware of it by requiring
a bootclasspath VM switch to run. This would be a less
controversial idea if it were not for all the cases that arise
in practice where other factors make it impossible for the
actual users of the functionality to control JVM startup
settings. Which ends up making this proposed rule overly
hostile in its practical effect.

So I think that wording things so as to make no promises
in these cases (and to not force the VM to make special
efforts to see if it must ignore @Contended), rather than to
promise no effect, is the best compromise available.

-Doug







From gary.collins at oracle.com  Wed Dec  5 09:46:38 2012
From: gary.collins at oracle.com (Gary Collins)
Date: Wed, 5 Dec 2012 09:46:38 -0800
Subject: Profiles update to jdk8-b66
In-Reply-To: <50BEDADE.40301@oracle.com>
References: <50BC0678.1040300@oracle.com> <50BEDADE.40301@oracle.com>
Message-ID: <F42C95BA-4544-4867-839E-3C7BFF8D84D5@oracle.com>

Awesome job!

Thanks David!

Gary
On Dec 4, 2012, at 9:25 PM, David Holmes wrote:

> Just FYI the Profiles forest has been updated to the jdk8-b66 level.
> 
> Aside from that, recent changes include:
> 
> - javac support for -profile flag
> - keytool is now part of profile compact1
> - Fix for FDS to ensure configure settings make their way through to hotspot
> 
> David


From david.holmes at oracle.com  Wed Dec  5 20:57:45 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 06 Dec 2012 14:57:45 +1000
Subject: fastdebug vs jvmg
In-Reply-To: <B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
Message-ID: <50C025C9.20902@oracle.com>

First note that Jesper's email is from Oct 31 and only just turned up! 
Either that or he has a clock issue on his system :)

On 6/12/2012 8:25 AM, Kelly O'Hair wrote:
> On Oct 31, 2012, at 5:26 AM, Jesper Wilhelmsson wrote:
>> Then I reconfigured with --enable-debug.
>>
>> --enable-debug currently configures hotspot to build with the build target fastdebug. fastdebug isn't really fast since asserts are turned on, and it can't be used for debugging since the code is optimized, so the name is a bit misleading. Personally I always use jvmg when debugging and testing.
>
> But the debug build has asserts on too, doesn't it? It should.
>
>>
>> I asked around the Stockholm office and it seems as most people here would prefer jvmg. It seems as jvmg is very slow on Mac so those who work on Mac only uses jvmg when debugging for real, not for regular testing, but otherwise fastdebug is rarely used here.
>
> A long time ago, in a land far far away, fastdebug was pretty good on Solaris, using dbx, worked really well, not perfect but pretty good.
> Since then, Linux was added, and gdb is needed, and Mac too, so we have many native code debuggers to deal with now.
> Also since then, machines have gotten faster, and disks are fatter and faster, and maybe fastdebug has lost it's benefit.
> Testing the debug build is pretty impossible, or was, it just was way too slow, maybe 100x slower than a product build.
> But fastdebug was possible, maybe 10x slower than a product build.
> So I have always assumed that fastdebug was faster than a debug build.
> But who knows what the performance is now. I think I was always looking at an entire JDK built with product vs. debug vs. fastdebug
> not just hotspot, although hotspot was usually the piece that cause performance issues.

I admit we probably haven't run a comparison against fastdebug and jvmg 
recently (especially as jvmg was dropped for a while and only came back 
when it was thought we might extend hotspot-express to JDK 5!) but I 
think the hotspot team will be shocked to discover that fastdebug is 
slower than jvmg. fastdebug is supposed to be faster than debug because 
it still uses the OPT_CFLAGS, not DEBUG_CFLAGS, while also allowing a 
certain level of debugging (and having asserts enabled as does jvmg).

David
-----

> If all this has changed, then we should re-consider what we build and test.
>
> I think it was always agreed that the asserts were invaluable, so we need to keep that on in some build.
>
> -kto
>
>>
>> Cheers,
>> /Jesper
>>
>

From dmitry.samersoff at oracle.com  Wed Dec  5 23:59:33 2012
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 06 Dec 2012 11:59:33 +0400
Subject: fastdebug vs jvmg
In-Reply-To: <50C025C9.20902@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com>
Message-ID: <50C05065.7070805@oracle.com>

David,

The question is whether we need fastdebug as a separate item, or
something like --enable-asserts --enable-non-product-flags is enough.

Most of JVM bugs I worked with couldn't be reproduced with debug VM so I
almost always end up to instrumented product build.

-Dmitry


On 2012-12-06 08:57, David Holmes wrote:
> First note that Jesper's email is from Oct 31 and only just turned up!
> Either that or he has a clock issue on his system :)
> 
> On 6/12/2012 8:25 AM, Kelly O'Hair wrote:
>> On Oct 31, 2012, at 5:26 AM, Jesper Wilhelmsson wrote:
>>> Then I reconfigured with --enable-debug.
>>>
>>> --enable-debug currently configures hotspot to build with the build
>>> target fastdebug. fastdebug isn't really fast since asserts are
>>> turned on, and it can't be used for debugging since the code is
>>> optimized, so the name is a bit misleading. Personally I always use
>>> jvmg when debugging and testing.
>>
>> But the debug build has asserts on too, doesn't it? It should.
>>
>>>
>>> I asked around the Stockholm office and it seems as most people here
>>> would prefer jvmg. It seems as jvmg is very slow on Mac so those who
>>> work on Mac only uses jvmg when debugging for real, not for regular
>>> testing, but otherwise fastdebug is rarely used here.
>>
>> A long time ago, in a land far far away, fastdebug was pretty good on
>> Solaris, using dbx, worked really well, not perfect but pretty good.
>> Since then, Linux was added, and gdb is needed, and Mac too, so we
>> have many native code debuggers to deal with now.
>> Also since then, machines have gotten faster, and disks are fatter and
>> faster, and maybe fastdebug has lost it's benefit.
>> Testing the debug build is pretty impossible, or was, it just was way
>> too slow, maybe 100x slower than a product build.
>> But fastdebug was possible, maybe 10x slower than a product build.
>> So I have always assumed that fastdebug was faster than a debug build.
>> But who knows what the performance is now. I think I was always
>> looking at an entire JDK built with product vs. debug vs. fastdebug
>> not just hotspot, although hotspot was usually the piece that cause
>> performance issues.
> 
> I admit we probably haven't run a comparison against fastdebug and jvmg
> recently (especially as jvmg was dropped for a while and only came back
> when it was thought we might extend hotspot-express to JDK 5!) but I
> think the hotspot team will be shocked to discover that fastdebug is
> slower than jvmg. fastdebug is supposed to be faster than debug because
> it still uses the OPT_CFLAGS, not DEBUG_CFLAGS, while also allowing a
> certain level of debugging (and having asserts enabled as does jvmg).
> 
> David
> -----
> 
>> If all this has changed, then we should re-consider what we build and
>> test.
>>
>> I think it was always agreed that the asserts were invaluable, so we
>> need to keep that on in some build.
>>
>> -kto
>>
>>>
>>> Cheers,
>>> /Jesper
>>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer

From mikeb01 at gmail.com  Thu Dec  6 01:31:24 2012
From: mikeb01 at gmail.com (Michael Barker)
Date: Thu, 6 Dec 2012 09:31:24 +0000
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <50BF2D18.1090702@cs.oswego.edu>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
	<50BF2D18.1090702@cs.oswego.edu>
Message-ID: <CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>

> Mostly as an aside: We wouldn't do this by default for
> AtomicInteger etc, to avoid surprises for existing users,
> but would make available alternate classes that do.

Make's sense.

> I think John's point/view is that if you have components
> that are explicitly in JVMese, not Java (i.e., that use sun.misc),
> then you are by definition providing a "core library" and
> users should be forced to be aware of it by requiring
> a bootclasspath VM switch to run. This would be a less
> controversial idea if it were not for all the cases that arise
> in practice where other factors make it impossible for the
> actual users of the functionality to control JVM startup
> settings. Which ends up making this proposed rule overly
> hostile in its practical effect.

I agree, almost to the point where it wouldn't worth the effort to
produce a JDK8+ specific implementation of the Disruptor (or any other
re-usable library) that used @Contended instead of the manual padding.
 I think users would follow the path of least resistance and use the
one with manual padding.  Admittedly I'm guessing, so I'll definitely
attempt to use this when it comes available and measure the uptake.

A middle ground I could live with would be something like
-XX:(+/-)RestrictContendedToBootClassPath (preferably with the default
as off).  Adding/removing a switch of that nature is operationally
simpler than fiddling with file locations and classpath settings.

> So I think that wording things so as to make no promises
> in these cases (and to not force the VM to make special
> efforts to see if it must ignore @Contended), rather than to
> promise no effect, is the best compromise available.

I can understand the necessity of not speccing the JVM into a corner.
What I'm hoping is that in practice is that by default it will provide
the behaviour that it suggests, i.e. false sharing is prevented on the
areas where I know they could be contented.  I'll just find a way
verify the behaviour before each production release and be able to
document which configurations work.

Mike.

From volker.simonis at gmail.com  Thu Dec  6 02:20:15 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 6 Dec 2012 11:20:15 +0100
Subject: fastdebug vs jvmg
In-Reply-To: <50C025C9.20902@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com>
Message-ID: <CA+3eh12OOA2Wviqd=7ybKLK_8JSZ=CuZyN8C-b5SKr_ZXB-Cng@mail.gmail.com>

Hi,

I can confirm that fastdebug is at least an order of magnitude faster
than debug and as such it is the only practicable way to do automatic
testing with assertions turned on. On the other hand, on most
platforms you really need a true debug build to get a decent debugging
experience.

So we daily build product and fastdebug configurations by default for
automatic testing but developers usually build a true debug (jvmg)
build for their daily work.

Regards,
Volker


On Thu, Dec 6, 2012 at 5:57 AM, David Holmes <david.holmes at oracle.com> wrote:
> First note that Jesper's email is from Oct 31 and only just turned up!
> Either that or he has a clock issue on his system :)
>
> On 6/12/2012 8:25 AM, Kelly O'Hair wrote:
>>
>> On Oct 31, 2012, at 5:26 AM, Jesper Wilhelmsson wrote:
>>>
>>> Then I reconfigured with --enable-debug.
>>>
>>> --enable-debug currently configures hotspot to build with the build
>>> target fastdebug. fastdebug isn't really fast since asserts are turned on,
>>> and it can't be used for debugging since the code is optimized, so the name
>>> is a bit misleading. Personally I always use jvmg when debugging and
>>> testing.
>>
>>
>> But the debug build has asserts on too, doesn't it? It should.
>>
>>>
>>> I asked around the Stockholm office and it seems as most people here
>>> would prefer jvmg. It seems as jvmg is very slow on Mac so those who work on
>>> Mac only uses jvmg when debugging for real, not for regular testing, but
>>> otherwise fastdebug is rarely used here.
>>
>>
>> A long time ago, in a land far far away, fastdebug was pretty good on
>> Solaris, using dbx, worked really well, not perfect but pretty good.
>> Since then, Linux was added, and gdb is needed, and Mac too, so we have
>> many native code debuggers to deal with now.
>> Also since then, machines have gotten faster, and disks are fatter and
>> faster, and maybe fastdebug has lost it's benefit.
>> Testing the debug build is pretty impossible, or was, it just was way too
>> slow, maybe 100x slower than a product build.
>> But fastdebug was possible, maybe 10x slower than a product build.
>> So I have always assumed that fastdebug was faster than a debug build.
>> But who knows what the performance is now. I think I was always looking at
>> an entire JDK built with product vs. debug vs. fastdebug
>> not just hotspot, although hotspot was usually the piece that cause
>> performance issues.
>
>
> I admit we probably haven't run a comparison against fastdebug and jvmg
> recently (especially as jvmg was dropped for a while and only came back when
> it was thought we might extend hotspot-express to JDK 5!) but I think the
> hotspot team will be shocked to discover that fastdebug is slower than jvmg.
> fastdebug is supposed to be faster than debug because it still uses the
> OPT_CFLAGS, not DEBUG_CFLAGS, while also allowing a certain level of
> debugging (and having asserts enabled as does jvmg).
>
> David
> -----
>
>> If all this has changed, then we should re-consider what we build and
>> test.
>>
>> I think it was always agreed that the asserts were invaluable, so we need
>> to keep that on in some build.
>>
>> -kto
>>
>>>
>>> Cheers,
>>> /Jesper
>>>
>>
>

From Ulf.Zibis at CoSoCo.de  Thu Dec  6 04:16:22 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 06 Dec 2012 13:16:22 +0100
Subject: fastdebug vs jvmg
In-Reply-To: <CA+3eh12OOA2Wviqd=7ybKLK_8JSZ=CuZyN8C-b5SKr_ZXB-Cng@mail.gmail.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com>
	<CA+3eh12OOA2Wviqd=7ybKLK_8JSZ=CuZyN8C-b5SKr_ZXB-Cng@mail.gmail.com>
Message-ID: <50C08C96.7060101@CoSoCo.de>

Am 06.12.2012 11:20, schrieb Volker Simonis:
> So we daily build product and fastdebug configurations by default for
> automatic testing ...

Are these builds publicly available somewhere ?

Thanks,

Ulf


From aleksey.shipilev at oracle.com  Thu Dec  6 05:10:14 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 06 Dec 2012 17:10:14 +0400
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
	<50BF2D18.1090702@cs.oswego.edu>
	<CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
Message-ID: <50C09936.50201@oracle.com>

On 12/06/2012 01:31 PM, Michael Barker wrote:
> I agree, almost to the point where it wouldn't worth the effort to
> produce a JDK8+ specific implementation of the Disruptor (or any other
> re-usable library) that used @Contended instead of the manual padding.
>  I think users would follow the path of least resistance and use the
> one with manual padding.  Admittedly I'm guessing, so I'll definitely
> attempt to use this when it comes available and measure the uptake.

I've been asking this on concurrency-interest@, but let's go through
this here. Imagine some weird Christmas miracle had happened, and
@Contended is actually available starting some JDK 7 update. Will that
change anything in the adoption scenarios we are speculating now?

-Aleksey.

From daniel.daugherty at oracle.com  Thu Dec  6 07:13:51 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 06 Dec 2012 08:13:51 -0700
Subject: fastdebug vs jvmg
In-Reply-To: <50C025C9.20902@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com>
Message-ID: <50C0B62F.1010507@oracle.com>

One clarification:

 > (especially as jvmg was dropped for a while and only came back
 > when it was thought we might extend hotspot-express to JDK 5!)

The "jvmg" build config was never dropped. Some of the platforms
in the internal JPRT system still build three configs: product,
fastdebug and jvmg. Just to make things confusing: the "jvmg" config
is called the "debug" config on Windows. I really, really hope that
the new build-infra system will fix that naming anomaly.

What was dropped was the generation and use of binaries with the
"_g" suffix, e.g., java_g, libjvm_g.so, etc. HotSpot did bring that
back for a while in a limited form and it is about to go away again:

     7153050 remove crufty '_g' support from HotSpot repo

Ron Durbin is putting the finishes touches on his fix for 7153050.

One reminder:

When Full Debug Symbols (FDS) is enabled, product and fastdebug
builds use the same debug and optimization flags. So the big
difference between product and fastdebug is now just the asserts
and any NOT_PRODUCT code.

Dan



On 12/5/12 9:57 PM, David Holmes wrote:
> First note that Jesper's email is from Oct 31 and only just turned up! 
> Either that or he has a clock issue on his system :)
>
> On 6/12/2012 8:25 AM, Kelly O'Hair wrote:
>> On Oct 31, 2012, at 5:26 AM, Jesper Wilhelmsson wrote:
>>> Then I reconfigured with --enable-debug.
>>>
>>> --enable-debug currently configures hotspot to build with the build 
>>> target fastdebug. fastdebug isn't really fast since asserts are 
>>> turned on, and it can't be used for debugging since the code is 
>>> optimized, so the name is a bit misleading. Personally I always use 
>>> jvmg when debugging and testing.
>>
>> But the debug build has asserts on too, doesn't it? It should.
>>
>>>
>>> I asked around the Stockholm office and it seems as most people here 
>>> would prefer jvmg. It seems as jvmg is very slow on Mac so those who 
>>> work on Mac only uses jvmg when debugging for real, not for regular 
>>> testing, but otherwise fastdebug is rarely used here.
>>
>> A long time ago, in a land far far away, fastdebug was pretty good on 
>> Solaris, using dbx, worked really well, not perfect but pretty good.
>> Since then, Linux was added, and gdb is needed, and Mac too, so we 
>> have many native code debuggers to deal with now.
>> Also since then, machines have gotten faster, and disks are fatter 
>> and faster, and maybe fastdebug has lost it's benefit.
>> Testing the debug build is pretty impossible, or was, it just was way 
>> too slow, maybe 100x slower than a product build.
>> But fastdebug was possible, maybe 10x slower than a product build.
>> So I have always assumed that fastdebug was faster than a debug build.
>> But who knows what the performance is now. I think I was always 
>> looking at an entire JDK built with product vs. debug vs. fastdebug
>> not just hotspot, although hotspot was usually the piece that cause 
>> performance issues.
>
> I admit we probably haven't run a comparison against fastdebug and 
> jvmg recently (especially as jvmg was dropped for a while and only 
> came back when it was thought we might extend hotspot-express to JDK 
> 5!) but I think the hotspot team will be shocked to discover that 
> fastdebug is slower than jvmg. fastdebug is supposed to be faster than 
> debug because it still uses the OPT_CFLAGS, not DEBUG_CFLAGS, while 
> also allowing a certain level of debugging (and having asserts enabled 
> as does jvmg).
>
> David
> -----
>
>> If all this has changed, then we should re-consider what we build and 
>> test.
>>
>> I think it was always agreed that the asserts were invaluable, so we 
>> need to keep that on in some build.
>>
>> -kto
>>
>>>
>>> Cheers,
>>> /Jesper
>>>
>>


From karen.kinnear at oracle.com  Thu Dec  6 07:20:59 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 6 Dec 2012 10:20:59 -0500
Subject: fastdebug vs jvmg
In-Reply-To: <50C0B62F.1010507@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com> <50C0B62F.1010507@oracle.com>
Message-ID: <021287DF-E2D9-419D-BC30-B589A3F56EC4@oracle.com>

My personal testing on solaris-sparc this week found that fastdebug ran much faster than
jvmg. 

thanks,
Karen

On Dec 6, 2012, at 10:13 AM, Daniel D. Daugherty wrote:

> One clarification:
> 
> > (especially as jvmg was dropped for a while and only came back
> > when it was thought we might extend hotspot-express to JDK 5!)
> 
> The "jvmg" build config was never dropped. Some of the platforms
> in the internal JPRT system still build three configs: product,
> fastdebug and jvmg. Just to make things confusing: the "jvmg" config
> is called the "debug" config on Windows. I really, really hope that
> the new build-infra system will fix that naming anomaly.
> 
> What was dropped was the generation and use of binaries with the
> "_g" suffix, e.g., java_g, libjvm_g.so, etc. HotSpot did bring that
> back for a while in a limited form and it is about to go away again:
> 
>    7153050 remove crufty '_g' support from HotSpot repo
> 
> Ron Durbin is putting the finishes touches on his fix for 7153050.
> 
> One reminder:
> 
> When Full Debug Symbols (FDS) is enabled, product and fastdebug
> builds use the same debug and optimization flags. So the big
> difference between product and fastdebug is now just the asserts
> and any NOT_PRODUCT code.
> 
> Dan
> 
> 
> 
> On 12/5/12 9:57 PM, David Holmes wrote:
>> First note that Jesper's email is from Oct 31 and only just turned up! Either that or he has a clock issue on his system :)
>> 
>> On 6/12/2012 8:25 AM, Kelly O'Hair wrote:
>>> On Oct 31, 2012, at 5:26 AM, Jesper Wilhelmsson wrote:
>>>> Then I reconfigured with --enable-debug.
>>>> 
>>>> --enable-debug currently configures hotspot to build with the build target fastdebug. fastdebug isn't really fast since asserts are turned on, and it can't be used for debugging since the code is optimized, so the name is a bit misleading. Personally I always use jvmg when debugging and testing.
>>> 
>>> But the debug build has asserts on too, doesn't it? It should.
>>> 
>>>> 
>>>> I asked around the Stockholm office and it seems as most people here would prefer jvmg. It seems as jvmg is very slow on Mac so those who work on Mac only uses jvmg when debugging for real, not for regular testing, but otherwise fastdebug is rarely used here.
>>> 
>>> A long time ago, in a land far far away, fastdebug was pretty good on Solaris, using dbx, worked really well, not perfect but pretty good.
>>> Since then, Linux was added, and gdb is needed, and Mac too, so we have many native code debuggers to deal with now.
>>> Also since then, machines have gotten faster, and disks are fatter and faster, and maybe fastdebug has lost it's benefit.
>>> Testing the debug build is pretty impossible, or was, it just was way too slow, maybe 100x slower than a product build.
>>> But fastdebug was possible, maybe 10x slower than a product build.
>>> So I have always assumed that fastdebug was faster than a debug build.
>>> But who knows what the performance is now. I think I was always looking at an entire JDK built with product vs. debug vs. fastdebug
>>> not just hotspot, although hotspot was usually the piece that cause performance issues.
>> 
>> I admit we probably haven't run a comparison against fastdebug and jvmg recently (especially as jvmg was dropped for a while and only came back when it was thought we might extend hotspot-express to JDK 5!) but I think the hotspot team will be shocked to discover that fastdebug is slower than jvmg. fastdebug is supposed to be faster than debug because it still uses the OPT_CFLAGS, not DEBUG_CFLAGS, while also allowing a certain level of debugging (and having asserts enabled as does jvmg).
>> 
>> David
>> -----
>> 
>>> If all this has changed, then we should re-consider what we build and test.
>>> 
>>> I think it was always agreed that the asserts were invaluable, so we need to keep that on in some build.
>>> 
>>> -kto
>>> 
>>>> 
>>>> Cheers,
>>>> /Jesper
>>>> 
>>> 
> 


From mikeb01 at gmail.com  Thu Dec  6 08:10:43 2012
From: mikeb01 at gmail.com (Michael Barker)
Date: Thu, 6 Dec 2012 16:10:43 +0000
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <50C09936.50201@oracle.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
	<50BF2D18.1090702@cs.oswego.edu>
	<CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
	<50C09936.50201@oracle.com>
Message-ID: <CALwNKeSZxS43XJn3m_D-gS2J3yfZ-t-d_K_w5x4jXjdXPf7N7g@mail.gmail.com>

> I've been asking this on concurrency-interest@, but let's go through
> this here. Imagine some weird Christmas miracle had happened, and
> @Contended is actually available starting some JDK 7 update. Will that
> change anything in the adoption scenarios we are speculating now?

If @Contended was implemented with the bootclasspath restriction
(which I hope it isn't) then it would allow me to measure how much
this is a problem for individual users.

The advantage of this is that I'll probably need to maintain 2
versions of the code for some period of time and having @Contended in
JDK7 means that I could drop support for the older version sooner.

Mike.

From kelly.ohair at oracle.com  Thu Dec  6 10:07:52 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 6 Dec 2012 10:07:52 -0800
Subject: fastdebug vs jvmg
In-Reply-To: <50C0B62F.1010507@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com> <50C0B62F.1010507@oracle.com>
Message-ID: <B79D0674-E2AF-4E5F-92CF-D3560732EA6D@oracle.com>


On Dec 6, 2012, at 7:13 AM, Daniel D. Daugherty wrote:

> What was dropped was the generation and use of binaries with the
> "_g" suffix, e.g., java_g, libjvm_g.so, etc. HotSpot did bring that
> back for a while in a limited form and it is about to go away again:
> 
>    7153050 remove crufty '_g' support from HotSpot repo
> 
> Ron Durbin is putting the finishes touches on his fix for 7153050.

If anyone brings back these _g names again, I'll bring out my bloody bat
   http://weblogs.java.net/blog/kellyohair/archive/2006/02/the_bloody_bat.html

So, thank you Ron and everyone that ripped this crap out again. Having different names for
libraries and executables is a nightmare.

-kto


From kelly.ohair at oracle.com  Thu Dec  6 10:15:15 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Thu, 6 Dec 2012 10:15:15 -0800
Subject: fastdebug vs jvmg
In-Reply-To: <50C0B62F.1010507@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com> <50C0B62F.1010507@oracle.com>
Message-ID: <3D6B0AC2-6319-48B2-9E55-0D64F1AE2940@oracle.com>


On Dec 6, 2012, at 7:13 AM, Daniel D. Daugherty wrote:

> One reminder:
> 
> When Full Debug Symbols (FDS) is enabled, product and fastdebug
> builds use the same debug and optimization flags. So the big
> difference between product and fastdebug is now just the asserts
> and any NOT_PRODUCT code.
> 
> Dan

If all builds enable FDS, then all customers get that type of build, so why have the different optimizations without FDS?
Isn't that just opening up a variation that will cause confusion?
Can we just use one set of "optimization on" settings? Or is that a hot potato?

-kto


From daniel.daugherty at oracle.com  Thu Dec  6 10:47:47 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 06 Dec 2012 11:47:47 -0700
Subject: fastdebug vs jvmg
In-Reply-To: <B79D0674-E2AF-4E5F-92CF-D3560732EA6D@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com> <50C0B62F.1010507@oracle.com>
	<B79D0674-E2AF-4E5F-92CF-D3560732EA6D@oracle.com>
Message-ID: <50C0E853.6060900@oracle.com>

Forgot that Ron's not on the OpenJDK aliases yet...
so adding him...

Dan


On 12/6/12 11:07 AM, Kelly O'Hair wrote:
>
> On Dec 6, 2012, at 7:13 AM, Daniel D. Daugherty wrote:
>
>> What was dropped was the generation and use of binaries with the
>> "_g" suffix, e.g., java_g, libjvm_g.so, etc. HotSpot did bring that
>> back for a while in a limited form and it is about to go away again:
>>
>>    7153050 remove crufty '_g' support from HotSpot repo
>>
>> Ron Durbin is putting the finishes touches on his fix for 7153050.
>
> If anyone brings back these _g names again, I'll bring out my bloody bat
> http://weblogs.java.net/blog/kellyohair/archive/2006/02/the_bloody_bat.html
>
> So, thank you Ron and everyone that ripped this crap out again. Having 
> different names for
> libraries and executables is a nightmare.
>
> -kto
>


From daniel.daugherty at oracle.com  Thu Dec  6 10:52:05 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 06 Dec 2012 11:52:05 -0700
Subject: fastdebug vs jvmg
In-Reply-To: <3D6B0AC2-6319-48B2-9E55-0D64F1AE2940@oracle.com>
References: <509118FD.5010308@oracle.com>
	<B6E4D13B-90A3-4670-B6FE-52C82A3CE9F1@oracle.com>
	<50C025C9.20902@oracle.com> <50C0B62F.1010507@oracle.com>
	<3D6B0AC2-6319-48B2-9E55-0D64F1AE2940@oracle.com>
Message-ID: <50C0E955.6000506@oracle.com>

On 12/6/12 11:15 AM, Kelly O'Hair wrote:
>
> On Dec 6, 2012, at 7:13 AM, Daniel D. Daugherty wrote:
>
>> One reminder:
>>
>> When Full Debug Symbols (FDS) is enabled, product and fastdebug
>> builds use the same debug and optimization flags. So the big
>> difference between product and fastdebug is now just the asserts
>> and any NOT_PRODUCT code.
>>
>> Dan
>
> If all builds enable FDS, then all customers get that type of build, 
> so why have the different optimizations without FDS?
> Isn't that just opening up a variation that will cause confusion?
> Can we just use one set of "optimization on" settings? Or is that a 
> hot potato?

Hot potato, rat hole, religious crusade... take your pick.

There are developers that build HotSpot with FDS disabled because
the link phase takes longer than it used to. I have pointed out
that when they do that, their testing may not be valid since the
official push via JPRT or the official promotion from RE will
be built differently.

Some day we may get to the point where FDS-enabled is just the way
we build, but we aren't there yet.

Dan


From rkennke at redhat.com  Thu Dec  6 12:24:01 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 06 Dec 2012 21:24:01 +0100
Subject: RFR: Some build fixes for gcc4.7
Message-ID: <1354825441.1747.22.camel@mercury>

I posted part of this before in hotspot-gc-dev, without any reply yet.
(http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-November/005327.html) 


In any case, here is a more complete patch relating to build failures
with GCC 4.7. It's basically:

- Some more this-> qualifiers in binaryTreeDictionary.cpp (other such
qualifiers have been added before, those here probably slipped through
because they're only in asserts and compiled in debug builds.
- In library_call.cpp some return false should really be return NULL.
Also improves consistency in this code (other return statements in the
same method correctly return NULL).


Ok to go in?

http://cr.openjdk.java.net/~rkennke/gcc47/webrev.00/

Regards,
Roman



From john.cuthbertson at oracle.com  Thu Dec  6 14:08:05 2012
From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com)
Date: Thu, 06 Dec 2012 22:08:05 +0000
Subject: hg: hsx/hsx24/hotspot: 2 new changesets
Message-ID: <20121206220817.E76B447F5B@hg.openjdk.java.net>

Changeset: fd3cf9ada039
Author:    johnc
Date:      2012-12-06 11:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fd3cf9ada039

7194633: G1: Assertion and guarantee failures in block offset table
Summary: Add detailed error messages to assertions and guarantees in G1's block offset table.
Reviewed-by: ysr, brutisso

! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp
! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp
! src/share/vm/memory/space.cpp

Changeset: 8e478700068f
Author:    johnc
Date:      2012-12-06 11:26 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8e478700068f

8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8
Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor.
Reviewed-by: jwilhelm, azeemj, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/timer.cpp


From coleen.phillimore at oracle.com  Thu Dec  6 15:40:19 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 06 Dec 2012 18:40:19 -0500
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <1354825441.1747.22.camel@mercury>
References: <1354825441.1747.22.camel@mercury>
Message-ID: <50C12CE3.2050907@oracle.com>


The changes to binaryTreeDictionary.cpp are already in the hotspot-gc 
repository and will/have been pushed up to main already. They should 
already be in hotspot-comp.

Which compiler complains about the library_call.cpp changes?  I have an 
unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this 
file compiles fine for me as is.

Thanks,
Coleen


On 12/06/2012 03:24 PM, Roman Kennke wrote:
> I posted part of this before in hotspot-gc-dev, without any reply yet.
> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-November/005327.html)
>
>
> In any case, here is a more complete patch relating to build failures
> with GCC 4.7. It's basically:
>
> - Some more this-> qualifiers in binaryTreeDictionary.cpp (other such
> qualifiers have been added before, those here probably slipped through
> because they're only in asserts and compiled in debug builds.
> - In library_call.cpp some return false should really be return NULL.
> Also improves consistency in this code (other return statements in the
> same method correctly return NULL).
>
>
> Ok to go in?
>
> http://cr.openjdk.java.net/~rkennke/gcc47/webrev.00/
>
> Regards,
> Roman
>
>


From david.holmes at oracle.com  Thu Dec  6 18:36:44 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 07 Dec 2012 12:36:44 +1000
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C12CE3.2050907@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
Message-ID: <50C1563C.7010208@oracle.com>

On 7/12/2012 9:40 AM, Coleen Phillimore wrote:
>
> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
> repository and will/have been pushed up to main already. They should
> already be in hotspot-comp.

Unfortunately there has been a bit of a lag between the two sets of 
fixes. :(

> Which compiler complains about the library_call.cpp changes? I have an
> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
> file compiles fine for me as is.

Even thought it presently compiles fine it is obviously "wrong" and 
should be fixed IMHO.

Cheers,
David

> Thanks,
> Coleen
>
>
> On 12/06/2012 03:24 PM, Roman Kennke wrote:
>> I posted part of this before in hotspot-gc-dev, without any reply yet.
>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-November/005327.html)
>>
>>
>>
>> In any case, here is a more complete patch relating to build failures
>> with GCC 4.7. It's basically:
>>
>> - Some more this-> qualifiers in binaryTreeDictionary.cpp (other such
>> qualifiers have been added before, those here probably slipped through
>> because they're only in asserts and compiled in debug builds.
>> - In library_call.cpp some return false should really be return NULL.
>> Also improves consistency in this code (other return statements in the
>> same method correctly return NULL).
>>
>>
>> Ok to go in?
>>
>> http://cr.openjdk.java.net/~rkennke/gcc47/webrev.00/
>>
>> Regards,
>> Roman
>>
>>
>

From john.coomes at oracle.com  Thu Dec  6 20:31:41 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Dec 2012 04:31:41 +0000
Subject: hg: hsx/hotspot-main: 6 new changesets
Message-ID: <20121207043141.9936347F80@hg.openjdk.java.net>

Changeset: 98a7af257bee
Author:    erikj
Date:      2012-12-03 10:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/98a7af257bee

8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk
Summary: Removing trailing backslash from LIB and INCLUDE.
Reviewed-by: ohrstrom, ohair

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

Changeset: 754f91d22e1c
Author:    erikj
Date:      2012-12-05 09:39 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/754f91d22e1c

8001541: Cannot build on Solaris using softlinks
Summary: Fixed softlink resolver macro in configure.
Reviewed-by: tbell, ohair

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

Changeset: ec187d02c95e
Author:    erikj
Date:      2012-12-05 10:12 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/ec187d02c95e

8004281: build-infra: Move all jar creation to images target and put jars in images/lib
Summary: Fixed bug in setting up make dependencies in SetupArchive.
Reviewed-by: ohair, tbell, dholmes

! common/makefiles/JavaCompilation.gmk

Changeset: bd32ef0789ca
Author:    erikj
Date:      2012-12-05 16:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/bd32ef0789ca

8003414: build-infra: fails on on windows
Summary: Added extra check that windows sdk is valid.
Reviewed-by: tbell, ohrstrom, ohair

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

Changeset: 9a6ec97ec45c
Author:    katleman
Date:      2012-12-05 12:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/9a6ec97ec45c

Merge


Changeset: c91c581321ce
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/c91c581321ce

Added tag jdk8-b67 for changeset 9a6ec97ec45c

! .hgtags


From john.coomes at oracle.com  Thu Dec  6 20:31:45 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Dec 2012 04:31:45 +0000
Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b67 for changeset
	394515ad2a55
Message-ID: <20121207043148.D41A847F83@hg.openjdk.java.net>

Changeset: 82000531feaa
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/82000531feaa

Added tag jdk8-b67 for changeset 394515ad2a55

! .hgtags


From john.coomes at oracle.com  Thu Dec  6 20:31:53 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Dec 2012 04:31:53 +0000
Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b67 for changeset
	83df3493ca3c
Message-ID: <20121207043202.B4F9347F86@hg.openjdk.java.net>

Changeset: b854e7008421
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b854e7008421

Added tag jdk8-b67 for changeset 83df3493ca3c

! .hgtags


From john.coomes at oracle.com  Thu Dec  6 20:32:09 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Dec 2012 04:32:09 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b67 for changeset
	eb06aa51dfc2
Message-ID: <20121207043213.CD2E847F89@hg.openjdk.java.net>

Changeset: d3fe408f3a9a
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d3fe408f3a9a

Added tag jdk8-b67 for changeset eb06aa51dfc2

! .hgtags


From john.coomes at oracle.com  Thu Dec  6 20:32:22 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Dec 2012 04:32:22 +0000
Subject: hg: hsx/hotspot-main/jdk: 3 new changesets
Message-ID: <20121207043334.C9CFA47F8C@hg.openjdk.java.net>

Changeset: 0fda013e4638
Author:    erikj
Date:      2012-12-05 10:12 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0fda013e4638

8004281: build-infra: Move all jar creation to images target and put jars in images/lib
Reviewed-by: ohair, tbell, dholmes

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/Images.gmk
! makefiles/Import.gmk

Changeset: ce9b02a3a17e
Author:    katleman
Date:      2012-12-05 12:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce9b02a3a17e

Merge


Changeset: ea0d3a9d0d01
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea0d3a9d0d01

Added tag jdk8-b67 for changeset ce9b02a3a17e

! .hgtags


From john.coomes at oracle.com  Thu Dec  6 20:35:24 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 07 Dec 2012 04:35:24 +0000
Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b67 for changeset
	303b09787a69
Message-ID: <20121207043532.7BF0E47F8D@hg.openjdk.java.net>

Changeset: e9a13a6c9d5d
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e9a13a6c9d5d

Added tag jdk8-b67 for changeset 303b09787a69

! .hgtags


From mikeb01 at gmail.com  Fri Dec  7 01:35:44 2012
From: mikeb01 at gmail.com (Michael Barker)
Date: Fri, 7 Dec 2012 09:35:44 +0000
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <CALwNKeSZxS43XJn3m_D-gS2J3yfZ-t-d_K_w5x4jXjdXPf7N7g@mail.gmail.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
	<50BF2D18.1090702@cs.oswego.edu>
	<CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
	<50C09936.50201@oracle.com>
	<CALwNKeSZxS43XJn3m_D-gS2J3yfZ-t-d_K_w5x4jXjdXPf7N7g@mail.gmail.com>
Message-ID: <CALwNKeT6mgW+=skgqGMgkgx-Vn-ap6kjqx0sg81ujynAMJgvqQ@mail.gmail.com>

>> I've been asking this on concurrency-interest@, but let's go through
>> this here. Imagine some weird Christmas miracle had happened, and
>> @Contended is actually available starting some JDK 7 update. Will that
>> change anything in the adoption scenarios we are speculating now?

Actually looking at the JDK8 M6 feature list, I'll look to maintain a
generic binary and JDK8+ binary as I'll probably want to make use of
the fence intrinsics.  So adding support to JDK7 probably wouldn't
help that much.

Mike.

From roland.westrelin at oracle.com  Fri Dec  7 03:17:05 2012
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Fri, 07 Dec 2012 11:17:05 +0000
Subject: hg: hsx/hotspot-main/hotspot: 15 new changesets
Message-ID: <20121207111803.118B947FAF@hg.openjdk.java.net>

Changeset: 7cc69864a29b
Author:    kvn
Date:      2012-11-16 15:49 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7cc69864a29b

7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum
Summary: Increase the stack size in the run parameters.
Reviewed-by: kvn
Contributed-by: david.r.chase at oracle.com

! test/compiler/6865265/StackOverflowBug.java

Changeset: ee32440febeb
Author:    vlivanov
Date:      2012-11-21 05:57 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ee32440febeb

8001538: hs_err file does not list anymore compiled methods in compilation events
Summary: Fixed message buffer size calculation.
Reviewed-by: kvn, twisti

! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/utilities/events.hpp

Changeset: beebba0acc11
Author:    twisti
Date:      2012-11-26 17:25 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/beebba0acc11

7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop()
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/type.hpp

Changeset: 2cd5e15048e6
Author:    twisti
Date:      2012-11-27 12:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2cd5e15048e6

8003868: fix shark for latest HotSpot and LLVM
Reviewed-by: twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/assembler_zero.hpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/globals_zero.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/shark/llvmHeaders.hpp
! src/share/vm/shark/llvmValue.hpp
! src/share/vm/shark/sharkBlock.cpp
! src/share/vm/shark/sharkBuilder.cpp
! src/share/vm/shark/sharkBuilder.hpp
! src/share/vm/shark/sharkCacheDecache.cpp
! src/share/vm/shark/sharkCacheDecache.hpp
! src/share/vm/shark/sharkCodeBuffer.hpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkConstant.cpp
! src/share/vm/shark/sharkContext.cpp
! src/share/vm/shark/sharkContext.hpp
! src/share/vm/shark/sharkFunction.hpp
! src/share/vm/shark/sharkIntrinsics.cpp
! src/share/vm/shark/sharkMemoryManager.cpp
! src/share/vm/shark/sharkMemoryManager.hpp
! src/share/vm/shark/sharkNativeWrapper.cpp
! src/share/vm/shark/sharkStack.cpp
! src/share/vm/shark/sharkStack.hpp
! src/share/vm/shark/sharkState.cpp
! src/share/vm/shark/sharkTopLevelBlock.cpp
! src/share/vm/shark/sharkTopLevelBlock.hpp
! src/share/vm/shark/sharkType.hpp
! src/share/vm/shark/sharkValue.cpp
! src/share/vm/shark/shark_globals.hpp

Changeset: 2aff40cb4703
Author:    bharadwaj
Date:      2012-11-27 17:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2aff40cb4703

7092905: C2: Keep track of the number of dead nodes
Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes.
Reviewed-by: kvn, twisti, jrose, vlivanov

! src/share/tools/LogCompilation/README
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/stringopts.cpp

Changeset: 1acccb7c0b01
Author:    kvn
Date:      2012-11-27 17:41 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1acccb7c0b01

8003850: add support for constants in stub code
Summary: remember the code section and switch back to the proper one when adding constants.
Reviewed-by: twisti, kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/codeBuffer.cpp

Changeset: 6ab62ad83507
Author:    twisti
Date:      2012-11-30 11:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ab62ad83507

8003195: AbstractAssembler should not store code pointers but use the CodeSection directly
Reviewed-by: twisti, kvn
Contributed-by: Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com>

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/assembler.inline.hpp
! src/share/vm/asm/codeBuffer.hpp

Changeset: cd3d6a6b95d9
Author:    twisti
Date:      2012-11-30 15:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd3d6a6b95d9

8003240: x86: move MacroAssembler into separate file
Reviewed-by: kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/codeBuffer_sparc.hpp
! src/cpu/sparc/vm/frame_sparc.hpp
! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/icBuffer_x86.cpp
! src/cpu/x86/vm/icache_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/jniFastGetField_x86_32.cpp
! src/cpu/x86/vm/jniFastGetField_x86_64.cpp
+ src/cpu/x86/vm/macroAssembler_x86.cpp
+ src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/metaspaceShared_x86_32.cpp
! src/cpu/x86/vm/metaspaceShared_x86_64.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/runtime_x86_32.cpp
! src/cpu/x86/vm/runtime_x86_64.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/os/bsd/vm/osThread_bsd.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/linux/vm/osThread_linux.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/solaris/vm/osThread_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/windows/vm/osThread_windows.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.inline.hpp
! src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/assembler.inline.hpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
+ src/share/vm/asm/macroAssembler.hpp
+ src/share/vm/asm/macroAssembler.inline.hpp
! src/share/vm/c1/c1_MacroAssembler.hpp
! src/share/vm/code/icBuffer.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/runtime/atomic.cpp
! src/share/vm/runtime/atomic.hpp
+ src/share/vm/runtime/atomic.inline.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/stubCodeGenerator.cpp

Changeset: dd38cfd12c3a
Author:    twisti
Date:      2012-12-03 15:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dd38cfd12c3a

8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640
Reviewed-by: kvn, johnc

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

Changeset: c5d414e98fd4
Author:    neliasso
Date:      2012-11-26 15:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c5d414e98fd4

8003983: LogCompilation tool is broken since c1 support
Summary: Fixed emitting and parsing
Reviewed-by: jrose, kvn

! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java
! src/share/vm/c1/c1_Compilation.cpp

Changeset: b7ff5879152e
Author:    neliasso
Date:      2012-12-06 09:50 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b7ff5879152e

8003934: Fix generation of malformed options to Projectcreator
Summary: Makefile produces unmatched quotes due to nmake bug
Reviewed-by: jwilhelm, brutisso

! make/windows/projectfiles/common/Makefile

Changeset: 228a94f37a67
Author:    neliasso
Date:      2012-12-06 14:33 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/228a94f37a67

Merge


Changeset: f0c2369fda5a
Author:    twisti
Date:      2012-12-06 09:57 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f0c2369fda5a

8003250: SPARC: move MacroAssembler into separate file
Reviewed-by: jrose, kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/sparc/vm/icBuffer_sparc.cpp
! src/cpu/sparc/vm/icache_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
! src/cpu/sparc/vm/jniFastGetField_sparc.cpp
+ src/cpu/sparc/vm/macroAssembler_sparc.cpp
+ src/cpu/sparc/vm/macroAssembler_sparc.hpp
+ src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp
! src/cpu/sparc/vm/metaspaceShared_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/runtime_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vmreg_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/assembler_zero.hpp
! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/share/vm/adlc/main.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/macroAssembler.hpp
! src/share/vm/asm/macroAssembler.inline.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/code/vmreg.hpp

Changeset: 522662fa9c16
Author:    twisti
Date:      2012-12-06 11:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/522662fa9c16

Merge


Changeset: d2f8c38e543d
Author:    roland
Date:      2012-12-07 01:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d2f8c38e543d

Merge

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/thread.cpp


From jon.masamitsu at oracle.com  Fri Dec  7 07:54:36 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 07 Dec 2012 07:54:36 -0800
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <1354825441.1747.22.camel@mercury>
References: <1354825441.1747.22.camel@mercury>
Message-ID: <50C2113C.1050508@oracle.com>

Roman,

I'll sponsor the changes to binaryTreeDictionary.cpp but let be get
back to you later today or Monday on it.

Coleen,

I've go this.

Jon

On 12/6/2012 12:24 PM, Roman Kennke wrote:
> I posted part of this before in hotspot-gc-dev, without any reply yet.
> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-November/005327.html)
>
>
> In any case, here is a more complete patch relating to build failures
> with GCC 4.7. It's basically:
>
> - Some more this->  qualifiers in binaryTreeDictionary.cpp (other such
> qualifiers have been added before, those here probably slipped through
> because they're only in asserts and compiled in debug builds.
> - In library_call.cpp some return false should really be return NULL.
> Also improves consistency in this code (other return statements in the
> same method correctly return NULL).
>
>
> Ok to go in?
>
> http://cr.openjdk.java.net/~rkennke/gcc47/webrev.00/
>
> Regards,
> Roman
>
>

From rkennke at redhat.com  Fri Dec  7 08:28:45 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 07 Dec 2012 17:28:45 +0100
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C12CE3.2050907@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
Message-ID: <1354897725.1747.75.camel@mercury>

Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc 
> repository and will/have been pushed up to main already. They should 
> already be in hotspot-comp.

Ah great, good to see, thanks! :-)

> Which compiler complains about the library_call.cpp changes?  I have an 
> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this 
> file compiles fine for me as is.

This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
improvements from dev versions sometimes... I agree with David, it would
be good to fix in any case.

Thanks,
Roman



From jesper.wilhelmsson at oracle.com  Fri Dec  7 09:30:21 2012
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 07 Dec 2012 17:30:21 +0000
Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets
Message-ID: <20121207173030.214A347FBD@hg.openjdk.java.net>

Changeset: 0f80645e9c26
Author:    johnc
Date:      2012-11-30 11:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f80645e9c26

8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8
Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor.
Reviewed-by: jwilhelm, azeemj, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/timer.cpp

Changeset: eade6b2e4782
Author:    jmasa
Date:      2012-11-29 10:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eade6b2e4782

8003554: NPG: move Metablock and Metachunk code out of metaspace.cpp
Reviewed-by: coleenp

+ src/share/vm/memory/metablock.cpp
+ src/share/vm/memory/metachunk.cpp
! src/share/vm/memory/metaspace.cpp

Changeset: cbe736bc70fa
Author:    jwilhelm
Date:      2012-12-07 07:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cbe736bc70fa

Merge



From alejandro.murillo at oracle.com  Fri Dec  7 13:12:31 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 07 Dec 2012 21:12:31 +0000
Subject: hg: hsx/hsx25/hotspot: 22 new changesets
Message-ID: <20121207211319.1406847FC6@hg.openjdk.java.net>

Changeset: 10587a580c51
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/10587a580c51

Added tag jdk8-b67 for changeset 25bdce771bb3

! .hgtags

Changeset: 816b7e5bf2ed
Author:    amurillo
Date:      2012-11-30 17:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/816b7e5bf2ed

8004248: new hotspot build - hs25-b12
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 7cc69864a29b
Author:    kvn
Date:      2012-11-16 15:49 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7cc69864a29b

7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum
Summary: Increase the stack size in the run parameters.
Reviewed-by: kvn
Contributed-by: david.r.chase at oracle.com

! test/compiler/6865265/StackOverflowBug.java

Changeset: ee32440febeb
Author:    vlivanov
Date:      2012-11-21 05:57 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ee32440febeb

8001538: hs_err file does not list anymore compiled methods in compilation events
Summary: Fixed message buffer size calculation.
Reviewed-by: kvn, twisti

! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/utilities/events.hpp

Changeset: beebba0acc11
Author:    twisti
Date:      2012-11-26 17:25 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/beebba0acc11

7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop()
Reviewed-by: kvn, jrose

! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/type.hpp

Changeset: 2cd5e15048e6
Author:    twisti
Date:      2012-11-27 12:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2cd5e15048e6

8003868: fix shark for latest HotSpot and LLVM
Reviewed-by: twisti
Contributed-by: Roman Kennke <rkennke at redhat.com>

! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/assembler_zero.hpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/globals_zero.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/shark/llvmHeaders.hpp
! src/share/vm/shark/llvmValue.hpp
! src/share/vm/shark/sharkBlock.cpp
! src/share/vm/shark/sharkBuilder.cpp
! src/share/vm/shark/sharkBuilder.hpp
! src/share/vm/shark/sharkCacheDecache.cpp
! src/share/vm/shark/sharkCacheDecache.hpp
! src/share/vm/shark/sharkCodeBuffer.hpp
! src/share/vm/shark/sharkCompiler.cpp
! src/share/vm/shark/sharkConstant.cpp
! src/share/vm/shark/sharkContext.cpp
! src/share/vm/shark/sharkContext.hpp
! src/share/vm/shark/sharkFunction.hpp
! src/share/vm/shark/sharkIntrinsics.cpp
! src/share/vm/shark/sharkMemoryManager.cpp
! src/share/vm/shark/sharkMemoryManager.hpp
! src/share/vm/shark/sharkNativeWrapper.cpp
! src/share/vm/shark/sharkStack.cpp
! src/share/vm/shark/sharkStack.hpp
! src/share/vm/shark/sharkState.cpp
! src/share/vm/shark/sharkTopLevelBlock.cpp
! src/share/vm/shark/sharkTopLevelBlock.hpp
! src/share/vm/shark/sharkType.hpp
! src/share/vm/shark/sharkValue.cpp
! src/share/vm/shark/shark_globals.hpp

Changeset: 2aff40cb4703
Author:    bharadwaj
Date:      2012-11-27 17:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2aff40cb4703

7092905: C2: Keep track of the number of dead nodes
Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes.
Reviewed-by: kvn, twisti, jrose, vlivanov

! src/share/tools/LogCompilation/README
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java
! src/share/vm/opto/block.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/stringopts.cpp

Changeset: 1acccb7c0b01
Author:    kvn
Date:      2012-11-27 17:41 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1acccb7c0b01

8003850: add support for constants in stub code
Summary: remember the code section and switch back to the proper one when adding constants.
Reviewed-by: twisti, kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/codeBuffer.cpp

Changeset: 6ab62ad83507
Author:    twisti
Date:      2012-11-30 11:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6ab62ad83507

8003195: AbstractAssembler should not store code pointers but use the CodeSection directly
Reviewed-by: twisti, kvn
Contributed-by: Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com>

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/assembler.inline.hpp
! src/share/vm/asm/codeBuffer.hpp

Changeset: cd3d6a6b95d9
Author:    twisti
Date:      2012-11-30 15:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd3d6a6b95d9

8003240: x86: move MacroAssembler into separate file
Reviewed-by: kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/codeBuffer_sparc.hpp
! src/cpu/sparc/vm/frame_sparc.hpp
! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/cpu/x86/vm/icBuffer_x86.cpp
! src/cpu/x86/vm/icache_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
! src/cpu/x86/vm/jniFastGetField_x86_32.cpp
! src/cpu/x86/vm/jniFastGetField_x86_64.cpp
+ src/cpu/x86/vm/macroAssembler_x86.cpp
+ src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/metaspaceShared_x86_32.cpp
! src/cpu/x86/vm/metaspaceShared_x86_64.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/runtime_x86_32.cpp
! src/cpu/x86/vm/runtime_x86_64.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/os/bsd/vm/osThread_bsd.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/linux/vm/osThread_linux.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/solaris/vm/osThread_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/windows/vm/osThread_windows.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.inline.hpp
! src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/assembler.inline.hpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
+ src/share/vm/asm/macroAssembler.hpp
+ src/share/vm/asm/macroAssembler.inline.hpp
! src/share/vm/c1/c1_MacroAssembler.hpp
! src/share/vm/code/icBuffer.cpp
! src/share/vm/code/relocInfo.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/runtime/atomic.cpp
! src/share/vm/runtime/atomic.hpp
+ src/share/vm/runtime/atomic.inline.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/stubCodeGenerator.cpp

Changeset: dd38cfd12c3a
Author:    twisti
Date:      2012-12-03 15:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dd38cfd12c3a

8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640
Reviewed-by: kvn, johnc

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

Changeset: c5d414e98fd4
Author:    neliasso
Date:      2012-11-26 15:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c5d414e98fd4

8003983: LogCompilation tool is broken since c1 support
Summary: Fixed emitting and parsing
Reviewed-by: jrose, kvn

! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java
! src/share/vm/c1/c1_Compilation.cpp

Changeset: b7ff5879152e
Author:    neliasso
Date:      2012-12-06 09:50 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b7ff5879152e

8003934: Fix generation of malformed options to Projectcreator
Summary: Makefile produces unmatched quotes due to nmake bug
Reviewed-by: jwilhelm, brutisso

! make/windows/projectfiles/common/Makefile

Changeset: 228a94f37a67
Author:    neliasso
Date:      2012-12-06 14:33 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/228a94f37a67

Merge


Changeset: f0c2369fda5a
Author:    twisti
Date:      2012-12-06 09:57 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f0c2369fda5a

8003250: SPARC: move MacroAssembler into separate file
Reviewed-by: jrose, kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/sparc/vm/icBuffer_sparc.cpp
! src/cpu/sparc/vm/icache_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
! src/cpu/sparc/vm/jniFastGetField_sparc.cpp
+ src/cpu/sparc/vm/macroAssembler_sparc.cpp
+ src/cpu/sparc/vm/macroAssembler_sparc.hpp
+ src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp
! src/cpu/sparc/vm/metaspaceShared_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/runtime_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vmreg_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/assembler_zero.hpp
! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/share/vm/adlc/main.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/macroAssembler.hpp
! src/share/vm/asm/macroAssembler.inline.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/code/vmreg.hpp

Changeset: 522662fa9c16
Author:    twisti
Date:      2012-12-06 11:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/522662fa9c16

Merge


Changeset: d2f8c38e543d
Author:    roland
Date:      2012-12-07 01:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d2f8c38e543d

Merge

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/thread.cpp

Changeset: 0f80645e9c26
Author:    johnc
Date:      2012-11-30 11:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f80645e9c26

8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8
Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor.
Reviewed-by: jwilhelm, azeemj, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/timer.cpp

Changeset: eade6b2e4782
Author:    jmasa
Date:      2012-11-29 10:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/eade6b2e4782

8003554: NPG: move Metablock and Metachunk code out of metaspace.cpp
Reviewed-by: coleenp

+ src/share/vm/memory/metablock.cpp
+ src/share/vm/memory/metachunk.cpp
! src/share/vm/memory/metaspace.cpp

Changeset: cbe736bc70fa
Author:    jwilhelm
Date:      2012-12-07 07:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cbe736bc70fa

Merge


Changeset: a35a72dd2e12
Author:    amurillo
Date:      2012-12-07 10:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a35a72dd2e12

Merge


Changeset: 121aa71316af
Author:    amurillo
Date:      2012-12-07 10:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/121aa71316af

Added tag hs25-b12 for changeset a35a72dd2e12

! .hgtags


From alejandro.murillo at oracle.com  Fri Dec  7 14:41:53 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 07 Dec 2012 22:41:53 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121207224203.500D847FC9@hg.openjdk.java.net>

Changeset: 10587a580c51
Author:    katleman
Date:      2012-12-06 12:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/10587a580c51

Added tag jdk8-b67 for changeset 25bdce771bb3

! .hgtags

Changeset: a35a72dd2e12
Author:    amurillo
Date:      2012-12-07 10:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a35a72dd2e12

Merge


Changeset: 121aa71316af
Author:    amurillo
Date:      2012-12-07 10:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/121aa71316af

Added tag hs25-b12 for changeset a35a72dd2e12

! .hgtags

Changeset: 4a2ed49abd51
Author:    amurillo
Date:      2012-12-07 10:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a2ed49abd51

8004724: new hotspot build - hs25-b13
Reviewed-by: jcoomes

! make/hotspot_version


From david.holmes at oracle.com  Fri Dec  7 23:34:12 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 08 Dec 2012 17:34:12 +1000
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C2113C.1050508@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C2113C.1050508@oracle.com>
Message-ID: <50C2ED74.3080700@oracle.com>

Jon,

On 8/12/2012 1:54 AM, Jon Masamitsu wrote:
> Roman,
>
> I'll sponsor the changes to binaryTreeDictionary.cpp but let be get
> back to you later today or Monday on it.

This is already fixed.

David
-----

> Coleen,
>
> I've go this.
>
> Jon
>
> On 12/6/2012 12:24 PM, Roman Kennke wrote:
>> I posted part of this before in hotspot-gc-dev, without any reply yet.
>> (http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-November/005327.html)
>>
>>
>>
>> In any case, here is a more complete patch relating to build failures
>> with GCC 4.7. It's basically:
>>
>> - Some more this-> qualifiers in binaryTreeDictionary.cpp (other such
>> qualifiers have been added before, those here probably slipped through
>> because they're only in asserts and compiled in debug builds.
>> - In library_call.cpp some return false should really be return NULL.
>> Also improves consistency in this code (other return statements in the
>> same method correctly return NULL).
>>
>>
>> Ok to go in?
>>
>> http://cr.openjdk.java.net/~rkennke/gcc47/webrev.00/
>>
>> Regards,
>> Roman
>>
>>

From aleksey.shipilev at oracle.com  Mon Dec 10 08:12:27 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 10 Dec 2012 20:12:27 +0400
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
Message-ID: <50C609EB.2000505@oracle.com>

Hi,

This is the updated webrev for JEP-142 aka @Contended:
  http://shipilev.net/pub/jdk/hotspot/contended/webrev-6/

It employs the same trick for reducing footprint: piggybacking on
InstanceKlass::misc_flags to store class-level flag, and making the
tagged field in FieldInfo (as the side effect, cleaning up the mess with
"temporarily store type into offset field") to store per-field info. I
had to fix a few compile-time errors for MSVC.

Testing:
  - Test8003985 @Contended-targeted test passed
  - JPRT full cycle passed
  - adhoc nsk, regression suites passed

I would really appreciate the reviews!

Thanks,
Aleksey.

From zhengyu.gu at oracle.com  Mon Dec 10 11:30:20 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 10 Dec 2012 14:30:20 -0500
Subject: Code review request: 8004802 jcmd VM.native_memory baseline=false
	crashes VM
Message-ID: <50C6384C.3040702@oracle.com>

This crash is due to that NMT did not check option's value,  only 
checked if the option has value. The fix is to take option value into 
account.

http://cr.openjdk.java.net/~zgu/8004802/webrev.00/


Thanks,

-Zhengyu

From john.r.rose at oracle.com  Mon Dec 10 14:44:09 2012
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 10 Dec 2012 14:44:09 -0800
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <50C609EB.2000505@oracle.com>
References: <50C609EB.2000505@oracle.com>
Message-ID: <FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>

This is good.  I have some comments on it.

You don't need the field "bool _contended".  Use "has_annotation(_sun_misc_Contended)" instead.  That's how the other annotations work.  Having an accessor "is_contended" is great; just feed it from the "_annotations_present" bitmask.

In FieldInfo, the "type" field should be named "field_allocation_type", to avoid confusion with BasicType, etc.

It's good that you are packing the data into the field info array without adding new elements.  In the near future we are likely to add more sparse attributes to fields, which will require packing even more information into that limited space.  With that in mind, I would prefer to see us using a sparse representation sooner rather than later, but that change can wait. (In particular, the 'initval_index' is almost always zero, and should go away.)  The bottom line, for now, is that your solution for cramming in contended bits will probably need to be reworked with the next sparse field annotation (probably @Stable).  The rework could use something like your tagging scheme (which is clever) but have the exceptional tag value mean "I have extended attributes specified in N additional words of data".

In any case, this change overlaps with the following pending change from mlvm, which also introduces a field annotation:
  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/diff/b6f0babd7cf1/anno-stable-8001107.patch

That change makes the various method and field annotations be no-op outside of privileged code.
This needs to be the case also with @Contended.

(As you probably noted, Doug is OK with this, with some reluctance.  The time to make such annotations more generally available may well come, but that will be when the annotation name is put into a public API.)

You can use the code from 8001107 to do this:
  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/diff/b6f0babd7cf1/anno-stable-8001107.patch

The relevant hunk contains these lines:
> -ClassFileParser::AnnotationCollector::ID ClassFileParser::AnnotationCollector::annotation_index(Symbol* name) {
> +ClassFileParser::AnnotationCollector::ID
> +ClassFileParser::AnnotationCollector::annotation_index(ClassLoaderData* loader_data,
> +                                                       Symbol* name) {
>    vmSymbols::SID sid = vmSymbols::find_sid(name);
> +  bool privileged = false;
> +  if (loader_data->is_the_null_class_loader_data()) {
> +    // Privileged code can use all annotations.  Other code silently drops some.
> +    privileged = true;
> +  }
>    switch (sid) {

You will need to the class loader argument to annotation_index, etc.

I considered waiting to do this logic until we push 8001107, but there will be less trouble if you introduce it now.  Otherwise, new regression tests on @Contended will probably break when the restriction is introduced.

Are there SA changes and new jtreg tests?  I didn't see them in this webrev.

Thanks,
? John

On Dec 10, 2012, at 8:12 AM, Aleksey Shipilev wrote:

> Hi,
> 
> This is the updated webrev for JEP-142 aka @Contended:
>  http://shipilev.net/pub/jdk/hotspot/contended/webrev-6/
> 
> It employs the same trick for reducing footprint: piggybacking on
> InstanceKlass::misc_flags to store class-level flag, and making the
> tagged field in FieldInfo (as the side effect, cleaning up the mess with
> "temporarily store type into offset field") to store per-field info. I
> had to fix a few compile-time errors for MSVC.
> 
> Testing:
>  - Test8003985 @Contended-targeted test passed
>  - JPRT full cycle passed
>  - adhoc nsk, regression suites passed
> 
> I would really appreciate the reviews!
> 
> Thanks,
> Aleksey.


From john.r.rose at oracle.com  Mon Dec 10 15:52:40 2012
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 10 Dec 2012 15:52:40 -0800
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
	<50BF2D18.1090702@cs.oswego.edu>
	<CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
Message-ID: <A2056565-FA3E-414F-9F49-B69FDFBBBA84@oracle.com>

On Dec 6, 2012, at 1:31 AM, Michael Barker wrote:

> A middle ground I could live with would be something like
> -XX:(+/-)RestrictContendedToBootClassPath (preferably with the default
> as off).  Adding/removing a switch of that nature is operationally
> simpler than fiddling with file locations and classpath settings.

I'm OK with that.  The important thing is that, in order for your code use the annotations, you have to have control over the command line (or Unsafe) in order to access the functionality.  That way, people cannot start using the annotation from unprivileged class files, without an overarching decision from the person that launched the JVM.


On Dec 4, 2012, at 4:08 PM, Doug Lea wrote:

>> [1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible hack.
>>  Which is an implementation artifact that could easily break by accident.  If
>> you use that hack, you should move your code to BCP.
>> 
> 
> Which is the trick we use to put out our pre-openjdk-integration
> preview packages. So we'd have to find another trick...

On Dec 5, 2012, at 3:16 AM, Doug Lea wrote:

> This would be a less
> controversial idea if it were not for all the cases that arise
> in practice where other factors make it impossible for the
> actual users of the functionality to control JVM startup
> settings. Which ends up making this proposed rule overly
> hostile in its practical effect.

Note that Unsafe.defineClass allows you to load classes anywhere, including on the boot class path.  So if you want to load privileged code from an unprivileged context, and you are willing and able to use Unsafe, that is an option.  Is there some reason this fails to be useful?  Maybe some residual security check that still executes?

> So I think that wording things so as to make no promises
> in these cases (and to not force the VM to make special
> efforts to see if it must ignore @Contended), rather than to
> promise no effect, is the best compromise available.

It's easy to make the check (I just pointed Aleksey at the code), so I think we need to do it from the start, as long as @Contended is in a private package.  When it goes public, then all code (presumably) will benefit from it.

Additional rationale details:  If you cannot validly compile source code that refers to the annotation (which the ctsym file filters out), then you should not be able to execute the annotation within class files you can load, even if you are clever enough to build the annotation into the class files.  On the other hand, invalid annotations are defined as silent no-ops.  This leads to the restriction I am asking for.

In positive terms:  If you have to work around the ctsyms during compilation, expect to work around package access restrictions when loading and linking your program.  (This is already true, and will continue to be true.)

Why should a restriction on source code be mirrored by a restriction on bytecode?  It's not logically necessary, and it would be convenient to library deployers to have no restrictions on bytecode.  But I believe it is more reasonable to have repeated source/binary restrictions than to have source-only restrictions, especially for configuration parameters like class visibility.  In any case, that's how Java does things, and people are used to it.  It eases security and configuration analyses to have the source code and binary code to be subject (as much as possible, but see JLS Ch. 13) to the same (or analogous) access restrictions.

Granted, there would be little or no security downside for allowing @Contended fields everywhere.  Worst case, maybe, is that hackers would be able to create gigantic instance layouts, to some nefarious purpose.  I guess, besides a remote possibility of an attack, the main thing I'm concerned with is creating a support burden from arbitrary code using a feature intended to be restricted to privileged code.  (Remi cites the opposite support burden, for people that loads code that crosses a line.  That burden should be borne by whoever made the decision to cross that line, and I think Unsafe.defineClass gives them a reasonable workaround.)

In a nutshell, now that we're getting into the business of fancy annotations, we need to roll them out with just as much care as we do with normal class-based APIs.  That means enforcing access checks at both compile time and run time.  And for annotations, a failed access check at runtime entails a no-op.

On Dec 4, 2012, at 4:36 PM, Remi Forax wrote:

>> The annotation must be documented as being a no-op when it occurs inside class files that are loaded outside the boot class path.
> 
> I will agree if it's a way to be sure that the boot class path will not be cut in small pieces by jigsaw.
> What we really want here is a way to say that a module is tainted (like the linux kernel), and only tainted module have access to sun.misc.

I am assuming that wherever we say "boot class path" now, we will use a suitable replacement concept with Jigsaw.

? John

From dl at cs.oswego.edu  Tue Dec 11 04:46:47 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 11 Dec 2012 07:46:47 -0500
Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
In-Reply-To: <A2056565-FA3E-414F-9F49-B69FDFBBBA84@oracle.com>
References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com>
	<50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com>
	<50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com>
	<50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu>
	<809CEEBE-DA1F-4309-AC58-B1189E8C2B2C@oracle.com>
	<50BE908B.3040305@cs.oswego.edu>
	<CALwNKeSbPZp8Lmd8b79_Cw0spDgo=iZouX6G=cBE0FeL3Bm9wQ@mail.gmail.com>
	<50BF2D18.1090702@cs.oswego.edu>
	<CALwNKeTcsQmK2h3pCS8_e2xSam8bDKWBAqENr-g3n1jn=GmkqA@mail.gmail.com>
	<A2056565-FA3E-414F-9F49-B69FDFBBBA84@oracle.com>
Message-ID: <50C72B37.3040505@cs.oswego.edu>

On 12/10/12 18:52, John Rose wrote:
>
> On Dec 5, 2012, at 3:16 AM, Doug Lea wrote:
>
>> This would be a less
>> controversial idea if it were not for all the cases that arise
>> in practice where other factors make it impossible for the
>> actual users of the functionality to control JVM startup
>> settings. Which ends up making this proposed rule overly
>> hostile in its practical effect.
>
> Note that Unsafe.defineClass allows you to load classes anywhere, including on
> the boot class path.  So if you want to load privileged code from an
> unprivileged context, and you are willing and able to use Unsafe, that is an
> option.  Is there some reason this fails to be useful?  Maybe some residual
> security check that still executes?

It's just another gratuitous pain-point. But having already
established that low-level Java concurrency hackers are
masochists, there's no point in saying "ouch".
So please proceed.

-Doug




From aleksey.shipilev at oracle.com  Tue Dec 11 05:06:54 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 11 Dec 2012 17:06:54 +0400
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
Message-ID: <50C72FEE.5060203@oracle.com>

Thanks for an awesome review, John! Comments inline:

On 12/11/2012 02:44 AM, John Rose wrote:
> This is good.  I have some comments on it.
> 
> You don't need the field "bool _contended".  Use
> "has_annotation(_sun_misc_Contended)" instead.  That's how the other
> annotations work.  Having an accessor "is_contended" is great; just
> feed it from the "_annotations_present" bitmask.

Great, OK.

> In FieldInfo, the "type" field should be named
> "field_allocation_type", to avoid confusion with BasicType, etc.

OK.

> It's good that you are packing the data into the field info array
> without adding new elements.  In the near future we are likely to add
> more sparse attributes to fields, which will require packing even
> more information into that limited space.  With that in mind, I would
> prefer to see us using a sparse representation sooner rather than
> later, but that change can wait. (In particular, the 'initval_index'
> is almost always zero, and should go away.)  The bottom line, for
> now, is that your solution for cramming in contended bits will
> probably need to be reworked with the next sparse field annotation
> (probably @Stable).  The rework could use something like your tagging
> scheme (which is clever) but have the exceptional tag value mean "I
> have extended attributes specified in N additional words of data".

I think we have a little bit of mis-design about FieldInfo here. What
allows me to piggyback on FieldInfo is that we clearly have the
classload-scope (CS) metadata info for fields, and runtime-scope (RS)
metadata info. That allows us to mangle CS data during the classload,
knowing for sure we substitute that with RS after classload finishes.

This is probably a little dodgy when compared against sparse
representation, but I feel uncomfortable rebuilding entire field
attribute mechanics in the course of @Contended work.

> In any case, this change overlaps with the following pending change
> from mlvm, which also introduces a field annotation: 
> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/diff/b6f0babd7cf1/anno-stable-8001107.patch

>  That change makes the various method and field annotations be no-op
> outside of privileged code. This needs to be the case also with
> @Contended.

OK, I can do that for @Contended as well, and guard this behavior with
two flags, e.g. -XX:+EnableContendedOnBCP=true,
-XX:+EnableContendedOnCP=false, and act accordingly. We can discuss
separately what should be the default values for these flags.

> Are there SA changes and new jtreg tests?  I didn't see them in this
> webrev.

(sigh) Any pointers what should be done, and where the tests should be
placed?

-Aleksey.

From aleksey.shipilev at oracle.com  Tue Dec 11 13:30:09 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 12 Dec 2012 01:30:09 +0400
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
Message-ID: <50C7A5E1.1000207@oracle.com>

On 12/11/2012 02:44 AM, John Rose wrote:
> This is good.  I have some comments on it.

Ok, this is the updated webrev fixing most of John's comments:
  http://shipilev.net/pub/jdk/hotspot/contended/webrev-7/

Changes are:
  - ClassFileParser::_is_contended is gone
  - merged "privileged" machinery from John's patch into ClassFileParser
  - FieldInfo::type -> FieldInfo::allocation_type
  - two JVM options: -XX:+EnableContendedOnBCP, and
-XX:-EnableContendedOnCP added, so that @Contended is no-op for
non-privileged classes until you flip the switch

Testing:
  - built and tested on Linux x86_64
  - Test8003985 works with -XX:+EnableContendedOnCP
  - JPRT build is OK on most platforms, testing undergoing

John, can you confirm it looks ok for you? Otherwise, I'll make more
changes tomorrow.

-Aleksey.

From coleen.phillimore at oracle.com  Tue Dec 11 13:53:27 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 11 Dec 2012 16:53:27 -0500
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <1354897725.1747.75.camel@mercury>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury>
Message-ID: <50C7AB57.9040709@oracle.com>


Now I hit this library_call.cpp compilation error.   Has it been pushed 
yet?   I was going to piggyback this with another cleanup that I was 
making if not.

thanks,
Coleen

On 12/07/2012 11:28 AM, Roman Kennke wrote:
> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
>> repository and will/have been pushed up to main already. They should
>> already be in hotspot-comp.
> Ah great, good to see, thanks! :-)
>
>> Which compiler complains about the library_call.cpp changes?  I have an
>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
>> file compiles fine for me as is.
> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
> improvements from dev versions sometimes... I agree with David, it would
> be good to fix in any case.
>
> Thanks,
> Roman
>
>


From rkennke at redhat.com  Tue Dec 11 14:00:12 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 11 Dec 2012 23:00:12 +0100
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C7AB57.9040709@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
Message-ID: <1355263212.1747.154.camel@mercury>

Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
> Now I hit this library_call.cpp compilation error.   Has it been pushed 
> yet?   I was going to piggyback this with another cleanup that I was 
> making if not.

No, it has not been pushed yet. :-(

Seems like all my patches have become stuck in the queue. Is there
anything that I can do to make them move forward? Should I file them in
openjdk bugzilla?

Regards,
Roman

> 
> thanks,
> Coleen
> 
> On 12/07/2012 11:28 AM, Roman Kennke wrote:
> > Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
> >> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
> >> repository and will/have been pushed up to main already. They should
> >> already be in hotspot-comp.
> > Ah great, good to see, thanks! :-)
> >
> >> Which compiler complains about the library_call.cpp changes?  I have an
> >> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
> >> file compiles fine for me as is.
> > This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
> > improvements from dev versions sometimes... I agree with David, it would
> > be good to fix in any case.
> >
> > Thanks,
> > Roman
> >
> >
> 



From coleen.phillimore at oracle.com  Tue Dec 11 14:17:10 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 11 Dec 2012 17:17:10 -0500
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <1355263212.1747.154.camel@mercury>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
	<1355263212.1747.154.camel@mercury>
Message-ID: <50C7B0E6.6000602@oracle.com>


On 12/11/2012 05:00 PM, Roman Kennke wrote:
> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
>> Now I hit this library_call.cpp compilation error.   Has it been pushed
>> yet?   I was going to piggyback this with another cleanup that I was
>> making if not.
> No, it has not been pushed yet. :-(
>
> Seems like all my patches have become stuck in the queue. Is there
> anything that I can do to make them move forward? Should I file them in
> openjdk bugzilla?

What you are doing is the right way to submit patches.  We don't really 
monitor openjdk bugzilla.   I think people are working on your other 
patches.

thanks,
Coleen

>
> Regards,
> Roman
>
>> thanks,
>> Coleen
>>
>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
>>>> repository and will/have been pushed up to main already. They should
>>>> already be in hotspot-comp.
>>> Ah great, good to see, thanks! :-)
>>>
>>>> Which compiler complains about the library_call.cpp changes?  I have an
>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
>>>> file compiles fine for me as is.
>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
>>> improvements from dev versions sometimes... I agree with David, it would
>>> be good to fix in any case.
>>>
>>> Thanks,
>>> Roman
>>>
>>>
>


From coleen.phillimore at oracle.com  Tue Dec 11 14:17:47 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 11 Dec 2012 17:17:47 -0500
Subject: Request for review 8004883: NPG: clean up anonymous class fix
Message-ID: <50C7B10B.6010408@oracle.com>

Summary: Add klass_holder() to return either mirror or class_loader 
depending on if the class is anonymous or not.

Add code cleanup requested by John Rose and StefanK.

open webrev at http://cr.openjdk.java.net/~coleenp/8004883/
bug link at http://bugs.sun.com/view_bug.do?bug_id=8004883   (just 
filed, might not show up yet).

Ran nashorn tests again.

Thanks,
Coleen




From stefan.karlsson at oracle.com  Tue Dec 11 15:12:28 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 12 Dec 2012 00:12:28 +0100
Subject: Request for review 8004883: NPG: clean up anonymous class fix
In-Reply-To: <50C7B10B.6010408@oracle.com>
References: <50C7B10B.6010408@oracle.com>
Message-ID: <50C7BDDC.5050305@oracle.com>

Looks good. Thanks for doing this as a separate cleanup.

Did you need these changes to get it to compile?
http://cr.openjdk.java.net/~coleenp/8004883/src/share/vm/opto/library_call.cpp.udiff.html

StefanK

On 12/11/12 11:17 PM, Coleen Phillimore wrote:
> Summary: Add klass_holder() to return either mirror or class_loader 
> depending on if the class is anonymous or not.
>
> Add code cleanup requested by John Rose and StefanK.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8004883/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=8004883   (just 
> filed, might not show up yet).
>
> Ran nashorn tests again.
>
> Thanks,
> Coleen
>
>
>


From coleen.phillimore at oracle.com  Tue Dec 11 15:13:49 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 11 Dec 2012 18:13:49 -0500
Subject: Request for review 8004883: NPG: clean up anonymous class fix
In-Reply-To: <50C7BDDC.5050305@oracle.com>
References: <50C7B10B.6010408@oracle.com> <50C7BDDC.5050305@oracle.com>
Message-ID: <50C7BE2D.8080202@oracle.com>


On 12/11/2012 06:12 PM, Stefan Karlsson wrote:
> Looks good. Thanks for doing this as a separate cleanup.
>
> Did you need these changes to get it to compile?
> http://cr.openjdk.java.net/~coleenp/8004883/src/share/vm/opto/library_call.cpp.udiff.html 
>

Yes, thanks!
Coleen
>
> StefanK
>
> On 12/11/12 11:17 PM, Coleen Phillimore wrote:
>> Summary: Add klass_holder() to return either mirror or class_loader 
>> depending on if the class is anonymous or not.
>>
>> Add code cleanup requested by John Rose and StefanK.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8004883/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8004883 (just 
>> filed, might not show up yet).
>>
>> Ran nashorn tests again.
>>
>> Thanks,
>> Coleen
>>
>>
>>
>


From eric.mccorkle at oracle.com  Tue Dec 11 15:18:14 2012
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 11 Dec 2012 18:18:14 -0500
Subject: Review request for: JDK-8004728 Add hotspot support for parameter
	reflection
Message-ID: <50C7BF36.6020405@oracle.com>

Apologies if this has already come across the list; it appears that it
didn't get through for some reason.

Please review the implementation of the following new feature:
https://jbs.oracle.com/bugs/browse/JDK-8004728


The open webrev is here:
http://oklahoma.us.oracle.com/~cphillim/webrev/8004728/


Summary:

This is the VM side of the implementation of method parameter
reflection.  The implementation has been tested by building and running
regression tests with javac hardwired to produce classfiles containing
MethodParameters attributes.

It will be further tested as part of the testing for the Reflection API
side of the implementation of this feature.

The specification of the feature is attached to the new feature request
above.


Thanks,
Eric

From john.r.rose at oracle.com  Tue Dec 11 15:21:25 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 11 Dec 2012 15:21:25 -0800
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <50C72FEE.5060203@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
	<50C72FEE.5060203@oracle.com>
Message-ID: <A0906C96-DF5A-4C8A-8B02-D54ED88BE4BF@oracle.com>

On Dec 11, 2012, at 1:30 PM, Aleksey Shipilev wrote:

> On 12/11/2012 02:44 AM, John Rose wrote:
>> This is good.  I have some comments on it.
> 
> Ok, this is the updated webrev fixing most of John's comments:
>  http://shipilev.net/pub/jdk/hotspot/contended/webrev-7/
> 
> Changes are:
>  - ClassFileParser::_is_contended is gone
>  - merged "privileged" machinery from John's patch into ClassFileParser
>  - FieldInfo::type -> FieldInfo::allocation_type
>  - two JVM options: -XX:+EnableContendedOnBCP, and
> -XX:-EnableContendedOnCP added, so that @Contended is no-op for
> non-privileged classes until you flip the switch

The option names say too much, IMO.  I suggest removing the "OnBCP" part, and have -XX:-EnableContended disable @Contended everywhere.  I assume it is for performance testing, and I think the simpler flag is more useful for that.  Also, in its simpler form, it is a flag we will be proud of even when the behavior of @Contended is adjusted or is made part of the official spec.

The name -XX:+EnableContendedOnCP suggests it is about the -classpath, but it's not really.  I like Michael Barker's suggestion -XX:-RestrictContendedToBootClassPath, but with a default of "true".  Or, better and more simply, -XX:-RestrictContended.  This flag can be thrown away when @Contended becomes official.

So:
-XX:-EnableContended (true by default) turns off @Contended detection everywhere
-XX:-RestrictContended (true by default) allows @Contended everywhere, assuming -XX:+EnableContended
+    if (!EnableContended || (RestrictContended && !privileged))    break;

Good cleanups on the annotation collectors and field info struct.

The field layout logic gives me heartburn; it always has.  Now its 2x worse.  Would you please file a followup bug to clean up and factor that code?

On Dec 11, 2012, at 5:06 AM, Aleksey Shipilev wrote:

>> ...The rework could use something like your tagging
>> scheme (which is clever) but have the exceptional tag value mean "I
>> have extended attributes specified in N additional words of data".
> 
> I think we have a little bit of mis-design about FieldInfo here. What
> allows me to piggyback on FieldInfo is that we clearly have the
> classload-scope (CS) metadata info for fields, and runtime-scope (RS)
> metadata info. That allows us to mangle CS data during the classload,
> knowing for sure we substitute that with RS after classload finishes.
> 
> This is probably a little dodgy when compared against sparse
> representation, but I feel uncomfortable rebuilding entire field
> attribute mechanics in the course of @Contended work.

It's totally dodgy.  It makes some sense if you are aiming at an in-memory copy of the classfile AST, but is not friendly to the JVM which is actually using the data.  If I were rewriting it, I would try to use a temporary FieldInfo structure with a simple but non-dense layout, and a packing phase which would put the necessary field metadata into a dense streamable form, in an array<u1>, using CompressedStream.  The FieldStream would unpack each successive field descriptor into the FieldInfo structure.  By using CompressedStream, the data structure would be 32-bit clean, leading to various other advantages.

>> In any case, this change overlaps with the following pending change
>> from mlvm, which also introduces a field annotation: 
>> http://hg.openjdk.java.net/mlvm/mlvm/hotspot/diff/b6f0babd7cf1/anno-stable-8001107.patch
> 
>> That change makes the various method and field annotations be no-op
>> outside of privileged code. This needs to be the case also with
>> @Contended.
> 
> OK, I can do that for @Contended as well, and guard this behavior with
> two flags, e.g. -XX:+EnableContendedOnBCP=true,
> -XX:+EnableContendedOnCP=false, and act accordingly. We can discuss
> separately what should be the default values for these flags.

See above.

>> Are there SA changes and new jtreg tests?  I didn't see them in this
>> webrev.
> 
> (sigh) Any pointers what should be done, and where the tests should be
> placed?

You'll need to adjust getFieldOffset in agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java, and adjust the constant names, and add at least some of your new constants for decoding.  Start with this:

  cd $repos/hotspot; grep -ni low_offset $(hg loc -I agent)

Your unit test should be runnable with jtreg.  I think you need something like this:

 * @run main/othervm -XX:-RestrictContended Test8003985

So that this works:

  cd $repos/hotspot; jtreg test/runtime/8003985/Test8003985.java

Thanks,

? John

From john.r.rose at oracle.com  Tue Dec 11 16:53:31 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 11 Dec 2012 16:53:31 -0800
Subject: Request for review 8004883: NPG: clean up anonymous class fix
In-Reply-To: <50C7B10B.6010408@oracle.com>
References: <50C7B10B.6010408@oracle.com>
Message-ID: <04951004-B7BE-4332-B6F4-95ABAD87A5E7@oracle.com>

I like it; nice and clean.  Thanks!  ? John

On Dec 11, 2012, at 2:17 PM, Coleen Phillimore wrote:

> Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not.
> 
> Add code cleanup requested by John Rose and StefanK.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8004883/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=8004883   (just filed, might not show up yet).
> 
> Ran nashorn tests again.


From david.holmes at oracle.com  Tue Dec 11 18:13:23 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Dec 2012 12:13:23 +1000
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C7B0E6.6000602@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
	<1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com>
Message-ID: <50C7E843.9020006@oracle.com>

I think the library_call issue is the only thing that still needs 
working on.

David

On 12/12/2012 8:17 AM, Coleen Phillimore wrote:
>
> On 12/11/2012 05:00 PM, Roman Kennke wrote:
>> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
>>> Now I hit this library_call.cpp compilation error. Has it been pushed
>>> yet? I was going to piggyback this with another cleanup that I was
>>> making if not.
>> No, it has not been pushed yet. :-(
>>
>> Seems like all my patches have become stuck in the queue. Is there
>> anything that I can do to make them move forward? Should I file them in
>> openjdk bugzilla?
>
> What you are doing is the right way to submit patches. We don't really
> monitor openjdk bugzilla. I think people are working on your other patches.
>
> thanks,
> Coleen
>
>>
>> Regards,
>> Roman
>>
>>> thanks,
>>> Coleen
>>>
>>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
>>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
>>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
>>>>> repository and will/have been pushed up to main already. They should
>>>>> already be in hotspot-comp.
>>>> Ah great, good to see, thanks! :-)
>>>>
>>>>> Which compiler complains about the library_call.cpp changes? I have an
>>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
>>>>> file compiles fine for me as is.
>>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
>>>> improvements from dev versions sometimes... I agree with David, it
>>>> would
>>>> be good to fix in any case.
>>>>
>>>> Thanks,
>>>> Roman
>>>>
>>>>
>>
>

From david.holmes at oracle.com  Tue Dec 11 18:18:42 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Dec 2012 12:18:42 +1000
Subject: Request for review 8004883: NPG: clean up anonymous class fix
In-Reply-To: <50C7BE2D.8080202@oracle.com>
References: <50C7B10B.6010408@oracle.com> <50C7BDDC.5050305@oracle.com>
	<50C7BE2D.8080202@oracle.com>
Message-ID: <50C7E982.9070709@oracle.com>

On 12/12/2012 9:13 AM, Coleen Phillimore wrote:
>
> On 12/11/2012 06:12 PM, Stefan Karlsson wrote:
>> Looks good. Thanks for doing this as a separate cleanup.
>>
>> Did you need these changes to get it to compile?
>> http://cr.openjdk.java.net/~coleenp/8004883/src/share/vm/opto/library_call.cpp.udiff.html
>>
>
> Yes, thanks!

There is already a bug for that issue being worked on by Christian:

https://jbs.oracle.com/bugs/browse/JDK-8004898

Came in via a separate report on the compiler list

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html

David
-----

> Coleen
>>
>> StefanK
>>
>> On 12/11/12 11:17 PM, Coleen Phillimore wrote:
>>> Summary: Add klass_holder() to return either mirror or class_loader
>>> depending on if the class is anonymous or not.
>>>
>>> Add code cleanup requested by John Rose and StefanK.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8004883/
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8004883 (just
>>> filed, might not show up yet).
>>>
>>> Ran nashorn tests again.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>>
>>
>

From david.holmes at oracle.com  Tue Dec 11 18:42:32 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Dec 2012 12:42:32 +1000
Subject: Review request for: JDK-8004728 Add hotspot support for parameter
	reflection
In-Reply-To: <50C7BF36.6020405@oracle.com>
References: <50C7BF36.6020405@oracle.com>
Message-ID: <50C7EF18.5070703@oracle.com>

Hi Erik,

On 12/12/2012 9:18 AM, Eric McCorkle wrote:
> Apologies if this has already come across the list; it appears that it
> didn't get through for some reason.
>
> Please review the implementation of the following new feature:
> https://jbs.oracle.com/bugs/browse/JDK-8004728
>
>
> The open webrev is here:
> http://oklahoma.us.oracle.com/~cphillim/webrev/8004728/

Neither of the links above are available to non-Oracle OpenJDK community 
members. Please transfer the webrev to cr.openjdk.java.net - thanks.

The bug is available at:

http://bugs.sun.com/view_bug.do?bug_id=8004728

but contains no useful information.

> Summary:
>
> This is the VM side of the implementation of method parameter
> reflection.  The implementation has been tested by building and running
> regression tests with javac hardwired to produce classfiles containing
> MethodParameters attributes.

Just a superficial comment after a quick skim, we tend not to use types 
like u4 in general code. So for example in jvm.cpp and 
reflection.hpp/cpp we would not use it there.

I assume no space is allocated for method parameter information if none 
is needed?

> It will be further tested as part of the testing for the Reflection API
> side of the implementation of this feature.
>
> The specification of the feature is attached to the new feature request
> above.

The Jira attachment is not available outside of Oracle. Please provide a 
link to a publicly accessible document.

Thanks,
David

>
> Thanks,
> Eric

From rkennke at redhat.com  Wed Dec 12 00:19:26 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 12 Dec 2012 09:19:26 +0100
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C7E843.9020006@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
	<1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com>
	<50C7E843.9020006@oracle.com>
Message-ID: <1355300366.1747.169.camel@mercury>

Hi David,

>From my perspective, there are the following proposed changes not
committed yet:

1.
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html

>From that one, only the jdk part is missing:
http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/

I think it's the only one with a bug-id even:
8003868: fix shark for latest HotSpot and LLVM

2. Then there is the library_call build fixes. (Which have also been
proposed by Yasumasa Suenaga, which now got the bug id 8004898 and
Christian is working on it.)

Then I posted a bunch of others on hotspot-compiler-dev (maybe
hotspot-dev would have been better?)

3. Fix OSR in Shark for non-empty incoming stack
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html

This one got a little review by David Chase, for which I will send an
updated webrev soon. I was hoping to get some more feedback though, or
even a bug-id.

4. Implement deoptimization support in Shark
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html

This one did not get any feedback yet, no bug-id either.

5. Fix volatile float field access in Shark 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html

Same, no feedback, no bug-id.

6. Enable JSR292 support in Shark
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html

Got some positive feedback from John Rose, but no bug id and no
progress.

Please let me know if I should do anything different in the future
(different mailing list, different format, ..) Also, if it helps, I can
group all those changes into one big change, I just thought that it is
easier to review in logical chunks (otherwise the changes would
interleave and it's difficult to say what belongs to what).


Thanks for your cooperation!

Best regards,
Roman


> I think the library_call issue is the only thing that still needs 
> working on.
> 
> David
> 
> On 12/12/2012 8:17 AM, Coleen Phillimore wrote:
> >
> > On 12/11/2012 05:00 PM, Roman Kennke wrote:
> >> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
> >>> Now I hit this library_call.cpp compilation error. Has it been pushed
> >>> yet? I was going to piggyback this with another cleanup that I was
> >>> making if not.
> >> No, it has not been pushed yet. :-(
> >>
> >> Seems like all my patches have become stuck in the queue. Is there
> >> anything that I can do to make them move forward? Should I file them in
> >> openjdk bugzilla?
> >
> > What you are doing is the right way to submit patches. We don't really
> > monitor openjdk bugzilla. I think people are working on your other patches.
> >
> > thanks,
> > Coleen
> >
> >>
> >> Regards,
> >> Roman
> >>
> >>> thanks,
> >>> Coleen
> >>>
> >>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
> >>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
> >>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
> >>>>> repository and will/have been pushed up to main already. They should
> >>>>> already be in hotspot-comp.
> >>>> Ah great, good to see, thanks! :-)
> >>>>
> >>>>> Which compiler complains about the library_call.cpp changes? I have an
> >>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
> >>>>> file compiles fine for me as is.
> >>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
> >>>> improvements from dev versions sometimes... I agree with David, it
> >>>> would
> >>>> be good to fix in any case.
> >>>>
> >>>> Thanks,
> >>>> Roman
> >>>>
> >>>>
> >>
> >



From david.holmes at oracle.com  Wed Dec 12 01:27:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Dec 2012 19:27:49 +1000
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <1355300366.1747.169.camel@mercury>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
	<1355263212.1747.154.camel@mercury>
	<50C7B0E6.6000602@oracle.com> <50C7E843.9020006@oracle.com>
	<1355300366.1747.169.camel@mercury>
Message-ID: <50C84E15.5010407@oracle.com>

On 12/12/2012 6:19 PM, Roman Kennke wrote:
> Hi David,
>
>  From my perspective, there are the following proposed changes not
> committed yet:

Sorry I was only referring to gcc4.7 specific issues.

For the other patches you are doing the right thing, it is just 
unfortunate that there is a lot happening right now (M6 is just around 
the corner) and people have a lot on their plate.

David
-----


> 1.
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html
>
>  From that one, only the jdk part is missing:
> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/
>
> I think it's the only one with a bug-id even:
> 8003868: fix shark for latest HotSpot and LLVM
>
> 2. Then there is the library_call build fixes. (Which have also been
> proposed by Yasumasa Suenaga, which now got the bug id 8004898 and
> Christian is working on it.)
>
> Then I posted a bunch of others on hotspot-compiler-dev (maybe
> hotspot-dev would have been better?)
>
> 3. Fix OSR in Shark for non-empty incoming stack
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html
>
> This one got a little review by David Chase, for which I will send an
> updated webrev soon. I was hoping to get some more feedback though, or
> even a bug-id.
>
> 4. Implement deoptimization support in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html
>
> This one did not get any feedback yet, no bug-id either.
>
> 5. Fix volatile float field access in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html
>
> Same, no feedback, no bug-id.
>
> 6. Enable JSR292 support in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html
>
> Got some positive feedback from John Rose, but no bug id and no
> progress.
>
> Please let me know if I should do anything different in the future
> (different mailing list, different format, ..) Also, if it helps, I can
> group all those changes into one big change, I just thought that it is
> easier to review in logical chunks (otherwise the changes would
> interleave and it's difficult to say what belongs to what).
>
>
> Thanks for your cooperation!
>
> Best regards,
> Roman
>
>
>> I think the library_call issue is the only thing that still needs
>> working on.
>>
>> David
>>
>> On 12/12/2012 8:17 AM, Coleen Phillimore wrote:
>>>
>>> On 12/11/2012 05:00 PM, Roman Kennke wrote:
>>>> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
>>>>> Now I hit this library_call.cpp compilation error. Has it been pushed
>>>>> yet? I was going to piggyback this with another cleanup that I was
>>>>> making if not.
>>>> No, it has not been pushed yet. :-(
>>>>
>>>> Seems like all my patches have become stuck in the queue. Is there
>>>> anything that I can do to make them move forward? Should I file them in
>>>> openjdk bugzilla?
>>>
>>> What you are doing is the right way to submit patches. We don't really
>>> monitor openjdk bugzilla. I think people are working on your other patches.
>>>
>>> thanks,
>>> Coleen
>>>
>>>>
>>>> Regards,
>>>> Roman
>>>>
>>>>> thanks,
>>>>> Coleen
>>>>>
>>>>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
>>>>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
>>>>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
>>>>>>> repository and will/have been pushed up to main already. They should
>>>>>>> already be in hotspot-comp.
>>>>>> Ah great, good to see, thanks! :-)
>>>>>>
>>>>>>> Which compiler complains about the library_call.cpp changes? I have an
>>>>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
>>>>>>> file compiles fine for me as is.
>>>>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
>>>>>> improvements from dev versions sometimes... I agree with David, it
>>>>>> would
>>>>>> be good to fix in any case.
>>>>>>
>>>>>> Thanks,
>>>>>> Roman
>>>>>>
>>>>>>
>>>>
>>>
>
>

From rkennke at redhat.com  Wed Dec 12 01:31:49 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 12 Dec 2012 10:31:49 +0100
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <50C84E15.5010407@oracle.com>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
	<1355263212.1747.154.camel@mercury> <50C7B0E6.6000602@oracle.com>
	<50C7E843.9020006@oracle.com> <1355300366.1747.169.camel@mercury>
	<50C84E15.5010407@oracle.com>
Message-ID: <1355304709.1747.170.camel@mercury>

Am Mittwoch, den 12.12.2012, 19:27 +1000 schrieb David Holmes:
> On 12/12/2012 6:19 PM, Roman Kennke wrote:
> > Hi David,
> >
> >  From my perspective, there are the following proposed changes not
> > committed yet:
> 
> Sorry I was only referring to gcc4.7 specific issues.
> 
> For the other patches you are doing the right thing, it is just 
> unfortunate that there is a lot happening right now (M6 is just around 
> the corner) and people have a lot on their plate.

Aha, good to know. This is fine then. :-)

Cheers,
Roman

> 
> David
> -----
> 
> 
> > 1.
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html
> >
> >  From that one, only the jdk part is missing:
> > http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/
> >
> > I think it's the only one with a bug-id even:
> > 8003868: fix shark for latest HotSpot and LLVM
> >
> > 2. Then there is the library_call build fixes. (Which have also been
> > proposed by Yasumasa Suenaga, which now got the bug id 8004898 and
> > Christian is working on it.)
> >
> > Then I posted a bunch of others on hotspot-compiler-dev (maybe
> > hotspot-dev would have been better?)
> >
> > 3. Fix OSR in Shark for non-empty incoming stack
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html
> >
> > This one got a little review by David Chase, for which I will send an
> > updated webrev soon. I was hoping to get some more feedback though, or
> > even a bug-id.
> >
> > 4. Implement deoptimization support in Shark
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html
> >
> > This one did not get any feedback yet, no bug-id either.
> >
> > 5. Fix volatile float field access in Shark
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html
> >
> > Same, no feedback, no bug-id.
> >
> > 6. Enable JSR292 support in Shark
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html
> >
> > Got some positive feedback from John Rose, but no bug id and no
> > progress.
> >
> > Please let me know if I should do anything different in the future
> > (different mailing list, different format, ..) Also, if it helps, I can
> > group all those changes into one big change, I just thought that it is
> > easier to review in logical chunks (otherwise the changes would
> > interleave and it's difficult to say what belongs to what).
> >
> >
> > Thanks for your cooperation!
> >
> > Best regards,
> > Roman
> >
> >
> >> I think the library_call issue is the only thing that still needs
> >> working on.
> >>
> >> David
> >>
> >> On 12/12/2012 8:17 AM, Coleen Phillimore wrote:
> >>>
> >>> On 12/11/2012 05:00 PM, Roman Kennke wrote:
> >>>> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
> >>>>> Now I hit this library_call.cpp compilation error. Has it been pushed
> >>>>> yet? I was going to piggyback this with another cleanup that I was
> >>>>> making if not.
> >>>> No, it has not been pushed yet. :-(
> >>>>
> >>>> Seems like all my patches have become stuck in the queue. Is there
> >>>> anything that I can do to make them move forward? Should I file them in
> >>>> openjdk bugzilla?
> >>>
> >>> What you are doing is the right way to submit patches. We don't really
> >>> monitor openjdk bugzilla. I think people are working on your other patches.
> >>>
> >>> thanks,
> >>> Coleen
> >>>
> >>>>
> >>>> Regards,
> >>>> Roman
> >>>>
> >>>>> thanks,
> >>>>> Coleen
> >>>>>
> >>>>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
> >>>>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
> >>>>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
> >>>>>>> repository and will/have been pushed up to main already. They should
> >>>>>>> already be in hotspot-comp.
> >>>>>> Ah great, good to see, thanks! :-)
> >>>>>>
> >>>>>>> Which compiler complains about the library_call.cpp changes? I have an
> >>>>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
> >>>>>>> file compiles fine for me as is.
> >>>>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
> >>>>>> improvements from dev versions sometimes... I agree with David, it
> >>>>>> would
> >>>>>> be good to fix in any case.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Roman
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >
> >



From erik.helin at oracle.com  Wed Dec 12 01:34:57 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 12 Dec 2012 10:34:57 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
Message-ID: <50C84FC1.90308@oracle.com>

Hi all,

the webrev is located at:

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

Summary:
When I browsed the code during a code review, I noticed the macro
VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
used to describe that all instances of a given C++ class can never be 
placed on (or removed from) the heap with the operations new or delete.

This is enforced by the class _ValueObj which implements the operators
new and delete by calling ShouldNotCallThis which will crash the VM.

The operators new and delete in _ValueObj are declared public
and this change instead declares them as private. This has the effect
of enforcing the above described restrictions at compile time.

The following three classes inherited from _ValueObj even though they
made use of either the new or delete operator:
- RegMask:
   The functions Node::out_regMask and Node::in_regMask are defined as:
   void RegMask &Node::out_regMask() const {
     ShouldNotCallThis();
     return *(new RegMask());
   }
   Both out_regMask and in_regMask are overridden by subclasses and they
   are not meant to be called on a Node object (as can be seen by the
   call ShouldNotCallThis). This is the only place where a RegMask
   object is allocated with new. There are two solutions to this problem:
   - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
   - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
     RegMask
   This CR presents a work around to the problem instead of removing
   VALUE_OBJ_CLASS_SPEC.

- MemBaseLine
   MemBaseLine has a virtual destructor which is not possible together
   with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
   can be removed, but I chose to make the destructor non-virtual since
   no class currently inherits from MemBaseline.

- AbstractGangTask
   AbstactGangTask has a virtual destructor _and_ there are classes
   inheriting from AbstractGangTask. The problem is that a class that
   defines a virtual destructor in C++ must also have a (working) delete
   operator in scope. The current delete operator is not working (it only
   calls ShouldNotReachHere), therefore my suggestion is to remove
   VALUE_OBJ_CLASS_SPEC from AbstractGangTask.

   How could this work before? I haven't checked that thoroughly, but I
   believe that no code calls delete on an AbstractGangTask pointer. If
   this is true, then the destructor in AbstractGangTask could be
   declared non-virtual, but I don't want to take that risk.

This change also changes the new and delete operations of "StackObj"
to be private (for the same reasons). This did not cause changes in any
other code.

Testing:
JPRT

Thanks,
Erik

From david.holmes at oracle.com  Wed Dec 12 02:01:56 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Dec 2012 20:01:56 +1000
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C84FC1.90308@oracle.com>
References: <50C84FC1.90308@oracle.com>
Message-ID: <50C85614.2000900@oracle.com>

Hi Erik,

Doesn't the change to AbstractGangTask break the rule that all VM types 
must inherit from one of the allocation classes ?

I'm not sure that your reasoning about virtual destructors and operator 
delete is correct. It is possible to call destructors directly without 
deleting the object. Need to think more about this ... and see what 
others (Hi Coleen!) have to say.

Cheers,
David

On 12/12/2012 7:34 PM, Erik Helin wrote:
> Hi all,
>
> the webrev is located at:
>
> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>
> Summary:
> When I browsed the code during a code review, I noticed the macro
> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
> used to describe that all instances of a given C++ class can never be
> placed on (or removed from) the heap with the operations new or delete.
>
> This is enforced by the class _ValueObj which implements the operators
> new and delete by calling ShouldNotCallThis which will crash the VM.
>
> The operators new and delete in _ValueObj are declared public
> and this change instead declares them as private. This has the effect
> of enforcing the above described restrictions at compile time.
>
> The following three classes inherited from _ValueObj even though they
> made use of either the new or delete operator:
> - RegMask:
> The functions Node::out_regMask and Node::in_regMask are defined as:
> void RegMask &Node::out_regMask() const {
> ShouldNotCallThis();
> return *(new RegMask());
> }
> Both out_regMask and in_regMask are overridden by subclasses and they
> are not meant to be called on a Node object (as can be seen by the
> call ShouldNotCallThis). This is the only place where a RegMask
> object is allocated with new. There are two solutions to this problem:
> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
> RegMask
> This CR presents a work around to the problem instead of removing
> VALUE_OBJ_CLASS_SPEC.
>
> - MemBaseLine
> MemBaseLine has a virtual destructor which is not possible together
> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
> can be removed, but I chose to make the destructor non-virtual since
> no class currently inherits from MemBaseline.
>
> - AbstractGangTask
> AbstactGangTask has a virtual destructor _and_ there are classes
> inheriting from AbstractGangTask. The problem is that a class that
> defines a virtual destructor in C++ must also have a (working) delete
> operator in scope. The current delete operator is not working (it only
> calls ShouldNotReachHere), therefore my suggestion is to remove
> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>
> How could this work before? I haven't checked that thoroughly, but I
> believe that no code calls delete on an AbstractGangTask pointer. If
> this is true, then the destructor in AbstractGangTask could be
> declared non-virtual, but I don't want to take that risk.
>
> This change also changes the new and delete operations of "StackObj"
> to be private (for the same reasons). This did not cause changes in any
> other code.
>
> Testing:
> JPRT
>
> Thanks,
> Erik

From erik.helin at oracle.com  Wed Dec 12 02:16:31 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 12 Dec 2012 11:16:31 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C85614.2000900@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
Message-ID: <50C8597F.3060309@oracle.com>

Hi David,

thanks for the review! See comments inline.

On 12/12/2012 11:01 AM, David Holmes wrote:
> Doesn't the change to AbstractGangTask break the rule that all VM types
> must inherit from one of the allocation classes ?

I wasn't aware of this rule, thanks for bringing it up. Is the class 
CheapObj the one that other classes should derive from if it is possible 
to put instances of the class on the heap?

On 12/12/2012 11:01 AM, David Holmes wrote:
> I'm not sure that your reasoning about virtual destructors and operator
> delete is correct. It is possible to call destructors directly without
> deleting the object. Need to think more about this ... and see what
> others (Hi Coleen!) have to say.

I'm not completely sure why you can't have virtual destructor and 
private delete operator. The following small sample shows that you can't 
have private delete operator and a virtual destructor:

class A {
   private:
     void operator delete(void *) { }
};

class B : public A {
  public:
   B() { }
   virtual ~B() { }
};

 > g++ -c foo.cpp
foo.cpp: In destructor ?virtual B::~B()?:
foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
foo.cpp:9:18: error: within this context
foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
foo.cpp:9:18: error: within this context
foo.cpp: In destructor ?virtual B::~B()?:
foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
foo.cpp:9:18: error: within this context
foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
foo.cpp:9:18: error: within this context

Thanks,
Erik

> Cheers,
> David
>
> On 12/12/2012 7:34 PM, Erik Helin wrote:
>> Hi all,
>>
>> the webrev is located at:
>>
>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>
>> Summary:
>> When I browsed the code during a code review, I noticed the macro
>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>> used to describe that all instances of a given C++ class can never be
>> placed on (or removed from) the heap with the operations new or delete.
>>
>> This is enforced by the class _ValueObj which implements the operators
>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>
>> The operators new and delete in _ValueObj are declared public
>> and this change instead declares them as private. This has the effect
>> of enforcing the above described restrictions at compile time.
>>
>> The following three classes inherited from _ValueObj even though they
>> made use of either the new or delete operator:
>> - RegMask:
>> The functions Node::out_regMask and Node::in_regMask are defined as:
>> void RegMask &Node::out_regMask() const {
>> ShouldNotCallThis();
>> return *(new RegMask());
>> }
>> Both out_regMask and in_regMask are overridden by subclasses and they
>> are not meant to be called on a Node object (as can be seen by the
>> call ShouldNotCallThis). This is the only place where a RegMask
>> object is allocated with new. There are two solutions to this problem:
>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
>> RegMask
>> This CR presents a work around to the problem instead of removing
>> VALUE_OBJ_CLASS_SPEC.
>>
>> - MemBaseLine
>> MemBaseLine has a virtual destructor which is not possible together
>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>> can be removed, but I chose to make the destructor non-virtual since
>> no class currently inherits from MemBaseline.
>>
>> - AbstractGangTask
>> AbstactGangTask has a virtual destructor _and_ there are classes
>> inheriting from AbstractGangTask. The problem is that a class that
>> defines a virtual destructor in C++ must also have a (working) delete
>> operator in scope. The current delete operator is not working (it only
>> calls ShouldNotReachHere), therefore my suggestion is to remove
>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>
>> How could this work before? I haven't checked that thoroughly, but I
>> believe that no code calls delete on an AbstractGangTask pointer. If
>> this is true, then the destructor in AbstractGangTask could be
>> declared non-virtual, but I don't want to take that risk.
>>
>> This change also changes the new and delete operations of "StackObj"
>> to be private (for the same reasons). This did not cause changes in any
>> other code.
>>
>> Testing:
>> JPRT
>>
>> Thanks,
>> Erik


From david.holmes at oracle.com  Wed Dec 12 02:50:57 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Dec 2012 20:50:57 +1000
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C8597F.3060309@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com>
Message-ID: <50C86191.7050702@oracle.com>

On 12/12/2012 8:16 PM, Erik Helin wrote:
> Hi David,
>
> thanks for the review! See comments inline.
>
> On 12/12/2012 11:01 AM, David Holmes wrote:
>> Doesn't the change to AbstractGangTask break the rule that all VM types
>> must inherit from one of the allocation classes ?
>
> I wasn't aware of this rule, thanks for bringing it up. Is the class
> CheapObj the one that other classes should derive from if it is possible
> to put instances of the class on the heap?

Yes. See the comments in allocation.hpp.

> On 12/12/2012 11:01 AM, David Holmes wrote:
>> I'm not sure that your reasoning about virtual destructors and operator
>> delete is correct. It is possible to call destructors directly without
>> deleting the object. Need to think more about this ... and see what
>> others (Hi Coleen!) have to say.
>
> I'm not completely sure why you can't have virtual destructor and
> private delete operator. The following small sample shows that you can't
> have private delete operator and a virtual destructor:
>
> class A {
> private:
> void operator delete(void *) { }
> };
>
> class B : public A {
> public:
> B() { }
> virtual ~B() { }
> };
>
>  > g++ -c foo.cpp
> foo.cpp: In destructor ?virtual B::~B()?:
> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
> foo.cpp:9:18: error: within this context
> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
> foo.cpp:9:18: error: within this context
> foo.cpp: In destructor ?virtual B::~B()?:
> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
> foo.cpp:9:18: error: within this context
> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
> foo.cpp:9:18: error: within this context

Okay that kind of makes sense. I was thinking more about them being in 
the same class.

But this just says to me "don't make new/delete private". (Think of them 
like virtual methods on Object - you can redefine them but they are 
always public ;-) )

David

> Thanks,
> Erik
>
>> Cheers,
>> David
>>
>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>> Hi all,
>>>
>>> the webrev is located at:
>>>
>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>
>>> Summary:
>>> When I browsed the code during a code review, I noticed the macro
>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>> used to describe that all instances of a given C++ class can never be
>>> placed on (or removed from) the heap with the operations new or delete.
>>>
>>> This is enforced by the class _ValueObj which implements the operators
>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>
>>> The operators new and delete in _ValueObj are declared public
>>> and this change instead declares them as private. This has the effect
>>> of enforcing the above described restrictions at compile time.
>>>
>>> The following three classes inherited from _ValueObj even though they
>>> made use of either the new or delete operator:
>>> - RegMask:
>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>> void RegMask &Node::out_regMask() const {
>>> ShouldNotCallThis();
>>> return *(new RegMask());
>>> }
>>> Both out_regMask and in_regMask are overridden by subclasses and they
>>> are not meant to be called on a Node object (as can be seen by the
>>> call ShouldNotCallThis). This is the only place where a RegMask
>>> object is allocated with new. There are two solutions to this problem:
>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
>>> RegMask
>>> This CR presents a work around to the problem instead of removing
>>> VALUE_OBJ_CLASS_SPEC.
>>>
>>> - MemBaseLine
>>> MemBaseLine has a virtual destructor which is not possible together
>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>> can be removed, but I chose to make the destructor non-virtual since
>>> no class currently inherits from MemBaseline.
>>>
>>> - AbstractGangTask
>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>> inheriting from AbstractGangTask. The problem is that a class that
>>> defines a virtual destructor in C++ must also have a (working) delete
>>> operator in scope. The current delete operator is not working (it only
>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>
>>> How could this work before? I haven't checked that thoroughly, but I
>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>> this is true, then the destructor in AbstractGangTask could be
>>> declared non-virtual, but I don't want to take that risk.
>>>
>>> This change also changes the new and delete operations of "StackObj"
>>> to be private (for the same reasons). This did not cause changes in any
>>> other code.
>>>
>>> Testing:
>>> JPRT
>>>
>>> Thanks,
>>> Erik
>

From erik.helin at oracle.com  Wed Dec 12 05:13:35 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Wed, 12 Dec 2012 14:13:35 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C86191.7050702@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
Message-ID: <50C882FF.2000006@oracle.com>

David,

On 12/12/2012 11:50 AM, David Holmes wrote:
>> class A {
>> private:
>> void operator delete(void *) { }
>> };
>>
>> class B : public A {
>> public:
>> B() { }
>> virtual ~B() { }
>> };
>>
>>  > g++ -c foo.cpp
>> foo.cpp: In destructor ?virtual B::~B()?:
>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>> foo.cpp:9:18: error: within this context
>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>> foo.cpp:9:18: error: within this context
>> foo.cpp: In destructor ?virtual B::~B()?:
>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>> foo.cpp:9:18: error: within this context
>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>> foo.cpp:9:18: error: within this context
>
> Okay that kind of makes sense. I was thinking more about them being in
> the same class.
>
> But this just says to me "don't make new/delete private". (Think of them
> like virtual methods on Object - you can redefine them but they are
> always public ;-) )

I believe that the benefit of making new/delete private is that we get 
compile time checking instead of maybe finding out via tests in JPRT (if 
the tests does not traverse a code path with incorrect usage, then we 
won't find it).

In my opinion, if a class has a virtual destructor and inherits from 
_ValueObj or StackObj, then either the destructor shouldn't be virtual 
or the class should not inherit from _ValueObj or StackObj.

As far as I can see, the only use for a _virtual_ destructor in a class 
is if you want to delete a pointer to that class (and make sure that the 
destructor of any class inheriting from that class also gets called). 
 From what I understand, deriving from _ValueObj or StackObj means that 
you don't expect this to happen.

What do you think of this?

Thanks for taking your time,
Erik

> David
>
>> Thanks,
>> Erik
>>
>>> Cheers,
>>> David
>>>
>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>> Hi all,
>>>>
>>>> the webrev is located at:
>>>>
>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>
>>>> Summary:
>>>> When I browsed the code during a code review, I noticed the macro
>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>>> used to describe that all instances of a given C++ class can never be
>>>> placed on (or removed from) the heap with the operations new or delete.
>>>>
>>>> This is enforced by the class _ValueObj which implements the operators
>>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>>
>>>> The operators new and delete in _ValueObj are declared public
>>>> and this change instead declares them as private. This has the effect
>>>> of enforcing the above described restrictions at compile time.
>>>>
>>>> The following three classes inherited from _ValueObj even though they
>>>> made use of either the new or delete operator:
>>>> - RegMask:
>>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>>> void RegMask &Node::out_regMask() const {
>>>> ShouldNotCallThis();
>>>> return *(new RegMask());
>>>> }
>>>> Both out_regMask and in_regMask are overridden by subclasses and they
>>>> are not meant to be called on a Node object (as can be seen by the
>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>> object is allocated with new. There are two solutions to this problem:
>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
>>>> RegMask
>>>> This CR presents a work around to the problem instead of removing
>>>> VALUE_OBJ_CLASS_SPEC.
>>>>
>>>> - MemBaseLine
>>>> MemBaseLine has a virtual destructor which is not possible together
>>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>>> can be removed, but I chose to make the destructor non-virtual since
>>>> no class currently inherits from MemBaseline.
>>>>
>>>> - AbstractGangTask
>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>> defines a virtual destructor in C++ must also have a (working) delete
>>>> operator in scope. The current delete operator is not working (it only
>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>
>>>> How could this work before? I haven't checked that thoroughly, but I
>>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>>> this is true, then the destructor in AbstractGangTask could be
>>>> declared non-virtual, but I don't want to take that risk.
>>>>
>>>> This change also changes the new and delete operations of "StackObj"
>>>> to be private (for the same reasons). This did not cause changes in any
>>>> other code.
>>>>
>>>> Testing:
>>>> JPRT
>>>>
>>>> Thanks,
>>>> Erik
>>


From stefan.karlsson at oracle.com  Wed Dec 12 05:30:20 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 12 Dec 2012 14:30:20 +0100
Subject: Review request for: JDK-8004728 Add hotspot support for parameter
	reflection
In-Reply-To: <50C7BF36.6020405@oracle.com>
References: <50C7BF36.6020405@oracle.com>
Message-ID: <50C886EC.9040003@oracle.com>

Hi Eric,

This is not a full review, but I have a comment regarding one part of 
the code.

http://oklahoma.us.oracle.com/~cphillim/webrev/8004728/src/share/vm/prims/jvm.cpp.udiff.html

+JVM_ENTRY(jobjectArray, JVM_GetMethodParameters(JNIEnv *env, jobject method))
+{
+  JVMWrapper("JVM_GetMethodParameters");
+
+  // method is a handle to a java.lang.reflect.Method object
+  Method* const m = jvm_get_method_common(method, CHECK_NULL);
+  const u4 num_params = m->method_parameters_length();
+  objArrayOop r = oopFactory::new_objArray(SystemDictionary::reflect_Parameter_klass(), num_params, CHECK_NULL);  // <-- GC can run here
+  objArrayHandle result (THREAD, r);
+  MethodParametersElement* params = m->method_parameters_start();
+  Handle executable (THREAD, JNIHandles::resolve_non_null(method));
+
+  for(u4 i = 0; i < num_params; i++) {
+    Symbol* sym = m->constants()->symbol_at(params[i].name_cp_index);
+    oop param = Reflection::new_parameter(executable, i, sym,
+                                          params[i].flags, CHECK_NULL);// <-- GC can run here
+    result->obj_at_put(i, param);
+  }
+  return (jobjectArray)JNIHandles::make_local(env, result());
+}
+JVM_END

Because of the way we deallocate methods after a class redefinition, you 
have to use methodHandles instead of Method*s whenever we might block 
for a GC.

See bug: http://bugs.sun.com/view_bug.do?bug_id=8004815

SefanK

On 12/12/2012 12:18 AM, Eric McCorkle wrote:
> Apologies if this has already come across the list; it appears that it
> didn't get through for some reason.
>
> Please review the implementation of the following new feature:
> https://jbs.oracle.com/bugs/browse/JDK-8004728
>
>
> The open webrev is here:
> http://oklahoma.us.oracle.com/~cphillim/webrev/8004728/
>
>
> Summary:
>
> This is the VM side of the implementation of method parameter
> reflection.  The implementation has been tested by building and running
> regression tests with javac hardwired to produce classfiles containing
> MethodParameters attributes.
>
> It will be further tested as part of the testing for the Reflection API
> side of the implementation of this feature.
>
> The specification of the feature is attached to the new feature request
> above.
>
>
> Thanks,
> Eric


From aleksey.shipilev at oracle.com  Wed Dec 12 07:08:25 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 12 Dec 2012 19:08:25 +0400
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <A0906C96-DF5A-4C8A-8B02-D54ED88BE4BF@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
	<50C72FEE.5060203@oracle.com>
	<A0906C96-DF5A-4C8A-8B02-D54ED88BE4BF@oracle.com>
Message-ID: <50C89DE9.6080308@oracle.com>

Thanks John,

The updated version is here:
  http://shipilev.net/pub/jdk/hotspot/contended/webrev-8/

Testing:
  - built and tested on Linux x86_64
  - Test8003985 passes on Linux x86_64
  - JPRT is acting corky today, will try to submit a job later

Meanwhile, please take a look at the code.

Comments follow:

On 12/12/2012 03:21 AM, John Rose wrote:
> -XX:-EnableContended (true by default) turns off @Contended detection everywhere
> -XX:-RestrictContended (true by default) allows @Contended everywhere, assuming -XX:+EnableContended
> +    if (!EnableContended || (RestrictContended && !privileged))    break;

Good, changed to EnableContended and RestrictContended.

> The field layout logic gives me heartburn; it always has.  

I hear you. Done: JDK-8004930.

>> (sigh) Any pointers what should be done, and where the tests should be
>> placed?
> 
> You'll need to adjust getFieldOffset in agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java, and adjust the constant names, and add at least some of your new constants for decoding.  Start with this:

Aha. I had pushed some of the predefined constants down to SA. Since
only the field offset should be accessible to SA, I've gone no further
than checking the proper tag for offset in getFieldOffset() and decoding
the proper offset.

> Your unit test should be runnable with jtreg.  I think you need something like this:
>  * @run main/othervm -XX:-RestrictContended Test8003985

Aha, thanks! Turns out the test needed to throw exception on failure to
actually test anything, fixed now.

-Aleksey.

From coleen.phillimore at oracle.com  Wed Dec 12 07:58:27 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 12 Dec 2012 10:58:27 -0500
Subject: Request for review 8004883: NPG: clean up anonymous class fix
In-Reply-To: <50C7E982.9070709@oracle.com>
References: <50C7B10B.6010408@oracle.com> <50C7BDDC.5050305@oracle.com>
	<50C7BE2D.8080202@oracle.com> <50C7E982.9070709@oracle.com>
Message-ID: <50C8A9A3.2050401@oracle.com>


I'll revert the library_call change because it was contributed by 
someone else.   I didn't realize there was a bug already, thanks David.
Coleen

On 12/11/2012 9:18 PM, David Holmes wrote:
> On 12/12/2012 9:13 AM, Coleen Phillimore wrote:
>>
>> On 12/11/2012 06:12 PM, Stefan Karlsson wrote:
>>> Looks good. Thanks for doing this as a separate cleanup.
>>>
>>> Did you need these changes to get it to compile?
>>> http://cr.openjdk.java.net/~coleenp/8004883/src/share/vm/opto/library_call.cpp.udiff.html 
>>>
>>>
>>
>> Yes, thanks!
>
> There is already a bug for that issue being worked on by Christian:
>
> https://jbs.oracle.com/bugs/browse/JDK-8004898
>
> Came in via a separate report on the compiler list
>
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html 
>
>
> David
> -----
>
>> Coleen
>>>
>>> StefanK
>>>
>>> On 12/11/12 11:17 PM, Coleen Phillimore wrote:
>>>> Summary: Add klass_holder() to return either mirror or class_loader
>>>> depending on if the class is anonymous or not.
>>>>
>>>> Add code cleanup requested by John Rose and StefanK.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8004883/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8004883 (just
>>>> filed, might not show up yet).
>>>>
>>>> Ran nashorn tests again.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>>
>>>
>>


From goetz.lindenmaier at sap.com  Wed Dec 12 08:10:37 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 12 Dec 2012 17:10:37 +0100
Subject: RFR (S): memory handling improvements
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF73EADDE@DEWDFECCR03.wdf.sap.corp>

Hi,

I found two fixes for memory handling in our (SAP) hotspot code and want
to share this with you:
\\hs0131\hs0131.a\sapjvm_dev\d045726\oJ\8\main-hotspot-leaks\webrev-mem\index.html<file:///\\hs0131\hs0131.a\sapjvm_dev\d045726\oJ\8\main-hotspot-leaks\webrev-mem\index.html>

In classLoader.cpp there is a memory leak, easy to be fixed.

In parNewGeneration we allocate the overflow list elements
on an arena. This is faster to allocate and no free is necessary.  It performed
better with our VM than malloc/free.

I propose to change openJDK accordingly.

Best regards,
  Goetz Lindenmaier





From goetz.lindenmaier at sap.com  Wed Dec 12 08:28:08 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 12 Dec 2012 17:28:08 +0100
Subject: FW: RFR (S): memory handling improvements
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>

Hi,


= > Sorry, now I fixed the link to the webrev.

I found two fixes for memory handling in our (SAP) hotspot code and want
to share this with you:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/

In classLoader.cpp there is a memory leak, easy to be fixed.

In parNewGeneration we allocate the overflow list elements
on an arena. This is faster to allocate and no free is necessary.  It performed
better with our VM than malloc/free.

I propose to change openJDK accordingly.

Best regards,
  Goetz Lindenmaier





From vitalyd at gmail.com  Wed Dec 12 08:39:30 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 12 Dec 2012 11:39:30 -0500
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <CAHjP37EF3zPr6Of7McPejndfbKbQAF8M_Ar-2ncbaNmKjY=ZBw@mail.gmail.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CAHjP37EF3zPr6Of7McPejndfbKbQAF8M_Ar-2ncbaNmKjY=ZBw@mail.gmail.com>
Message-ID: <CAHjP37HQhCk-01-XSQjuRzzbgTi+ugb0S_w90ixH3y0uVqGFDQ@mail.gmail.com>

Why is the sys_classpath copied in the first place? Is there a chance it's
modified while this code runs? Otherwise I don't see a reason for it, but I
probably missed something.

Thanks

Sent from my phone
On Dec 12, 2012 11:30 AM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
wrote:

Hi,


= > Sorry, now I fixed the link to the webrev.

I found two fixes for memory handling in our (SAP) hotspot code and want
to share this with you:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/

In classLoader.cpp there is a memory leak, easy to be fixed.

In parNewGeneration we allocate the overflow list elements
on an arena. This is faster to allocate and no free is necessary.  It
performed
better with our VM than malloc/free.

I propose to change openJDK accordingly.

Best regards,
  Goetz Lindenmaier

From ysr1729 at gmail.com  Wed Dec 12 09:57:20 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Wed, 12 Dec 2012 09:57:20 -0800
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
Message-ID: <CABzyjym-dwPp7uW74eo83YeGXb8WuP_bbianG1AJc58Zioih2w@mail.gmail.com>

Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and get
rid of the global linked list
code? I was surprised to find that it's off by default. Have you tested
your code with +/- ParGCUseLocalOverflow
to see how much of a difference it makes (with and without yr change to use
a resource allocated field
to link the overflow objects?) It seems as though if ParGCUseLocalOverflow
performs better, which i think it
will, we should just use that and get rid of the more complicated code
(memory is cheap, maintaining complicated
code is expensive, especially if that complicated code is also slow!)

Both your changes look good otherwise (i.e. from a correctness point of
view).

thanks!
-- ramki




On Wed, Dec 12, 2012 at 8:28 AM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi,
>
>
> = > Sorry, now I fixed the link to the webrev.
>
> I found two fixes for memory handling in our (SAP) hotspot code and want
> to share this with you:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/
>
> In classLoader.cpp there is a memory leak, easy to be fixed.
>
> In parNewGeneration we allocate the overflow list elements
> on an arena. This is faster to allocate and no free is necessary.  It
> performed
> better with our VM than malloc/free.
>
> I propose to change openJDK accordingly.
>
> Best regards,
>   Goetz Lindenmaier
>
>
>
>
>

From ysr1729 at gmail.com  Wed Dec 12 10:20:14 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Wed, 12 Dec 2012 10:20:14 -0800
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <CABzyjym-dwPp7uW74eo83YeGXb8WuP_bbianG1AJc58Zioih2w@mail.gmail.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CABzyjym-dwPp7uW74eo83YeGXb8WuP_bbianG1AJc58Zioih2w@mail.gmail.com>
Message-ID: <CABzyjykqzSTxtAmejRJPstDkUs3hGcgBk3zFPCAdaO7Y3X1XRA@mail.gmail.com>

Hi Goetz,

You might want to test with -XX:+ParGCWorkQueueOverflowALot (turned into a
product flag) to artificially induce
overflow and exercise this code with sufficient frequency to get a
reasonable number of data points to do a
perf comparison.

I'll also try and run some figures at this end because I have been doing
some perf numbers related to
promotion failure handling at this end, and this has a cross-section of
interaction with that code.

thanks!
-- ramki

On Wed, Dec 12, 2012 at 9:57 AM, Srinivas Ramakrishna <ysr1729 at gmail.com>wrote:

> Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and
> get rid of the global linked list
> code? I was surprised to find that it's off by default. Have you tested
> your code with +/- ParGCUseLocalOverflow
> to see how much of a difference it makes (with and without yr change to
> use a resource allocated field
> to link the overflow objects?) It seems as though if ParGCUseLocalOverflow
> performs better, which i think it
> will, we should just use that and get rid of the more complicated code
> (memory is cheap, maintaining complicated
> code is expensive, especially if that complicated code is also slow!)
>
> Both your changes look good otherwise (i.e. from a correctness point of
> view).
>
> thanks!
> -- ramki
>
>
>
>
>
> On Wed, Dec 12, 2012 at 8:28 AM, Lindenmaier, Goetz <
> goetz.lindenmaier at sap.com> wrote:
>
>> Hi,
>>
>>
>> = > Sorry, now I fixed the link to the webrev.
>>
>> I found two fixes for memory handling in our (SAP) hotspot code and want
>> to share this with you:
>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/
>>
>> In classLoader.cpp there is a memory leak, easy to be fixed.
>>
>> In parNewGeneration we allocate the overflow list elements
>> on an arena. This is faster to allocate and no free is necessary.  It
>> performed
>> better with our VM than malloc/free.
>>
>> I propose to change openJDK accordingly.
>>
>> Best regards,
>>   Goetz Lindenmaier
>>
>>
>>
>>
>>
>

From john.r.rose at oracle.com  Wed Dec 12 12:00:57 2012
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 12 Dec 2012 12:00:57 -0800
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <50C89DE9.6080308@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
	<50C72FEE.5060203@oracle.com>
	<A0906C96-DF5A-4C8A-8B02-D54ED88BE4BF@oracle.com>
	<50C89DE9.6080308@oracle.com>
Message-ID: <C95DA1FC-5CC8-43EC-848E-8F35CA5A36CC@oracle.com>

On Dec 12, 2012, at 7:08 AM, Aleksey Shipilev wrote:

> he updated version is here:
>  http://shipilev.net/pub/jdk/hotspot/contended/webrev-8/
> 
> Testing:
>  - built and tested on Linux x86_64
>  - Test8003985 passes on Linux x86_64
>  - JPRT is acting corky today, will try to submit a job later
> 
> Meanwhile, please take a look at the code.

It's good.  Ship it!

? John

P.S. Your test is the fifth jtreg test to use the hack of grabbing the private field Unsafe.theUnsafe.  If there is an alternative to that, we should use it.  In particular, if jtreg allows test classes to be loaded on the boot class path, then the public method Unsafe.getUnsafe can be used, and that would be much cleaner.


From coleen.phillimore at oracle.com  Wed Dec 12 12:32:53 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 12 Dec 2012 15:32:53 -0500
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <C95DA1FC-5CC8-43EC-848E-8F35CA5A36CC@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
	<50C72FEE.5060203@oracle.com>
	<A0906C96-DF5A-4C8A-8B02-D54ED88BE4BF@oracle.com>
	<50C89DE9.6080308@oracle.com>
	<C95DA1FC-5CC8-43EC-848E-8F35CA5A36CC@oracle.com>
Message-ID: <50C8E9F5.2090904@oracle.com>


Alexey,

Thank you for not increasing field space.   I had an additional 
comment.  Can you make the printing code from 4116-4142 be a function 
call?   The function parseClassFile is now 1190 lines long, but you 
don't want to make it worse if you don't have to. This badly needs 
refactoring in the future.   This function does too much.

Thanks,
Coleen

On 12/12/2012 3:00 PM, John Rose wrote:
> On Dec 12, 2012, at 7:08 AM, Aleksey Shipilev wrote:
>
>> he updated version is here:
>>   http://shipilev.net/pub/jdk/hotspot/contended/webrev-8/
>>
>> Testing:
>>   - built and tested on Linux x86_64
>>   - Test8003985 passes on Linux x86_64
>>   - JPRT is acting corky today, will try to submit a job later
>>
>> Meanwhile, please take a look at the code.
> It's good.  Ship it!
>
> ? John
>
> P.S. Your test is the fifth jtreg test to use the hack of grabbing the private field Unsafe.theUnsafe.  If there is an alternative to that, we should use it.  In particular, if jtreg allows test classes to be loaded on the boot class path, then the public method Unsafe.getUnsafe can be used, and that would be much cleaner.
>


From david.holmes at oracle.com  Wed Dec 12 17:44:12 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 11:44:12 +1000
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C882FF.2000006@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com>
Message-ID: <50C932EC.9010106@oracle.com>

Hi Erik,

On 12/12/2012 11:13 PM, Erik Helin wrote:
> On 12/12/2012 11:50 AM, David Holmes wrote:
>>> class A {
>>> private:
>>> void operator delete(void *) { }
>>> };
>>>
>>> class B : public A {
>>> public:
>>> B() { }
>>> virtual ~B() { }
>>> };
>>>
>>> > g++ -c foo.cpp
>>> foo.cpp: In destructor ?virtual B::~B()?:
>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>> foo.cpp:9:18: error: within this context
>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>> foo.cpp:9:18: error: within this context
>>> foo.cpp: In destructor ?virtual B::~B()?:
>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>> foo.cpp:9:18: error: within this context
>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>> foo.cpp:9:18: error: within this context
>>
>> Okay that kind of makes sense. I was thinking more about them being in
>> the same class.
>>
>> But this just says to me "don't make new/delete private". (Think of them
>> like virtual methods on Object - you can redefine them but they are
>> always public ;-) )
>
> I believe that the benefit of making new/delete private is that we get
> compile time checking instead of maybe finding out via tests in JPRT (if
> the tests does not traverse a code path with incorrect usage, then we
> won't find it).

Agreed - but that is at odds with the use of the virtual destructor ... 
I also have to wonder why that wasn't done in the first place as it 
seems an "obvious" way to ensure they don't get called.

> In my opinion, if a class has a virtual destructor and inherits from
> _ValueObj or StackObj, then either the destructor shouldn't be virtual
> or the class should not inherit from _ValueObj or StackObj.

I don't think these have to be mutually exclusive in a general sense. 
But it may be we don't need both capabilities in the current cases.

> As far as I can see, the only use for a _virtual_ destructor in a class
> is if you want to delete a pointer to that class (and make sure that the
> destructor of any class inheriting from that class also gets called).

Yes. If at any time you are likely to invoke delete on a derived class 
instance through a base class pointer then you want there to be a 
virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd 
edition Section 17.5.5) is that any base class with any virtual 
functions should also have a virtual destructor.

I've had to fix a number of bugs in certain variants of hotspot caused 
by lack of a virtual destructor. And I doubt that the current codebase 
is particularly "clean" in this regard.

>  From what I understand, deriving from _ValueObj or StackObj means that
> you don't expect this to happen.
>
> What do you think of this?

I'm not versed enough in the use of all the different types that derive 
from ValueObj and StackObj to answer that definitively. It seems likely 
to be true to me - particularly for StackObj. But can we say it is never 
needed?

Given these classes must derive from one of the allocation types, the 
only option is to remove the virtual from the destructor, so at a 
minimum you have to establish for these types that a virtual destructor 
will never be needed.

Cheers,
David
-----


> Thanks for taking your time,
> Erik
>
>> David
>>
>>> Thanks,
>>> Erik
>>>
>>>> Cheers,
>>>> David
>>>>
>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>> Hi all,
>>>>>
>>>>> the webrev is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>
>>>>> Summary:
>>>>> When I browsed the code during a code review, I noticed the macro
>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>>>> used to describe that all instances of a given C++ class can never be
>>>>> placed on (or removed from) the heap with the operations new or
>>>>> delete.
>>>>>
>>>>> This is enforced by the class _ValueObj which implements the operators
>>>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>>>
>>>>> The operators new and delete in _ValueObj are declared public
>>>>> and this change instead declares them as private. This has the effect
>>>>> of enforcing the above described restrictions at compile time.
>>>>>
>>>>> The following three classes inherited from _ValueObj even though they
>>>>> made use of either the new or delete operator:
>>>>> - RegMask:
>>>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>>>> void RegMask &Node::out_regMask() const {
>>>>> ShouldNotCallThis();
>>>>> return *(new RegMask());
>>>>> }
>>>>> Both out_regMask and in_regMask are overridden by subclasses and they
>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>> object is allocated with new. There are two solutions to this problem:
>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
>>>>> RegMask
>>>>> This CR presents a work around to the problem instead of removing
>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>
>>>>> - MemBaseLine
>>>>> MemBaseLine has a virtual destructor which is not possible together
>>>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>>>> can be removed, but I chose to make the destructor non-virtual since
>>>>> no class currently inherits from MemBaseline.
>>>>>
>>>>> - AbstractGangTask
>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>> defines a virtual destructor in C++ must also have a (working) delete
>>>>> operator in scope. The current delete operator is not working (it only
>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>
>>>>> How could this work before? I haven't checked that thoroughly, but I
>>>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>
>>>>> This change also changes the new and delete operations of "StackObj"
>>>>> to be private (for the same reasons). This did not cause changes in
>>>>> any
>>>>> other code.
>>>>>
>>>>> Testing:
>>>>> JPRT
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>
>

From david.holmes at oracle.com  Wed Dec 12 18:48:06 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 12:48:06 +1000
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <CAHjP37HQhCk-01-XSQjuRzzbgTi+ugb0S_w90ixH3y0uVqGFDQ@mail.gmail.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CAHjP37EF3zPr6Of7McPejndfbKbQAF8M_Ar-2ncbaNmKjY=ZBw@mail.gmail.com>
	<CAHjP37HQhCk-01-XSQjuRzzbgTi+ugb0S_w90ixH3y0uVqGFDQ@mail.gmail.com>
Message-ID: <50C941E6.8060908@oracle.com>

On 13/12/2012 2:39 AM, Vitaly Davidovich wrote:
> Why is the sys_classpath copied in the first place? Is there a chance it's
> modified while this code runs? Otherwise I don't see a reason for it, but I
> probably missed something.

That was my immediate reaction too - why the strdup? :) I don't see a 
reason for it either.

I can't comment on the GC code.

David
------

> Thanks
>
> Sent from my phone
> On Dec 12, 2012 11:30 AM, "Lindenmaier, Goetz"<goetz.lindenmaier at sap.com>
> wrote:
>
> Hi,
>
>
> =>  Sorry, now I fixed the link to the webrev.
>
> I found two fixes for memory handling in our (SAP) hotspot code and want
> to share this with you:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/
>
> In classLoader.cpp there is a memory leak, easy to be fixed.
>
> In parNewGeneration we allocate the overflow list elements
> on an arena. This is faster to allocate and no free is necessary.  It
> performed
> better with our VM than malloc/free.
>
> I propose to change openJDK accordingly.
>
> Best regards,
>    Goetz Lindenmaier

From coleen.phillimore at oracle.com  Wed Dec 12 19:15:13 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 12 Dec 2012 22:15:13 -0500
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C932EC.9010106@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
Message-ID: <50C94841.9090100@oracle.com>


Erik,
I think this looks reasonable, although someone from GC should comment 
on the AbstractGangTask's real allocation type.
Thanks,
Coleen

On 12/12/2012 8:44 PM, David Holmes wrote:
> Hi Erik,
>
> On 12/12/2012 11:13 PM, Erik Helin wrote:
>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>> class A {
>>>> private:
>>>> void operator delete(void *) { }
>>>> };
>>>>
>>>> class B : public A {
>>>> public:
>>>> B() { }
>>>> virtual ~B() { }
>>>> };
>>>>
>>>> > g++ -c foo.cpp
>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is 
>>>> private
>>>> foo.cpp:9:18: error: within this context
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is 
>>>> private
>>>> foo.cpp:9:18: error: within this context
>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is 
>>>> private
>>>> foo.cpp:9:18: error: within this context
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is 
>>>> private
>>>> foo.cpp:9:18: error: within this context
>>>
>>> Okay that kind of makes sense. I was thinking more about them being in
>>> the same class.
>>>
>>> But this just says to me "don't make new/delete private". (Think of 
>>> them
>>> like virtual methods on Object - you can redefine them but they are
>>> always public ;-) )
>>
>> I believe that the benefit of making new/delete private is that we get
>> compile time checking instead of maybe finding out via tests in JPRT (if
>> the tests does not traverse a code path with incorrect usage, then we
>> won't find it).
>
> Agreed - but that is at odds with the use of the virtual destructor 
> ... I also have to wonder why that wasn't done in the first place as 
> it seems an "obvious" way to ensure they don't get called.
>
>> In my opinion, if a class has a virtual destructor and inherits from
>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>> or the class should not inherit from _ValueObj or StackObj.
>
> I don't think these have to be mutually exclusive in a general sense. 
> But it may be we don't need both capabilities in the current cases.
>
>> As far as I can see, the only use for a _virtual_ destructor in a class
>> is if you want to delete a pointer to that class (and make sure that the
>> destructor of any class inheriting from that class also gets called).
>
> Yes. If at any time you are likely to invoke delete on a derived class 
> instance through a base class pointer then you want there to be a 
> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd 
> edition Section 17.5.5) is that any base class with any virtual 
> functions should also have a virtual destructor.
>
> I've had to fix a number of bugs in certain variants of hotspot caused 
> by lack of a virtual destructor. And I doubt that the current codebase 
> is particularly "clean" in this regard.
>
>>  From what I understand, deriving from _ValueObj or StackObj means that
>> you don't expect this to happen.
>>
>> What do you think of this?
>
> I'm not versed enough in the use of all the different types that 
> derive from ValueObj and StackObj to answer that definitively. It 
> seems likely to be true to me - particularly for StackObj. But can we 
> say it is never needed?
>
> Given these classes must derive from one of the allocation types, the 
> only option is to remove the virtual from the destructor, so at a 
> minimum you have to establish for these types that a virtual 
> destructor will never be needed.
>
> Cheers,
> David
> -----
>
>
>> Thanks for taking your time,
>> Erik
>>
>>> David
>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> the webrev is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>
>>>>>> Summary:
>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>>>>> used to describe that all instances of a given C++ class can 
>>>>>> never be
>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>> delete.
>>>>>>
>>>>>> This is enforced by the class _ValueObj which implements the 
>>>>>> operators
>>>>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>>>>
>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>> and this change instead declares them as private. This has the 
>>>>>> effect
>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>
>>>>>> The following three classes inherited from _ValueObj even though 
>>>>>> they
>>>>>> made use of either the new or delete operator:
>>>>>> - RegMask:
>>>>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>>>>> void RegMask &Node::out_regMask() const {
>>>>>> ShouldNotCallThis();
>>>>>> return *(new RegMask());
>>>>>> }
>>>>>> Both out_regMask and in_regMask are overridden by subclasses and 
>>>>>> they
>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>> object is allocated with new. There are two solutions to this 
>>>>>> problem:
>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC 
>>>>>> for
>>>>>> RegMask
>>>>>> This CR presents a work around to the problem instead of removing
>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>
>>>>>> - MemBaseLine
>>>>>> MemBaseLine has a virtual destructor which is not possible together
>>>>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>>>>> can be removed, but I chose to make the destructor non-virtual since
>>>>>> no class currently inherits from MemBaseline.
>>>>>>
>>>>>> - AbstractGangTask
>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>> defines a virtual destructor in C++ must also have a (working) 
>>>>>> delete
>>>>>> operator in scope. The current delete operator is not working (it 
>>>>>> only
>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>
>>>>>> How could this work before? I haven't checked that thoroughly, but I
>>>>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>
>>>>>> This change also changes the new and delete operations of "StackObj"
>>>>>> to be private (for the same reasons). This did not cause changes in
>>>>>> any
>>>>>> other code.
>>>>>>
>>>>>> Testing:
>>>>>> JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>
>>


From david.holmes at oracle.com  Wed Dec 12 20:51:15 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 14:51:15 +1000
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C932EC.9010106@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
Message-ID: <50C95EC3.3090803@oracle.com>

Erik,

Sorry, I've confused myself on a key detail here. I said:

"you have to establish for these types that a virtual destructor will 
never be needed."

but I also said:

"If at any time you are likely to invoke delete on a derived class 
instance through a base class pointer then you want there to be a 
virtual destructor."

But given that operator delete can NOT be called on these classes you 
can NOT need a virtual destructor. QED. Hence the correct fixes for 
MemBaseline and AbstractGangtask (and subclasses) would be to remove the 
"virtual" from the destructor.

Thanks,
David

On 13/12/2012 11:44 AM, David Holmes wrote:
> Hi Erik,
>
> On 12/12/2012 11:13 PM, Erik Helin wrote:
>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>> class A {
>>>> private:
>>>> void operator delete(void *) { }
>>>> };
>>>>
>>>> class B : public A {
>>>> public:
>>>> B() { }
>>>> virtual ~B() { }
>>>> };
>>>>
>>>> > g++ -c foo.cpp
>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>>> foo.cpp:9:18: error: within this context
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>>> foo.cpp:9:18: error: within this context
>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>>> foo.cpp:9:18: error: within this context
>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is private
>>>> foo.cpp:9:18: error: within this context
>>>
>>> Okay that kind of makes sense. I was thinking more about them being in
>>> the same class.
>>>
>>> But this just says to me "don't make new/delete private". (Think of them
>>> like virtual methods on Object - you can redefine them but they are
>>> always public ;-) )
>>
>> I believe that the benefit of making new/delete private is that we get
>> compile time checking instead of maybe finding out via tests in JPRT (if
>> the tests does not traverse a code path with incorrect usage, then we
>> won't find it).
>
> Agreed - but that is at odds with the use of the virtual destructor ...
> I also have to wonder why that wasn't done in the first place as it
> seems an "obvious" way to ensure they don't get called.
>
>> In my opinion, if a class has a virtual destructor and inherits from
>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>> or the class should not inherit from _ValueObj or StackObj.
>
> I don't think these have to be mutually exclusive in a general sense.
> But it may be we don't need both capabilities in the current cases.
>
>> As far as I can see, the only use for a _virtual_ destructor in a class
>> is if you want to delete a pointer to that class (and make sure that the
>> destructor of any class inheriting from that class also gets called).
>
> Yes. If at any time you are likely to invoke delete on a derived class
> instance through a base class pointer then you want there to be a
> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
> edition Section 17.5.5) is that any base class with any virtual
> functions should also have a virtual destructor.
>
> I've had to fix a number of bugs in certain variants of hotspot caused
> by lack of a virtual destructor. And I doubt that the current codebase
> is particularly "clean" in this regard.
>
>> From what I understand, deriving from _ValueObj or StackObj means that
>> you don't expect this to happen.
>>
>> What do you think of this?
>
> I'm not versed enough in the use of all the different types that derive
> from ValueObj and StackObj to answer that definitively. It seems likely
> to be true to me - particularly for StackObj. But can we say it is never
> needed?
>
> Given these classes must derive from one of the allocation types, the
> only option is to remove the virtual from the destructor, so at a
> minimum you have to establish for these types that a virtual destructor
> will never be needed.
>
> Cheers,
> David
> -----
>
>
>> Thanks for taking your time,
>> Erik
>>
>>> David
>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> the webrev is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>
>>>>>> Summary:
>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>>>>> used to describe that all instances of a given C++ class can never be
>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>> delete.
>>>>>>
>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>> operators
>>>>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>>>>
>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>> and this change instead declares them as private. This has the effect
>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>
>>>>>> The following three classes inherited from _ValueObj even though they
>>>>>> made use of either the new or delete operator:
>>>>>> - RegMask:
>>>>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>>>>> void RegMask &Node::out_regMask() const {
>>>>>> ShouldNotCallThis();
>>>>>> return *(new RegMask());
>>>>>> }
>>>>>> Both out_regMask and in_regMask are overridden by subclasses and they
>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>> object is allocated with new. There are two solutions to this
>>>>>> problem:
>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC for
>>>>>> RegMask
>>>>>> This CR presents a work around to the problem instead of removing
>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>
>>>>>> - MemBaseLine
>>>>>> MemBaseLine has a virtual destructor which is not possible together
>>>>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>>>>> can be removed, but I chose to make the destructor non-virtual since
>>>>>> no class currently inherits from MemBaseline.
>>>>>>
>>>>>> - AbstractGangTask
>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>> defines a virtual destructor in C++ must also have a (working) delete
>>>>>> operator in scope. The current delete operator is not working (it
>>>>>> only
>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>
>>>>>> How could this work before? I haven't checked that thoroughly, but I
>>>>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>
>>>>>> This change also changes the new and delete operations of "StackObj"
>>>>>> to be private (for the same reasons). This did not cause changes in
>>>>>> any
>>>>>> other code.
>>>>>>
>>>>>> Testing:
>>>>>> JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>
>>

From stefan.karlsson at oracle.com  Thu Dec 13 00:16:37 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 13 Dec 2012 09:16:37 +0100
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
Message-ID: <50C98EE5.9060403@oracle.com>

http://cr.openjdk.java.net/~stefank/8005002/webrev.00/

This is a fix for a crash seen the nightly comp testing in the test:
vm/mlvm/indy/stress/gc/lotsOfCallSites

We have a raw oop while calling out to an allocation function that might 
block for GC. If a GC enters, it might move the Object but will not 
update the oop. Make sure that we wrap the oop in a handle before 
calling the allocation function.

StefanK

From erik.helin at oracle.com  Thu Dec 13 00:53:16 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 13 Dec 2012 09:53:16 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C95EC3.3090803@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
	<50C95EC3.3090803@oracle.com>
Message-ID: <50C9977C.8010002@oracle.com>

David,

On 12/13/2012 05:51 AM, David Holmes wrote:
> Erik,
>
> Sorry, I've confused myself on a key detail here. I said:
>
> "you have to establish for these types that a virtual destructor will
> never be needed."
>
> but I also said:
>
> "If at any time you are likely to invoke delete on a derived class
> instance through a base class pointer then you want there to be a
> virtual destructor."
>
> But given that operator delete can NOT be called on these classes you
> can NOT need a virtual destructor. QED. Hence the correct fixes for
> MemBaseline and AbstractGangtask (and subclasses) would be to remove the
> "virtual" from the destructor.

I agree with you. I've uploaded a new webrev at:

http://cr.openjdk.java.net/~ehelin/8004845/webrev.01/

This webrev keeps VALUE_OBJ_CLASS_SPEC and instead makes the destructor 
for the classes AbstractGangTask and YieldingFlexibleGangTask 
non-virtual. The reason for making the destructor of 
YieldingFlexibleGanskTask non-virtual is because it inherits from 
AbstractGangTask.

What do you think of the change now?

Thanks,
Erik

> Thanks,
> David
>
> On 13/12/2012 11:44 AM, David Holmes wrote:
>> Hi Erik,
>>
>> On 12/12/2012 11:13 PM, Erik Helin wrote:
>>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>>> class A {
>>>>> private:
>>>>> void operator delete(void *) { }
>>>>> };
>>>>>
>>>>> class B : public A {
>>>>> public:
>>>>> B() { }
>>>>> virtual ~B() { }
>>>>> };
>>>>>
>>>>> > g++ -c foo.cpp
>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>
>>>> Okay that kind of makes sense. I was thinking more about them being in
>>>> the same class.
>>>>
>>>> But this just says to me "don't make new/delete private". (Think of
>>>> them
>>>> like virtual methods on Object - you can redefine them but they are
>>>> always public ;-) )
>>>
>>> I believe that the benefit of making new/delete private is that we get
>>> compile time checking instead of maybe finding out via tests in JPRT (if
>>> the tests does not traverse a code path with incorrect usage, then we
>>> won't find it).
>>
>> Agreed - but that is at odds with the use of the virtual destructor ...
>> I also have to wonder why that wasn't done in the first place as it
>> seems an "obvious" way to ensure they don't get called.
>>
>>> In my opinion, if a class has a virtual destructor and inherits from
>>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>>> or the class should not inherit from _ValueObj or StackObj.
>>
>> I don't think these have to be mutually exclusive in a general sense.
>> But it may be we don't need both capabilities in the current cases.
>>
>>> As far as I can see, the only use for a _virtual_ destructor in a class
>>> is if you want to delete a pointer to that class (and make sure that the
>>> destructor of any class inheriting from that class also gets called).
>>
>> Yes. If at any time you are likely to invoke delete on a derived class
>> instance through a base class pointer then you want there to be a
>> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
>> edition Section 17.5.5) is that any base class with any virtual
>> functions should also have a virtual destructor.
>>
>> I've had to fix a number of bugs in certain variants of hotspot caused
>> by lack of a virtual destructor. And I doubt that the current codebase
>> is particularly "clean" in this regard.
>>
>>> From what I understand, deriving from _ValueObj or StackObj means that
>>> you don't expect this to happen.
>>>
>>> What do you think of this?
>>
>> I'm not versed enough in the use of all the different types that derive
>> from ValueObj and StackObj to answer that definitively. It seems likely
>> to be true to me - particularly for StackObj. But can we say it is never
>> needed?
>>
>> Given these classes must derive from one of the allocation types, the
>> only option is to remove the virtual from the destructor, so at a
>> minimum you have to establish for these types that a virtual destructor
>> will never be needed.
>>
>> Cheers,
>> David
>> -----
>>
>>
>>> Thanks for taking your time,
>>> Erik
>>>
>>>> David
>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> the webrev is located at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>>
>>>>>>> Summary:
>>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>>>>>> used to describe that all instances of a given C++ class can
>>>>>>> never be
>>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>>> delete.
>>>>>>>
>>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>>> operators
>>>>>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>>>>>
>>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>>> and this change instead declares them as private. This has the
>>>>>>> effect
>>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>>
>>>>>>> The following three classes inherited from _ValueObj even though
>>>>>>> they
>>>>>>> made use of either the new or delete operator:
>>>>>>> - RegMask:
>>>>>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>>>>>> void RegMask &Node::out_regMask() const {
>>>>>>> ShouldNotCallThis();
>>>>>>> return *(new RegMask());
>>>>>>> }
>>>>>>> Both out_regMask and in_regMask are overridden by subclasses and
>>>>>>> they
>>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>>> object is allocated with new. There are two solutions to this
>>>>>>> problem:
>>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC
>>>>>>> for
>>>>>>> RegMask
>>>>>>> This CR presents a work around to the problem instead of removing
>>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>>
>>>>>>> - MemBaseLine
>>>>>>> MemBaseLine has a virtual destructor which is not possible together
>>>>>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>>>>>> can be removed, but I chose to make the destructor non-virtual since
>>>>>>> no class currently inherits from MemBaseline.
>>>>>>>
>>>>>>> - AbstractGangTask
>>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>>> defines a virtual destructor in C++ must also have a (working)
>>>>>>> delete
>>>>>>> operator in scope. The current delete operator is not working (it
>>>>>>> only
>>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>>
>>>>>>> How could this work before? I haven't checked that thoroughly, but I
>>>>>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>>
>>>>>>> This change also changes the new and delete operations of "StackObj"
>>>>>>> to be private (for the same reasons). This did not cause changes in
>>>>>>> any
>>>>>>> other code.
>>>>>>>
>>>>>>> Testing:
>>>>>>> JPRT
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>
>>>


From goetz.lindenmaier at sap.com  Thu Dec 13 01:20:27 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 13 Dec 2012 10:20:27 +0100
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <50C941E6.8060908@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CAHjP37EF3zPr6Of7McPejndfbKbQAF8M_Ar-2ncbaNmKjY=ZBw@mail.gmail.com>
	<CAHjP37HQhCk-01-XSQjuRzzbgTi+ugb0S_w90ixH3y0uVqGFDQ@mail.gmail.com>
	<50C941E6.8060908@oracle.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF73EB42D@DEWDFECCR03.wdf.sap.corp>

Hi,

I don't see either why strdup is needed.

But basically my intent was to share the fix of the memory leak, 
not to improve legacy code.  But if that results in an improvement, 
I'm happy.

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Donnerstag, 13. Dezember 2012 03:48
To: Vitaly Davidovich
Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
Subject: Re: FW: RFR (S): memory handling improvements

On 13/12/2012 2:39 AM, Vitaly Davidovich wrote:
> Why is the sys_classpath copied in the first place? Is there a chance it's
> modified while this code runs? Otherwise I don't see a reason for it, but I
> probably missed something.

That was my immediate reaction too - why the strdup? :) I don't see a 
reason for it either.

I can't comment on the GC code.

David
------

> Thanks
>
> Sent from my phone
> On Dec 12, 2012 11:30 AM, "Lindenmaier, Goetz"<goetz.lindenmaier at sap.com>
> wrote:
>
> Hi,
>
>
> =>  Sorry, now I fixed the link to the webrev.
>
> I found two fixes for memory handling in our (SAP) hotspot code and want
> to share this with you:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/
>
> In classLoader.cpp there is a memory leak, easy to be fixed.
>
> In parNewGeneration we allocate the overflow list elements
> on an arena. This is faster to allocate and no free is necessary.  It
> performed
> better with our VM than malloc/free.
>
> I propose to change openJDK accordingly.
>
> Best regards,
>    Goetz Lindenmaier

From goetz.lindenmaier at sap.com  Thu Dec 13 01:25:48 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 13 Dec 2012 10:25:48 +0100
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <CABzyjykqzSTxtAmejRJPstDkUs3hGcgBk3zFPCAdaO7Y3X1XRA@mail.gmail.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CABzyjym-dwPp7uW74eo83YeGXb8WuP_bbianG1AJc58Zioih2w@mail.gmail.com>
	<CABzyjykqzSTxtAmejRJPstDkUs3hGcgBk3zFPCAdaO7Y3X1XRA@mail.gmail.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF73EB447@DEWDFECCR03.wdf.sap.corp>

Hi ramki,

I'm not doing the GC stuff at SAP, so I can not change the GC settings in
our VM.  I just can tell you that we run productive with this change
for several years now.  And we decided to do the arena allocation for
performance reasons.

Best regards,
  Goetz.

From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com]
Sent: Mittwoch, 12. Dezember 2012 19:20
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net
Subject: Re: FW: RFR (S): memory handling improvements

Hi Goetz,

You might want to test with -XX:+ParGCWorkQueueOverflowALot (turned into a product flag) to artificially induce
overflow and exercise this code with sufficient frequency to get a reasonable number of data points to do a
perf comparison.

I'll also try and run some figures at this end because I have been doing some perf numbers related to
promotion failure handling at this end, and this has a cross-section of interaction with that code.

thanks!
-- ramki
On Wed, Dec 12, 2012 at 9:57 AM, Srinivas Ramakrishna <ysr1729 at gmail.com<mailto:ysr1729 at gmail.com>> wrote:
Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and get rid of the global linked list
code? I was surprised to find that it's off by default. Have you tested your code with +/- ParGCUseLocalOverflow
to see how much of a difference it makes (with and without yr change to use a resource allocated field
to link the overflow objects?) It seems as though if ParGCUseLocalOverflow performs better, which i think it
will, we should just use that and get rid of the more complicated code (memory is cheap, maintaining complicated
code is expensive, especially if that complicated code is also slow!)

Both your changes look good otherwise (i.e. from a correctness point of view).

thanks!
-- ramki




On Wed, Dec 12, 2012 at 8:28 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:
Hi,


= > Sorry, now I fixed the link to the webrev.

I found two fixes for memory handling in our (SAP) hotspot code and want
to share this with you:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/<http://cr.openjdk.java.net/%7Egoetz/webrevs/webrev-mem/>

In classLoader.cpp there is a memory leak, easy to be fixed.

In parNewGeneration we allocate the overflow list elements
on an arena. This is faster to allocate and no free is necessary.  It performed
better with our VM than malloc/free.

I propose to change openJDK accordingly.

Best regards,
  Goetz Lindenmaier






From david.holmes at oracle.com  Thu Dec 13 02:28:12 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 20:28:12 +1000
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C98EE5.9060403@oracle.com>
References: <50C98EE5.9060403@oracle.com>
Message-ID: <50C9ADBC.3090101@oracle.com>

Hi Stefan,

On 13/12/2012 6:16 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>
> This is a fix for a crash seen the nightly comp testing in the test:
> vm/mlvm/indy/stress/gc/lotsOfCallSites
>
> We have a raw oop while calling out to an allocation function that might
> block for GC. If a GC enters, it might move the Object but will not
> update the oop. Make sure that we wrap the oop in a handle before
> calling the allocation function.

Looks good to me.

I guess CHECK_UNHANDLED_OOPS never got this one :(

Thanks,
David

> StefanK

From david.holmes at oracle.com  Thu Dec 13 02:30:56 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 20:30:56 +1000
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C9977C.8010002@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
	<50C95EC3.3090803@oracle.com> <50C9977C.8010002@oracle.com>
Message-ID: <50C9AE60.9000905@oracle.com>

On 13/12/2012 6:53 PM, Erik Helin wrote:
> David,
>
> On 12/13/2012 05:51 AM, David Holmes wrote:
>> Erik,
>>
>> Sorry, I've confused myself on a key detail here. I said:
>>
>> "you have to establish for these types that a virtual destructor will
>> never be needed."
>>
>> but I also said:
>>
>> "If at any time you are likely to invoke delete on a derived class
>> instance through a base class pointer then you want there to be a
>> virtual destructor."
>>
>> But given that operator delete can NOT be called on these classes you
>> can NOT need a virtual destructor. QED. Hence the correct fixes for
>> MemBaseline and AbstractGangtask (and subclasses) would be to remove the
>> "virtual" from the destructor.
>
> I agree with you. I've uploaded a new webrev at:
>
> http://cr.openjdk.java.net/~ehelin/8004845/webrev.01/
>
> This webrev keeps VALUE_OBJ_CLASS_SPEC and instead makes the destructor
> for the classes AbstractGangTask and YieldingFlexibleGangTask
> non-virtual. The reason for making the destructor of
> YieldingFlexibleGanskTask non-virtual is because it inherits from
> AbstractGangTask.
>
> What do you think of the change now?

Looks fine to me. The empty destructors for the GangTasks seems 
superfluous anyway.

Sorry for the confusion.

David
-----


> Thanks,
> Erik
>
>> Thanks,
>> David
>>
>> On 13/12/2012 11:44 AM, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 12/12/2012 11:13 PM, Erik Helin wrote:
>>>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>>>> class A {
>>>>>> private:
>>>>>> void operator delete(void *) { }
>>>>>> };
>>>>>>
>>>>>> class B : public A {
>>>>>> public:
>>>>>> B() { }
>>>>>> virtual ~B() { }
>>>>>> };
>>>>>>
>>>>>> > g++ -c foo.cpp
>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>
>>>>> Okay that kind of makes sense. I was thinking more about them being in
>>>>> the same class.
>>>>>
>>>>> But this just says to me "don't make new/delete private". (Think of
>>>>> them
>>>>> like virtual methods on Object - you can redefine them but they are
>>>>> always public ;-) )
>>>>
>>>> I believe that the benefit of making new/delete private is that we get
>>>> compile time checking instead of maybe finding out via tests in JPRT
>>>> (if
>>>> the tests does not traverse a code path with incorrect usage, then we
>>>> won't find it).
>>>
>>> Agreed - but that is at odds with the use of the virtual destructor ...
>>> I also have to wonder why that wasn't done in the first place as it
>>> seems an "obvious" way to ensure they don't get called.
>>>
>>>> In my opinion, if a class has a virtual destructor and inherits from
>>>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>>>> or the class should not inherit from _ValueObj or StackObj.
>>>
>>> I don't think these have to be mutually exclusive in a general sense.
>>> But it may be we don't need both capabilities in the current cases.
>>>
>>>> As far as I can see, the only use for a _virtual_ destructor in a class
>>>> is if you want to delete a pointer to that class (and make sure that
>>>> the
>>>> destructor of any class inheriting from that class also gets called).
>>>
>>> Yes. If at any time you are likely to invoke delete on a derived class
>>> instance through a base class pointer then you want there to be a
>>> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
>>> edition Section 17.5.5) is that any base class with any virtual
>>> functions should also have a virtual destructor.
>>>
>>> I've had to fix a number of bugs in certain variants of hotspot caused
>>> by lack of a virtual destructor. And I doubt that the current codebase
>>> is particularly "clean" in this regard.
>>>
>>>> From what I understand, deriving from _ValueObj or StackObj means that
>>>> you don't expect this to happen.
>>>>
>>>> What do you think of this?
>>>
>>> I'm not versed enough in the use of all the different types that derive
>>> from ValueObj and StackObj to answer that definitively. It seems likely
>>> to be true to me - particularly for StackObj. But can we say it is never
>>> needed?
>>>
>>> Given these classes must derive from one of the allocation types, the
>>> only option is to remove the virtual from the destructor, so at a
>>> minimum you have to establish for these types that a virtual destructor
>>> will never be needed.
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>
>>>> Thanks for taking your time,
>>>> Erik
>>>>
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> the webrev is located at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj"
>>>>>>>> and is
>>>>>>>> used to describe that all instances of a given C++ class can
>>>>>>>> never be
>>>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>>>> delete.
>>>>>>>>
>>>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>>>> operators
>>>>>>>> new and delete by calling ShouldNotCallThis which will crash the
>>>>>>>> VM.
>>>>>>>>
>>>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>>>> and this change instead declares them as private. This has the
>>>>>>>> effect
>>>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>>>
>>>>>>>> The following three classes inherited from _ValueObj even though
>>>>>>>> they
>>>>>>>> made use of either the new or delete operator:
>>>>>>>> - RegMask:
>>>>>>>> The functions Node::out_regMask and Node::in_regMask are defined
>>>>>>>> as:
>>>>>>>> void RegMask &Node::out_regMask() const {
>>>>>>>> ShouldNotCallThis();
>>>>>>>> return *(new RegMask());
>>>>>>>> }
>>>>>>>> Both out_regMask and in_regMask are overridden by subclasses and
>>>>>>>> they
>>>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>>>> object is allocated with new. There are two solutions to this
>>>>>>>> problem:
>>>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC
>>>>>>>> for
>>>>>>>> RegMask
>>>>>>>> This CR presents a work around to the problem instead of removing
>>>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>>>
>>>>>>>> - MemBaseLine
>>>>>>>> MemBaseLine has a virtual destructor which is not possible together
>>>>>>>> with a private delete operator. Once again, the
>>>>>>>> VALUE_OBJ_CLASS_SPEC
>>>>>>>> can be removed, but I chose to make the destructor non-virtual
>>>>>>>> since
>>>>>>>> no class currently inherits from MemBaseline.
>>>>>>>>
>>>>>>>> - AbstractGangTask
>>>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>>>> defines a virtual destructor in C++ must also have a (working)
>>>>>>>> delete
>>>>>>>> operator in scope. The current delete operator is not working (it
>>>>>>>> only
>>>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>>>
>>>>>>>> How could this work before? I haven't checked that thoroughly,
>>>>>>>> but I
>>>>>>>> believe that no code calls delete on an AbstractGangTask
>>>>>>>> pointer. If
>>>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>>>
>>>>>>>> This change also changes the new and delete operations of
>>>>>>>> "StackObj"
>>>>>>>> to be private (for the same reasons). This did not cause changes in
>>>>>>>> any
>>>>>>>> other code.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> JPRT
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Erik
>>>>>>
>>>>
>

From stefan.karlsson at oracle.com  Thu Dec 13 02:32:52 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 13 Dec 2012 11:32:52 +0100
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C9ADBC.3090101@oracle.com>
References: <50C98EE5.9060403@oracle.com> <50C9ADBC.3090101@oracle.com>
Message-ID: <50C9AED4.2050208@oracle.com>

On 12/13/12 11:28 AM, David Holmes wrote:
> Hi Stefan,
>
> On 13/12/2012 6:16 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>>
>> This is a fix for a crash seen the nightly comp testing in the test:
>> vm/mlvm/indy/stress/gc/lotsOfCallSites
>>
>> We have a raw oop while calling out to an allocation function that might
>> block for GC. If a GC enters, it might move the Object but will not
>> update the oop. Make sure that we wrap the oop in a handle before
>> calling the allocation function.
>
> Looks good to me.
>
> I guess CHECK_UNHANDLED_OOPS never got this one :(

Are we using CHECK_UNHANDLED_OOPS in our regular nightly testing or JPRT?

This code path is normally not executed, since most dependencies between 
class loaders are handled by the java.lang.ClassLoader.parent chain. 
However, running OSGi or jsr292 tests seem to exercise this code path.

thanks,
SefanK
>
> Thanks,
> David
>
>> StefanK


From erik.helin at oracle.com  Thu Dec 13 02:39:51 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 13 Dec 2012 11:39:51 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C9AE60.9000905@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
	<50C95EC3.3090803@oracle.com> <50C9977C.8010002@oracle.com>
	<50C9AE60.9000905@oracle.com>
Message-ID: <50C9B077.9000304@oracle.com>

Thanks for taking your time and reviewing this change!

Erik

On 12/13/2012 11:30 AM, David Holmes wrote:
> On 13/12/2012 6:53 PM, Erik Helin wrote:
>> David,
>>
>> On 12/13/2012 05:51 AM, David Holmes wrote:
>>> Erik,
>>>
>>> Sorry, I've confused myself on a key detail here. I said:
>>>
>>> "you have to establish for these types that a virtual destructor will
>>> never be needed."
>>>
>>> but I also said:
>>>
>>> "If at any time you are likely to invoke delete on a derived class
>>> instance through a base class pointer then you want there to be a
>>> virtual destructor."
>>>
>>> But given that operator delete can NOT be called on these classes you
>>> can NOT need a virtual destructor. QED. Hence the correct fixes for
>>> MemBaseline and AbstractGangtask (and subclasses) would be to remove the
>>> "virtual" from the destructor.
>>
>> I agree with you. I've uploaded a new webrev at:
>>
>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.01/
>>
>> This webrev keeps VALUE_OBJ_CLASS_SPEC and instead makes the destructor
>> for the classes AbstractGangTask and YieldingFlexibleGangTask
>> non-virtual. The reason for making the destructor of
>> YieldingFlexibleGanskTask non-virtual is because it inherits from
>> AbstractGangTask.
>>
>> What do you think of the change now?
>
> Looks fine to me. The empty destructors for the GangTasks seems
> superfluous anyway.
>
> Sorry for the confusion.
>
> David
> -----
>
>
>> Thanks,
>> Erik
>>
>>> Thanks,
>>> David
>>>
>>> On 13/12/2012 11:44 AM, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>> On 12/12/2012 11:13 PM, Erik Helin wrote:
>>>>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>>>>> class A {
>>>>>>> private:
>>>>>>> void operator delete(void *) { }
>>>>>>> };
>>>>>>>
>>>>>>> class B : public A {
>>>>>>> public:
>>>>>>> B() { }
>>>>>>> virtual ~B() { }
>>>>>>> };
>>>>>>>
>>>>>>> > g++ -c foo.cpp
>>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>
>>>>>> Okay that kind of makes sense. I was thinking more about them
>>>>>> being in
>>>>>> the same class.
>>>>>>
>>>>>> But this just says to me "don't make new/delete private". (Think of
>>>>>> them
>>>>>> like virtual methods on Object - you can redefine them but they are
>>>>>> always public ;-) )
>>>>>
>>>>> I believe that the benefit of making new/delete private is that we get
>>>>> compile time checking instead of maybe finding out via tests in JPRT
>>>>> (if
>>>>> the tests does not traverse a code path with incorrect usage, then we
>>>>> won't find it).
>>>>
>>>> Agreed - but that is at odds with the use of the virtual destructor ...
>>>> I also have to wonder why that wasn't done in the first place as it
>>>> seems an "obvious" way to ensure they don't get called.
>>>>
>>>>> In my opinion, if a class has a virtual destructor and inherits from
>>>>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>>>>> or the class should not inherit from _ValueObj or StackObj.
>>>>
>>>> I don't think these have to be mutually exclusive in a general sense.
>>>> But it may be we don't need both capabilities in the current cases.
>>>>
>>>>> As far as I can see, the only use for a _virtual_ destructor in a
>>>>> class
>>>>> is if you want to delete a pointer to that class (and make sure that
>>>>> the
>>>>> destructor of any class inheriting from that class also gets called).
>>>>
>>>> Yes. If at any time you are likely to invoke delete on a derived class
>>>> instance through a base class pointer then you want there to be a
>>>> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
>>>> edition Section 17.5.5) is that any base class with any virtual
>>>> functions should also have a virtual destructor.
>>>>
>>>> I've had to fix a number of bugs in certain variants of hotspot caused
>>>> by lack of a virtual destructor. And I doubt that the current codebase
>>>> is particularly "clean" in this regard.
>>>>
>>>>> From what I understand, deriving from _ValueObj or StackObj means that
>>>>> you don't expect this to happen.
>>>>>
>>>>> What do you think of this?
>>>>
>>>> I'm not versed enough in the use of all the different types that derive
>>>> from ValueObj and StackObj to answer that definitively. It seems likely
>>>> to be true to me - particularly for StackObj. But can we say it is
>>>> never
>>>> needed?
>>>>
>>>> Given these classes must derive from one of the allocation types, the
>>>> only option is to remove the virtual from the destructor, so at a
>>>> minimum you have to establish for these types that a virtual destructor
>>>> will never be needed.
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>
>>>>> Thanks for taking your time,
>>>>> Erik
>>>>>
>>>>>> David
>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> the webrev is located at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj"
>>>>>>>>> and is
>>>>>>>>> used to describe that all instances of a given C++ class can
>>>>>>>>> never be
>>>>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>>>>> delete.
>>>>>>>>>
>>>>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>>>>> operators
>>>>>>>>> new and delete by calling ShouldNotCallThis which will crash the
>>>>>>>>> VM.
>>>>>>>>>
>>>>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>>>>> and this change instead declares them as private. This has the
>>>>>>>>> effect
>>>>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>>>>
>>>>>>>>> The following three classes inherited from _ValueObj even though
>>>>>>>>> they
>>>>>>>>> made use of either the new or delete operator:
>>>>>>>>> - RegMask:
>>>>>>>>> The functions Node::out_regMask and Node::in_regMask are defined
>>>>>>>>> as:
>>>>>>>>> void RegMask &Node::out_regMask() const {
>>>>>>>>> ShouldNotCallThis();
>>>>>>>>> return *(new RegMask());
>>>>>>>>> }
>>>>>>>>> Both out_regMask and in_regMask are overridden by subclasses and
>>>>>>>>> they
>>>>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>>>>> object is allocated with new. There are two solutions to this
>>>>>>>>> problem:
>>>>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC
>>>>>>>>> for
>>>>>>>>> RegMask
>>>>>>>>> This CR presents a work around to the problem instead of removing
>>>>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>>>>
>>>>>>>>> - MemBaseLine
>>>>>>>>> MemBaseLine has a virtual destructor which is not possible
>>>>>>>>> together
>>>>>>>>> with a private delete operator. Once again, the
>>>>>>>>> VALUE_OBJ_CLASS_SPEC
>>>>>>>>> can be removed, but I chose to make the destructor non-virtual
>>>>>>>>> since
>>>>>>>>> no class currently inherits from MemBaseline.
>>>>>>>>>
>>>>>>>>> - AbstractGangTask
>>>>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>>>>> defines a virtual destructor in C++ must also have a (working)
>>>>>>>>> delete
>>>>>>>>> operator in scope. The current delete operator is not working (it
>>>>>>>>> only
>>>>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>>>>
>>>>>>>>> How could this work before? I haven't checked that thoroughly,
>>>>>>>>> but I
>>>>>>>>> believe that no code calls delete on an AbstractGangTask
>>>>>>>>> pointer. If
>>>>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>>>>
>>>>>>>>> This change also changes the new and delete operations of
>>>>>>>>> "StackObj"
>>>>>>>>> to be private (for the same reasons). This did not cause
>>>>>>>>> changes in
>>>>>>>>> any
>>>>>>>>> other code.
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> JPRT
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Erik
>>>>>>>
>>>>>
>>


From david.holmes at oracle.com  Thu Dec 13 02:47:48 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 20:47:48 +1000
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C9AED4.2050208@oracle.com>
References: <50C98EE5.9060403@oracle.com> <50C9ADBC.3090101@oracle.com>
	<50C9AED4.2050208@oracle.com>
Message-ID: <50C9B254.6090203@oracle.com>

On 13/12/2012 8:32 PM, Stefan Karlsson wrote:
> On 12/13/12 11:28 AM, David Holmes wrote:
>> Hi Stefan,
>>
>> On 13/12/2012 6:16 PM, Stefan Karlsson wrote:
>>> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>>>
>>> This is a fix for a crash seen the nightly comp testing in the test:
>>> vm/mlvm/indy/stress/gc/lotsOfCallSites
>>>
>>> We have a raw oop while calling out to an allocation function that might
>>> block for GC. If a GC enters, it might move the Object but will not
>>> update the oop. Make sure that we wrap the oop in a handle before
>>> calling the allocation function.
>>
>> Looks good to me.
>>
>> I guess CHECK_UNHANDLED_OOPS never got this one :(
>
> Are we using CHECK_UNHANDLED_OOPS in our regular nightly testing or JPRT?

I thought we were but ...

> This code path is normally not executed, since most dependencies between
> class loaders are handled by the java.lang.ClassLoader.parent chain.
> However, running OSGi or jsr292 tests seem to exercise this code path.

I don't know if it covers these specific tests.

David
-----

> thanks,
> SefanK
>>
>> Thanks,
>> David
>>
>>> StefanK
>

From david.holmes at oracle.com  Thu Dec 13 03:23:26 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Dec 2012 21:23:26 +1000
Subject: Profiles update to jdk8-b67
In-Reply-To: <50BEDADE.40301@oracle.com>
References: <50BC0678.1040300@oracle.com> <50BEDADE.40301@oracle.com>
Message-ID: <50C9BAAE.5030309@oracle.com>

Just FYI the Profiles forest has been updated to the jdk8-b67 level.

This version includes the initial set of java.util.function APIs from 
lambda.

It also restricts profiles builds to linux.

David

From serguei.spitsyn at oracle.com  Thu Dec 13 04:30:11 2012
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 13 Dec 2012 04:30:11 -0800
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C98EE5.9060403@oracle.com>
References: <50C98EE5.9060403@oracle.com>
Message-ID: <50C9CA53.4040809@oracle.com>

The fix is good.

Thanks,
Serguei

On 12/13/12 12:16 AM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>
> This is a fix for a crash seen the nightly comp testing in the test:
> vm/mlvm/indy/stress/gc/lotsOfCallSites
>
> We have a raw oop while calling out to an allocation function that 
> might block for GC. If a GC enters, it might move the Object but will 
> not update the oop. Make sure that we wrap the oop in a handle before 
> calling the allocation function.
>
> StefanK


From stefan.karlsson at oracle.com  Thu Dec 13 04:38:58 2012
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 13 Dec 2012 13:38:58 +0100
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C9CA53.4040809@oracle.com>
References: <50C98EE5.9060403@oracle.com> <50C9CA53.4040809@oracle.com>
Message-ID: <50C9CC62.3070304@oracle.com>

Thanks,
StefanK

On 12/13/12 1:30 PM, serguei.spitsyn at oracle.com wrote:
> The fix is good.
>
> Thanks,
> Serguei
>
> On 12/13/12 12:16 AM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>>
>> This is a fix for a crash seen the nightly comp testing in the test:
>> vm/mlvm/indy/stress/gc/lotsOfCallSites
>>
>> We have a raw oop while calling out to an allocation function that 
>> might block for GC. If a GC enters, it might move the Object but will 
>> not update the oop. Make sure that we wrap the oop in a handle before 
>> calling the allocation function.
>>
>> StefanK
>


From coleen.phillimore at oracle.com  Thu Dec 13 06:12:00 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 13 Dec 2012 09:12:00 -0500
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C98EE5.9060403@oracle.com>
References: <50C98EE5.9060403@oracle.com>
Message-ID: <50C9E230.1030009@oracle.com>


Looks good.
Thanks,
Coleen

On 12/13/2012 3:16 AM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>
> This is a fix for a crash seen the nightly comp testing in the test:
> vm/mlvm/indy/stress/gc/lotsOfCallSites
>
> We have a raw oop while calling out to an allocation function that 
> might block for GC. If a GC enters, it might move the Object but will 
> not update the oop. Make sure that we wrap the oop in a handle before 
> calling the allocation function.
>
> StefanK


From coleen.phillimore at oracle.com  Thu Dec 13 06:14:42 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 13 Dec 2012 09:14:42 -0500
Subject: Review request (S): 8005002: Crash because of a raw oop in
	ClassLoaderData::add_dependency
In-Reply-To: <50C9ADBC.3090101@oracle.com>
References: <50C98EE5.9060403@oracle.com> <50C9ADBC.3090101@oracle.com>
Message-ID: <50C9E2D2.9000507@oracle.com>

On 12/13/2012 5:28 AM, David Holmes wrote:
> Hi Stefan,
>
> On 13/12/2012 6:16 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>>
>> This is a fix for a crash seen the nightly comp testing in the test:
>> vm/mlvm/indy/stress/gc/lotsOfCallSites
>>
>> We have a raw oop while calling out to an allocation function that might
>> block for GC. If a GC enters, it might move the Object but will not
>> update the oop. Make sure that we wrap the oop in a handle before
>> calling the allocation function.
>
> Looks good to me.
>
> I guess CHECK_UNHANDLED_OOPS never got this one :(

Since CHECK_UNHANDLED_OOPs only works on solaris (the operator 
overloading turned out too hard to get to compile on linux), nobody 
probably ran it.   This option needs an overhaul.  I filed a bug on it.

Coleen

>
> Thanks,
> David
>
>> StefanK


From ysr1729 at gmail.com  Thu Dec 13 10:29:19 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 13 Dec 2012 10:29:19 -0800
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF73EB447@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CABzyjym-dwPp7uW74eo83YeGXb8WuP_bbianG1AJc58Zioih2w@mail.gmail.com>
	<CABzyjykqzSTxtAmejRJPstDkUs3hGcgBk3zFPCAdaO7Y3X1XRA@mail.gmail.com>
	<140FA3E3585AD840A3316D2853F974DC1BF73EB447@DEWDFECCR03.wdf.sap.corp>
Message-ID: <CABzyjy=UJ435agQVnOqoYNaQ=HrcZtOkRfu6Wajf-7Go-MmCBQ@mail.gmail.com>

OK, as I noted, your change looks fine to me. Thanks for sharing.

I'll do the perf runs that I suggested, at my end, and if the numbers bear
out my suspicion,
will file a CR and patch to get rid of that code (subject to performance
verification etc. by the
HotSpot performance team).

thanks.
-- ramki

On Thu, Dec 13, 2012 at 1:25 AM, Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi ramki,****
>
> ** **
>
> I?m not doing the GC stuff at SAP, so I can not change the GC settings in
> ****
>
> our VM.  I just can tell you that we run productive with this change****
>
> for several years now.  And we decided to do the arena allocation for****
>
> performance reasons.****
>
> ** **
>
> Best regards,****
>
>   Goetz.****
>
> ** **
>
> *From:* Srinivas Ramakrishna [mailto:ysr1729 at gmail.com]
> *Sent:* Mittwoch, 12. Dezember 2012 19:20
> *To:* Lindenmaier, Goetz
> *Cc:* hotspot-dev at openjdk.java.net
>
> *Subject:* Re: FW: RFR (S): memory handling improvements****
>
> ** **
>
> Hi Goetz,
>
>
> You might want to test with -XX:+ParGCWorkQueueOverflowALot (turned into a
> product flag) to artificially induce
> overflow and exercise this code with sufficient frequency to get a
> reasonable number of data points to do a
> perf comparison.
>
> I'll also try and run some figures at this end because I have been doing
> some perf numbers related to
> promotion failure handling at this end, and this has a cross-section of
> interaction with that code.
>
> thanks!
> -- ramki****
>
> On Wed, Dec 12, 2012 at 9:57 AM, Srinivas Ramakrishna <ysr1729 at gmail.com>
> wrote:****
>
> Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and
> get rid of the global linked list
> code? I was surprised to find that it's off by default. Have you tested
> your code with +/- ParGCUseLocalOverflow
> to see how much of a difference it makes (with and without yr change to
> use a resource allocated field
> to link the overflow objects?) It seems as though if ParGCUseLocalOverflow
> performs better, which i think it
> will, we should just use that and get rid of the more complicated code
> (memory is cheap, maintaining complicated
> code is expensive, especially if that complicated code is also slow!)
>
> Both your changes look good otherwise (i.e. from a correctness point of
> view).
>
> thanks!
> -- ramki****
>
>
>
>
>
> ****
>
> On Wed, Dec 12, 2012 at 8:28 AM, Lindenmaier, Goetz <
> goetz.lindenmaier at sap.com> wrote:****
>
> Hi,
>
>
> = > Sorry, now I fixed the link to the webrev.****
>
>
> I found two fixes for memory handling in our (SAP) hotspot code and want
> to share this with you:****
>
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/****
>
>
> In classLoader.cpp there is a memory leak, easy to be fixed.
>
> In parNewGeneration we allocate the overflow list elements
> on an arena. This is faster to allocate and no free is necessary.  It
> performed
> better with our VM than malloc/free.
>
> I propose to change openJDK accordingly.
>
> Best regards,
>   Goetz Lindenmaier
>
>
>
> ****
>
> ** **
>
> ** **
>

From christian.thalinger at oracle.com  Thu Dec 13 12:41:18 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 13 Dec 2012 12:41:18 -0800
Subject: RFR: Some build fixes for gcc4.7
In-Reply-To: <1355300366.1747.169.camel@mercury>
References: <1354825441.1747.22.camel@mercury> <50C12CE3.2050907@oracle.com>
	<1354897725.1747.75.camel@mercury> <50C7AB57.9040709@oracle.com>
	<1355263212.1747.154.camel@mercury>
	<50C7B0E6.6000602@oracle.com> <50C7E843.9020006@oracle.com>
	<1355300366.1747.169.camel@mercury>
Message-ID: <A4E817C4-CDFA-4BE9-B8DE-9AB03A91F9C7@oracle.com>


On Dec 12, 2012, at 12:19 AM, Roman Kennke <rkennke at redhat.com> wrote:

> Hi David,
> 
>> From my perspective, there are the following proposed changes not
> committed yet:
> 
> 1.
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007294.html
> 
>> From that one, only the jdk part is missing:
> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/
> 
> I think it's the only one with a bug-id even:
> 8003868: fix shark for latest HotSpot and LLVM
> 
> 2. Then there is the library_call build fixes. (Which have also been
> proposed by Yasumasa Suenaga, which now got the bug id 8004898 and
> Christian is working on it.)
> 
> Then I posted a bunch of others on hotspot-compiler-dev (maybe
> hotspot-dev would have been better?)
> 
> 3. Fix OSR in Shark for non-empty incoming stack
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009087.html
> 
> This one got a little review by David Chase, for which I will send an
> updated webrev soon. I was hoping to get some more feedback though, or
> even a bug-id.
> 
> 4. Implement deoptimization support in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009088.html
> 
> This one did not get any feedback yet, no bug-id either.
> 
> 5. Fix volatile float field access in Shark 
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009089.html
> 
> Same, no feedback, no bug-id.
> 
> 6. Enable JSR292 support in Shark
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html
> 
> Got some positive feedback from John Rose, but no bug id and no
> progress.
> 
> Please let me know if I should do anything different in the future
> (different mailing list, different format, ..) Also, if it helps, I can
> group all those changes into one big change, I just thought that it is
> easier to review in logical chunks (otherwise the changes would
> interleave and it's difficult to say what belongs to what).

Currently we have some problems with JPRT so I waiting for that to be resolved.  But I will take care of all the above.

-- Chris

> 
> 
> Thanks for your cooperation!
> 
> Best regards,
> Roman
> 
> 
>> I think the library_call issue is the only thing that still needs 
>> working on.
>> 
>> David
>> 
>> On 12/12/2012 8:17 AM, Coleen Phillimore wrote:
>>> 
>>> On 12/11/2012 05:00 PM, Roman Kennke wrote:
>>>> Am Dienstag, den 11.12.2012, 16:53 -0500 schrieb Coleen Phillimore:
>>>>> Now I hit this library_call.cpp compilation error. Has it been pushed
>>>>> yet? I was going to piggyback this with another cleanup that I was
>>>>> making if not.
>>>> No, it has not been pushed yet. :-(
>>>> 
>>>> Seems like all my patches have become stuck in the queue. Is there
>>>> anything that I can do to make them move forward? Should I file them in
>>>> openjdk bugzilla?
>>> 
>>> What you are doing is the right way to submit patches. We don't really
>>> monitor openjdk bugzilla. I think people are working on your other patches.
>>> 
>>> thanks,
>>> Coleen
>>> 
>>>> 
>>>> Regards,
>>>> Roman
>>>> 
>>>>> thanks,
>>>>> Coleen
>>>>> 
>>>>> On 12/07/2012 11:28 AM, Roman Kennke wrote:
>>>>>> Am Donnerstag, den 06.12.2012, 18:40 -0500 schrieb Coleen Phillimore:
>>>>>>> The changes to binaryTreeDictionary.cpp are already in the hotspot-gc
>>>>>>> repository and will/have been pushed up to main already. They should
>>>>>>> already be in hotspot-comp.
>>>>>> Ah great, good to see, thanks! :-)
>>>>>> 
>>>>>>> Which compiler complains about the library_call.cpp changes? I have an
>>>>>>> unstable ubuntu 12.10 system in order to run with gcc 4.7.2 and this
>>>>>>> file compiles fine for me as is.
>>>>>> This happens on Fedora, gcc 4.7.2. Fedora tends to incorporate
>>>>>> improvements from dev versions sometimes... I agree with David, it
>>>>>> would
>>>>>> be good to fix in any case.
>>>>>> 
>>>>>> Thanks,
>>>>>> Roman
>>>>>> 
>>>>>> 
>>>> 
>>> 
> 
> 


From paul.nauman at oracle.com  Thu Dec 13 16:26:15 2012
From: paul.nauman at oracle.com (Paul Nauman)
Date: Thu, 13 Dec 2012 16:26:15 -0800
Subject: RFR (XS) 8004713: Stackoverflowerror thrown when thread stack
	straddles 0x80000000
In-Reply-To: <50CA65D8.2050105@oracle.com>
References: <50CA65D8.2050105@oracle.com>
Message-ID: <50CA7227.6090608@oracle.com>

SPARC template interpreter uses signed comparison when checking for 
stack overflow while pushing a stack frame larger than the page size. In 
32 bit VM that can cause unnecessary StackOverflowErrors. Fix is to use 
unsigned comparison when checking for stack overflow.

http://cr.openjdk.java.net/~kvn/8004713/webrev/

Paul Nauman

From vladimir.kozlov at oracle.com  Thu Dec 13 16:51:19 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 13 Dec 2012 16:51:19 -0800
Subject: RFR (XS) 8004713: Stackoverflowerror thrown when thread stack
	straddles 0x80000000
In-Reply-To: <50CA7227.6090608@oracle.com>
References: <50CA65D8.2050105@oracle.com> <50CA7227.6090608@oracle.com>
Message-ID: <50CA7807.9060106@oracle.com>

Good. I will push it.

Thanks,
Vladimir

On 12/13/12 4:26 PM, Paul Nauman wrote:
> SPARC template interpreter uses signed comparison when checking for
> stack overflow while pushing a stack frame larger than the page size. In
> 32 bit VM that can cause unnecessary StackOverflowErrors. Fix is to use
> unsigned comparison when checking for stack overflow.
>
> http://cr.openjdk.java.net/~kvn/8004713/webrev/
>
> Paul Nauman

From paul.nauman at oracle.com  Thu Dec 13 15:33:44 2012
From: paul.nauman at oracle.com (Paul Nauman)
Date: Thu, 13 Dec 2012 15:33:44 -0800
Subject: RFR (XS) 8004713: Stackoverflowerror thrown when thread stack
	straddles 0x80000000
Message-ID: <50CA65D8.2050105@oracle.com>

SPARC template interpreter uses signed comparison when checking for stack overflow while pushing a stack frame larger than the page size. In 32 bit VM that can cause unnecessary StackOverflowErrors. Fix is to use unsigned comparison when checking for stack overflow.

http://cr.openjdk.java.net/~kvn/8004713/webrev/

Paul Nauman



From alejandro.murillo at oracle.com  Thu Dec 13 20:50:27 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 14 Dec 2012 04:50:27 +0000
Subject: hg: hsx/hsx24/hotspot: 4 new changesets
Message-ID: <20121214045040.B2F9C4713C@hg.openjdk.java.net>

Changeset: 4e4026772caf
Author:    katleman
Date:      2012-12-05 16:04 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4e4026772caf

Added tag jdk7u12-b04 for changeset ed9b424d5e43

! .hgtags

Changeset: 86ac69dabf56
Author:    katleman
Date:      2012-12-12 12:16 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/86ac69dabf56

Added tag jdk7u12-b05 for changeset 4e4026772caf

! .hgtags

Changeset: 364bc54d7096
Author:    amurillo
Date:      2012-12-13 17:59 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/364bc54d7096

Merge


Changeset: 2e497fde1807
Author:    amurillo
Date:      2012-12-13 17:59 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2e497fde1807

Added tag hs24-b27 for changeset 364bc54d7096

! .hgtags


From erik.helin at oracle.com  Thu Dec 13 22:08:51 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 14 Dec 2012 07:08:51 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50C94841.9090100@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
	<50C94841.9090100@oracle.com>
Message-ID: <50CAC273.5030501@oracle.com>

Coleen,

On 12/13/2012 04:15 AM, Coleen Phillimore wrote:
> I think this looks reasonable, although someone from GC should comment
> on the AbstractGangTask's real allocation type.

what do you think of the latest webrev (which keeps the allocation type 
for AbstractGangTask):

http://cr.openjdk.java.net/~ehelin/8004845/webrev.01/

This webrev keeps VALUE_OBJ_CLASS_SPEC and instead makes the destructor 
for the classes AbstractGangTask and YieldingFlexibleGangTask non-virtual.

This was changed because I got some great feedback from David:

On 12/13/2012 05:51 AM, David Holmes wrote:
 > But given that operator delete can NOT be called on these classes you
 > can NOT need a virtual destructor. QED. Hence the correct fixes for
 > MemBaseline and AbstractGangtask (and subclasses) would be to remove the
 > "virtual" from the destructor.

Thanks,
Erik

> Thanks,
> Coleen
>
> On 12/12/2012 8:44 PM, David Holmes wrote:
>> Hi Erik,
>>
>> On 12/12/2012 11:13 PM, Erik Helin wrote:
>>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>>> class A {
>>>>> private:
>>>>> void operator delete(void *) { }
>>>>> };
>>>>>
>>>>> class B : public A {
>>>>> public:
>>>>> B() { }
>>>>> virtual ~B() { }
>>>>> };
>>>>>
>>>>> > g++ -c foo.cpp
>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>> private
>>>>> foo.cpp:9:18: error: within this context
>>>>
>>>> Okay that kind of makes sense. I was thinking more about them being in
>>>> the same class.
>>>>
>>>> But this just says to me "don't make new/delete private". (Think of
>>>> them
>>>> like virtual methods on Object - you can redefine them but they are
>>>> always public ;-) )
>>>
>>> I believe that the benefit of making new/delete private is that we get
>>> compile time checking instead of maybe finding out via tests in JPRT (if
>>> the tests does not traverse a code path with incorrect usage, then we
>>> won't find it).
>>
>> Agreed - but that is at odds with the use of the virtual destructor
>> ... I also have to wonder why that wasn't done in the first place as
>> it seems an "obvious" way to ensure they don't get called.
>>
>>> In my opinion, if a class has a virtual destructor and inherits from
>>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>>> or the class should not inherit from _ValueObj or StackObj.
>>
>> I don't think these have to be mutually exclusive in a general sense.
>> But it may be we don't need both capabilities in the current cases.
>>
>>> As far as I can see, the only use for a _virtual_ destructor in a class
>>> is if you want to delete a pointer to that class (and make sure that the
>>> destructor of any class inheriting from that class also gets called).
>>
>> Yes. If at any time you are likely to invoke delete on a derived class
>> instance through a base class pointer then you want there to be a
>> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
>> edition Section 17.5.5) is that any base class with any virtual
>> functions should also have a virtual destructor.
>>
>> I've had to fix a number of bugs in certain variants of hotspot caused
>> by lack of a virtual destructor. And I doubt that the current codebase
>> is particularly "clean" in this regard.
>>
>>>  From what I understand, deriving from _ValueObj or StackObj means that
>>> you don't expect this to happen.
>>>
>>> What do you think of this?
>>
>> I'm not versed enough in the use of all the different types that
>> derive from ValueObj and StackObj to answer that definitively. It
>> seems likely to be true to me - particularly for StackObj. But can we
>> say it is never needed?
>>
>> Given these classes must derive from one of the allocation types, the
>> only option is to remove the virtual from the destructor, so at a
>> minimum you have to establish for these types that a virtual
>> destructor will never be needed.
>>
>> Cheers,
>> David
>> -----
>>
>>
>>> Thanks for taking your time,
>>> Erik
>>>
>>>> David
>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> the webrev is located at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>>
>>>>>>> Summary:
>>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" and is
>>>>>>> used to describe that all instances of a given C++ class can
>>>>>>> never be
>>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>>> delete.
>>>>>>>
>>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>>> operators
>>>>>>> new and delete by calling ShouldNotCallThis which will crash the VM.
>>>>>>>
>>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>>> and this change instead declares them as private. This has the
>>>>>>> effect
>>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>>
>>>>>>> The following three classes inherited from _ValueObj even though
>>>>>>> they
>>>>>>> made use of either the new or delete operator:
>>>>>>> - RegMask:
>>>>>>> The functions Node::out_regMask and Node::in_regMask are defined as:
>>>>>>> void RegMask &Node::out_regMask() const {
>>>>>>> ShouldNotCallThis();
>>>>>>> return *(new RegMask());
>>>>>>> }
>>>>>>> Both out_regMask and in_regMask are overridden by subclasses and
>>>>>>> they
>>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>>> object is allocated with new. There are two solutions to this
>>>>>>> problem:
>>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC
>>>>>>> for
>>>>>>> RegMask
>>>>>>> This CR presents a work around to the problem instead of removing
>>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>>
>>>>>>> - MemBaseLine
>>>>>>> MemBaseLine has a virtual destructor which is not possible together
>>>>>>> with a private delete operator. Once again, the VALUE_OBJ_CLASS_SPEC
>>>>>>> can be removed, but I chose to make the destructor non-virtual since
>>>>>>> no class currently inherits from MemBaseline.
>>>>>>>
>>>>>>> - AbstractGangTask
>>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>>> defines a virtual destructor in C++ must also have a (working)
>>>>>>> delete
>>>>>>> operator in scope. The current delete operator is not working (it
>>>>>>> only
>>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>>
>>>>>>> How could this work before? I haven't checked that thoroughly, but I
>>>>>>> believe that no code calls delete on an AbstractGangTask pointer. If
>>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>>
>>>>>>> This change also changes the new and delete operations of "StackObj"
>>>>>>> to be private (for the same reasons). This did not cause changes in
>>>>>>> any
>>>>>>> other code.
>>>>>>>
>>>>>>> Testing:
>>>>>>> JPRT
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>
>>>
>


From kirk at kodewerk.com  Thu Dec 13 23:17:59 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 14 Dec 2012 08:17:59 +0100
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <50BCE743.10705@cs.oswego.edu>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
Message-ID: <31D8987F-4713-4FA5-B4E9-CC42D026A5AF@kodewerk.com>

Hi Doug et all...

I've been thinking about these intrinsics/annotations and I've been wondering if it would be worth exploring somehow setting up intrinsics to allow access to the MSRs? With better access to MSR, people might have a better chance of using measures to sort out strange effects due to unfortunately alignments of data in caches.

The source of my objects to these methods is that they can currently only be applied speculatively. As Mike Barker pointed out, he's hacked up access to these registers for Mac's and I and some others have worked up a library for Linux (via the device drivers). But given that all that is really needed is a thin C++ wrapper over a small amount of assembler, it would be so much easier to support this either in the JVMTI or in s.m.u. Down side is that you do need to fix permissions to get this to work and this is all very processor specific and difficult (or practically impossible) to generalize across processors. That said, if the decision has been made to open up access to fencing and padding and other CPU tricks, I'd argue that we need to consider opening up a way to measure the effects.

Regards,
Kirk
On 2012-12-03, at 6:54 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/03/12 12:45, David Chase wrote:
>> Is this the right place to comment on this? I think these should not go in
>> Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.
> 
> They cannot. The methods cannot be spec'ed using only the concepts
> in the JLS/JMM. So they are not "Java methods", but "JVM methods".
> (This is the same rationale for placing @Contended in sun.misc.)
> Someday, a serious effort is needed to enable rigorous specs
> of core intrinsics along these lines (possible even with a
> Java-level JMM memory model overhaul). But I don't think anyone
> wants to hold these methods hostage for years until this happens.
> 
> -Doug
> 
> 
> 


From kirk at kodewerk.com  Thu Dec 13 23:19:12 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 14 Dec 2012 08:19:12 +0100
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
	<9A0D83C5-D8E3-4A49-9F6F-FEE66415855A@oracle.com>
Message-ID: <A7E16DBD-D9B8-4003-83A1-4AB7D2C3508C@kodewerk.com>

How about sun.misc.CPU?

Regards,
Kirk

On 2012-12-03, at 7:25 PM, David Chase <david.r.chase at oracle.com> wrote:

> I'll defer to your judgement on the JMM issues, but from a user (programmer) POV, does this distinction make a difference?  I think their (in)ability to write "portable" code (across style checkers, across class loaders) would be a big deal.
> 
> How about "sun.misc.VM" instead?  Unsafe seems to be booby-trapped against use by non-system classloaders; I don't see how that is necessary here.
> 
> David
> 
> On 2012-12-03, at 12:54 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
>> On 12/03/12 12:45, David Chase wrote:
>>> Is this the right place to comment on this? I think these should not go in
>>> Unsafe; fence intrinsics belong with compareAndSet in j.u.concurrent.atomic.
>> 
>> They cannot. The methods cannot be spec'ed using only the concepts
>> in the JLS/JMM. So they are not "Java methods", but "JVM methods".
>> (This is the same rationale for placing @Contended in sun.misc.)
>> Someday, a serious effort is needed to enable rigorous specs
>> of core intrinsics along these lines (possible even with a
>> Java-level JMM memory model overhaul). But I don't think anyone
>> wants to hold these methods hostage for years until this happens.
>> 
>> -Doug
>> 
>> 
>> 
> 


From goetz.lindenmaier at sap.com  Thu Dec 13 23:35:41 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 14 Dec 2012 08:35:41 +0100
Subject: FW: RFR (S): memory handling improvements
In-Reply-To: <CABzyjy=UJ435agQVnOqoYNaQ=HrcZtOkRfu6Wajf-7Go-MmCBQ@mail.gmail.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF73EAE2F@DEWDFECCR03.wdf.sap.corp>
	<CABzyjym-dwPp7uW74eo83YeGXb8WuP_bbianG1AJc58Zioih2w@mail.gmail.com>
	<CABzyjykqzSTxtAmejRJPstDkUs3hGcgBk3zFPCAdaO7Y3X1XRA@mail.gmail.com>
	<140FA3E3585AD840A3316D2853F974DC1BF73EB447@DEWDFECCR03.wdf.sap.corp>
	<CABzyjy=UJ435agQVnOqoYNaQ=HrcZtOkRfu6Wajf-7Go-MmCBQ@mail.gmail.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF749E561@DEWDFECCR03.wdf.sap.corp>

Hi Ramki,

To come back to your question in your first mail:


?  Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and get rid of the global linked list
code

I talked to my GC collegue.  He says, he would appreciate if Oracle enables
ParGCUseLocalOverflow per default for the same reasons you proposed.
We just use the other code as we keep the settings Oracle uses.

Best regards,
  Goetz.


From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com]
Sent: Donnerstag, 13. Dezember 2012 19:29
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net
Subject: Re: FW: RFR (S): memory handling improvements

OK, as I noted, your change looks fine to me. Thanks for sharing.

I'll do the perf runs that I suggested, at my end, and if the numbers bear out my suspicion,
will file a CR and patch to get rid of that code (subject to performance verification etc. by the
HotSpot performance team).

thanks.
-- ramki
On Thu, Dec 13, 2012 at 1:25 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:
Hi ramki,

I'm not doing the GC stuff at SAP, so I can not change the GC settings in
our VM.  I just can tell you that we run productive with this change
for several years now.  And we decided to do the arena allocation for
performance reasons.

Best regards,
  Goetz.

From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com<mailto:ysr1729 at gmail.com>]
Sent: Mittwoch, 12. Dezember 2012 19:20
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>

Subject: Re: FW: RFR (S): memory handling improvements

Hi Goetz,


You might want to test with -XX:+ParGCWorkQueueOverflowALot (turned into a product flag) to artificially induce
overflow and exercise this code with sufficient frequency to get a reasonable number of data points to do a
perf comparison.

I'll also try and run some figures at this end because I have been doing some perf numbers related to
promotion failure handling at this end, and this has a cross-section of interaction with that code.

thanks!
-- ramki
On Wed, Dec 12, 2012 at 9:57 AM, Srinivas Ramakrishna <ysr1729 at gmail.com<mailto:ysr1729 at gmail.com>> wrote:
Goetz. shouldn't we be using ParGCUseLocalOverflow true by default, and get rid of the global linked list
code? I was surprised to find that it's off by default. Have you tested your code with +/- ParGCUseLocalOverflow
to see how much of a difference it makes (with and without yr change to use a resource allocated field
to link the overflow objects?) It seems as though if ParGCUseLocalOverflow performs better, which i think it
will, we should just use that and get rid of the more complicated code (memory is cheap, maintaining complicated
code is expensive, especially if that complicated code is also slow!)

Both your changes look good otherwise (i.e. from a correctness point of view).

thanks!
-- ramki



On Wed, Dec 12, 2012 at 8:28 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>> wrote:
Hi,


= > Sorry, now I fixed the link to the webrev.

I found two fixes for memory handling in our (SAP) hotspot code and want
to share this with you:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-mem/<http://cr.openjdk.java.net/%7Egoetz/webrevs/webrev-mem/>

In classLoader.cpp there is a memory leak, easy to be fixed.

In parNewGeneration we allocate the overflow list elements
on an arena. This is faster to allocate and no free is necessary.  It performed
better with our VM than malloc/free.

I propose to change openJDK accordingly.

Best regards,
  Goetz Lindenmaier






From alejandro.murillo at oracle.com  Thu Dec 13 23:38:37 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 14 Dec 2012 07:38:37 +0000
Subject: hg: hsx/hsx24/hotspot: 8005035: new hotspot build - hs24-b28
Message-ID: <20121214073841.1CFF647140@hg.openjdk.java.net>

Changeset: e064c40afff6
Author:    amurillo
Date:      2012-12-13 18:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e064c40afff6

8005035: new hotspot build - hs24-b28
Reviewed-by: jcoomes

! make/hotspot_version


From john.coomes at oracle.com  Fri Dec 14 01:31:45 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Dec 2012 09:31:45 +0000
Subject: hg: hsx/hotspot-main: 8 new changesets
Message-ID: <20121214093145.A3B5947143@hg.openjdk.java.net>

Changeset: ab1ab9b148dd
Author:    smarks
Date:      2012-11-28 17:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/ab1ab9b148dd

8004131: move jdi tests out of core testset
Reviewed-by: alanb, chegar

! make/jprt.properties

Changeset: ad54163c95f5
Author:    lana
Date:      2012-11-30 16:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/ad54163c95f5

Merge


Changeset: 04435608c613
Author:    lana
Date:      2012-12-10 20:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/04435608c613

Merge


Changeset: 6b96b7744913
Author:    erikj
Date:      2012-12-07 17:23 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/6b96b7744913

8004045: build-infra: Error 12 from zip when updating src.zip
Summary: Hiding this error from make so that it doesn't fail
Reviewed-by: ohrstrom, dholmes

! common/makefiles/JavaCompilation.gmk

Changeset: 2795874efd16
Author:    erikj
Date:      2012-12-11 11:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/2795874efd16

8003945: build-infra: problems finding compiler when using --with-dev-kit
Summary: Search all compiler names in dev-kit dir first.
Reviewed-by: tbell

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

Changeset: e175ecff1391
Author:    erikj
Date:      2012-12-11 11:33 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/e175ecff1391

8001753: build-infra: mismatch with full debug symbol control for hotspot
Summary: Enabling hotspot to use the FDS settings established at configure time
Reviewed-by: dholmes, ohair

! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/jdk-options.m4
! common/makefiles/NativeCompilation.gmk

Changeset: cdb401a60cea
Author:    katleman
Date:      2012-12-12 13:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/cdb401a60cea

Merge


Changeset: e9ec00893bb4
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/e9ec00893bb4

Added tag jdk8-b68 for changeset cdb401a60cea

! .hgtags


From john.coomes at oracle.com  Fri Dec 14 01:31:51 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Dec 2012 09:31:51 +0000
Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b68 for changeset
	82000531feaa
Message-ID: <20121214093156.0E9F847144@hg.openjdk.java.net>

Changeset: 22ddcac208a8
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/22ddcac208a8

Added tag jdk8-b68 for changeset 82000531feaa

! .hgtags


From john.coomes at oracle.com  Fri Dec 14 01:32:00 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Dec 2012 09:32:00 +0000
Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b68 for changeset
	b854e7008421
Message-ID: <20121214093210.7734B47145@hg.openjdk.java.net>

Changeset: 789a855de959
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/789a855de959

Added tag jdk8-b68 for changeset b854e7008421

! .hgtags


From john.coomes at oracle.com  Fri Dec 14 01:32:15 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Dec 2012 09:32:15 +0000
Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b68 for changeset
	d3fe408f3a9a
Message-ID: <20121214093220.932EE47146@hg.openjdk.java.net>

Changeset: 756323c99011
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/756323c99011

Added tag jdk8-b68 for changeset d3fe408f3a9a

! .hgtags


From john.coomes at oracle.com  Fri Dec 14 01:34:59 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Dec 2012 09:34:59 +0000
Subject: hg: hsx/hotspot-main/jdk: 69 new changesets
Message-ID: <20121214094921.9568A47147@hg.openjdk.java.net>

Changeset: 39f9b2cc5738
Author:    bae
Date:      2012-11-28 12:28 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39f9b2cc5738

4649812: GIFImageReader handles transparency incorrectly
Reviewed-by: bae, prr
Contributed-by: Vadim Pakhnushev <vadim.pakhnushev at oracle.com>

! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java

Changeset: 6569819eb2fe
Author:    bae
Date:      2012-11-28 12:38 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6569819eb2fe

5082749: GIF stream metadata specification of aspect ratio is incorrect
Reviewed-by: bae, prr
Contributed-by: Vadim Pakhnushev <vadim.pakhnushev at oracle.com>

! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html

Changeset: 934595726263
Author:    bae
Date:      2012-11-28 14:12 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/934595726263

7064516: ImageIO.read() fails to load an image
Reviewed-by: jgodinez, prr

! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/image/ColorConvertOp.java
+ test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java

Changeset: d54db1e16b97
Author:    bae
Date:      2012-11-30 11:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d54db1e16b97

7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly
Reviewed-by: jgodinez

! src/share/classes/sun/print/PathGraphics.java

Changeset: bd3b3cda125d
Author:    lana
Date:      2012-11-30 16:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd3b3cda125d

Merge


Changeset: 3c5bf5ed45a9
Author:    bae
Date:      2012-12-03 16:26 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c5bf5ed45a9

7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage
Reviewed-by: prr, flar

! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java
+ test/sun/java2d/OpenGL/CustomCompositeTest.java

Changeset: 1175410d98ea
Author:    serb
Date:      2012-11-21 15:50 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1175410d98ea

7124552: [macosx] NullPointerException in getBufferStrategy()
7124219: [macosx] Unable to draw images to fullscreen
Reviewed-by: bae, anthony

! src/macosx/classes/sun/awt/CGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/lwawt/LWCanvasPeer.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
+ src/macosx/classes/sun/lwawt/LWGraphicsConfig.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/PlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
- src/share/classes/sun/awt/TextureSizeConstraining.java

Changeset: 5b2c31d20a64
Author:    serb
Date:      2012-11-21 15:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b2c31d20a64

7193214: Consider simplifying CPlatformWindow.setResizable()
Reviewed-by: anthony, denis

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: c9dead63607c
Author:    serb
Date:      2012-11-21 15:58 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9dead63607c

7154516: [macosx] Popup menus have no visible borders
Reviewed-by: anthony, denis

! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java

Changeset: 9cd48409539e
Author:    kizune
Date:      2012-11-21 20:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9cd48409539e

8003273: Missing testcase for 7171812
Reviewed-by: art, serb

+ test/javax/swing/dnd/7171812/JListWithScroll.java
+ test/javax/swing/dnd/7171812/bug7171812.java

Changeset: 5600005b87fb
Author:    serb
Date:      2012-11-27 17:03 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5600005b87fb

8002308: [macosx] 7198229 should be applied to the user action only
Reviewed-by: anthony, skovatch

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m
+ test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java

Changeset: 0e91d6f3019c
Author:    alexsch
Date:      2012-11-29 07:42 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e91d6f3019c

8000423: Diacritic is not applyed to a base letter on Linux
Reviewed-by: anthony, serb

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

Changeset: abee1d528df1
Author:    kshefov
Date:      2012-11-30 12:39 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abee1d528df1

7124242: [macosx] Test doesn't work because of the frame round corners in the LaF
Reviewed-by: anthony, yan, alexsch

! test/javax/swing/text/CSSBorder/6796710/bug6796710.java

Changeset: 35d8085aa14a
Author:    lana
Date:      2012-11-30 17:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/35d8085aa14a

Merge


Changeset: da55ef766e48
Author:    alexsch
Date:      2012-12-04 15:26 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da55ef766e48

6671481: NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection
Reviewed-by: serb

! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java

Changeset: bd175c70684c
Author:    alexsch
Date:      2012-12-04 15:56 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd175c70684c

8003830: NPE at BasicTreeUI$Actions.page:4470
Reviewed-by: serb, alexsch
Contributed-by: Jaroslav Tulach <jaroslav.tulach at oracle.com>

! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
+ test/javax/swing/JTree/8003830/bug8003830.java

Changeset: 009fd6e1d9f5
Author:    alexsch
Date:      2012-12-04 16:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/009fd6e1d9f5

8002077: Possible mnemonic issue on JFileChooser Save button on nimbus L&F
Reviewed-by: serb

! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java

Changeset: 4aad3e6f68d2
Author:    jviswana
Date:      2012-12-04 17:17 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4aad3e6f68d2

4631925: JColor Chooser is not fully accessible
Reviewed-by: alexsch

! src/share/classes/javax/swing/JColorChooser.java
! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java
! src/share/classes/javax/swing/colorchooser/ColorPanel.java
! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java

Changeset: ea20c9388d90
Author:    aph
Date:      2012-12-04 14:02 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea20c9388d90

8004344: Fix a crash in ToolkitErrorHandler() in XlibWrapper.c
Summary: Code does not check for JNU_GetEnv returning NULL.
Reviewed-by: anthony

! src/solaris/native/sun/xawt/XlibWrapper.c

Changeset: bbbb5c70aa59
Author:    lana
Date:      2012-12-04 11:41 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bbbb5c70aa59

Merge

- src/share/classes/sun/awt/TextureSizeConstraining.java

Changeset: f389bf27fc4f
Author:    dbuck
Date:      2012-11-20 21:35 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f389bf27fc4f

7198904: (alt-rt) TreeMap.clone is broken
Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well
Reviewed-by: mduigou, dholmes

+ test/java/util/TreeMap/Clone.java

Changeset: ee6e5b7d5d55
Author:    uta
Date:      2012-11-23 13:07 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ee6e5b7d5d55

8003898: X11 toolkit can be chosen as the default toolkit
Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY).
Reviewed-by: anthony, art

! src/solaris/native/java/lang/java_props_macosx.c

Changeset: 621c379d909d
Author:    xuelei
Date:      2012-11-24 03:34 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/621c379d909d

8001751: Javadoc warnings in JSSE code
Reviewed-by: alanb

! src/share/classes/javax/net/ssl/HostnameVerifier.java
! src/share/classes/javax/net/ssl/SNIHostName.java
! src/share/classes/javax/net/ssl/SNIMatcher.java
! src/share/classes/javax/net/ssl/SNIServerName.java
! src/share/classes/javax/net/ssl/SSLParameters.java
! src/share/classes/javax/net/ssl/SSLSocketFactory.java

Changeset: f7d45462b225
Author:    xuelei
Date:      2012-11-24 04:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7d45462b225

8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl
Reviewed-by: xuelei
Contributed-by: Florian Weimer <fweimer at redhat.com>

! src/share/classes/sun/security/ssl/AppInputStream.java
! src/share/classes/sun/security/ssl/AppOutputStream.java
! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
! src/share/classes/sun/security/ssl/ByteBufferInputStream.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/CipherSuiteList.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/DHClientKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHCrypt.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/ExtensionType.java
! src/share/classes/sun/security/ssl/HandshakeHash.java
! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/HelloExtension.java
! src/share/classes/sun/security/ssl/HelloExtensions.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/Krb5Helper.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/ProtocolList.java
! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java
! src/share/classes/sun/security/ssl/RSASignature.java
! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/ServerNameExtension.java
! src/share/classes/sun/security/ssl/SessionId.java
! src/share/classes/sun/security/ssl/SunJSSE.java
! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java
! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java
! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
! src/share/classes/sun/security/ssl/UnknownExtension.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java

Changeset: d30c13172254
Author:    xuelei
Date:      2012-11-24 04:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d30c13172254

8003951: Removes unused variables in sun.security.ssl
Reviewed-by: xuelei
Contributed-by: Florian Weimer <fweimer at redhat.com>

! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java
! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java

Changeset: 8970128e040d
Author:    uta
Date:      2012-11-26 15:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8970128e040d

7162111: TEST_BUG: change tests run in headless mode [macosx] (open)
Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed.
Reviewed-by: alanb

! test/ProblemList.txt
! test/demo/jvmti/mtrace/TraceJFrame.java
! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java
! test/java/io/Serializable/resolveClass/deserializeButton/Test.java
! test/java/io/Serializable/resolveClass/deserializeButton/run.sh

Changeset: 054470092795
Author:    mullan
Date:      2012-11-26 08:12 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/054470092795

7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid
Reviewed-by: weijun, xuelei

! src/share/classes/com/sun/net/ssl/SSLPermission.java
! src/share/classes/java/lang/RuntimePermission.java
! src/share/classes/java/net/NetPermission.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/javax/net/ssl/SSLPermission.java
+ test/java/security/BasicPermission/Wildcard.java

Changeset: ea66140be78d
Author:    mullan
Date:      2012-11-26 08:23 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea66140be78d

Merge

- makefiles/docs/CORE_PKGS.gmk
- makefiles/docs/Makefile
- makefiles/docs/NON_CORE_PKGS.gmk
- makefiles/docs/Notes.html
- makefiles/mapfiles/launchers/mapfile-amd64
- makefiles/mapfiles/launchers/mapfile-i586
- makefiles/mapfiles/libawt_headless/reorder-i586
- makefiles/mapfiles/libjava/reorder-i586
- makefiles/mapfiles/libjpeg/reorder-i586
- makefiles/mapfiles/libnio/mapfile-bsd
- makefiles/mapfiles/libnio/reorder-i586
- makefiles/mapfiles/libverify/reorder-i586
- makefiles/mapfiles/libzip/reorder-i586
- makefiles/sun/xawt/ToBin.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/javax/net/ssl/SSLPermission.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java

Changeset: d7ed56d57d97
Author:    mullan
Date:      2012-11-26 08:34 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d7ed56d57d97

Merge


Changeset: c2e80176a697
Author:    mduigou
Date:      2012-11-26 15:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c2e80176a697

8001634: Initial set of functional interface types
Summary: Add the core functional interfaces used by the JSR335 libraries.
Reviewed-by: dholmes, briangoetz, darcy

! make/docs/CORE_PKGS.gmk
! make/java/java/Makefile
+ src/share/classes/java/util/function/BinaryOperator.java
+ src/share/classes/java/util/function/Block.java
+ src/share/classes/java/util/function/DoubleBinaryOperator.java
+ src/share/classes/java/util/function/DoubleBlock.java
+ src/share/classes/java/util/function/DoubleFunction.java
+ src/share/classes/java/util/function/DoubleSupplier.java
+ src/share/classes/java/util/function/DoubleUnaryOperator.java
+ src/share/classes/java/util/function/Function.java
+ src/share/classes/java/util/function/IntBinaryOperator.java
+ src/share/classes/java/util/function/IntBlock.java
+ src/share/classes/java/util/function/IntFunction.java
+ src/share/classes/java/util/function/IntSupplier.java
+ src/share/classes/java/util/function/IntUnaryOperator.java
+ src/share/classes/java/util/function/LongBinaryOperator.java
+ src/share/classes/java/util/function/LongBlock.java
+ src/share/classes/java/util/function/LongFunction.java
+ src/share/classes/java/util/function/LongSupplier.java
+ src/share/classes/java/util/function/LongUnaryOperator.java
+ src/share/classes/java/util/function/Predicate.java
+ src/share/classes/java/util/function/Supplier.java
+ src/share/classes/java/util/function/UnaryOperator.java
+ src/share/classes/java/util/function/package-info.java

Changeset: ddf97baea570
Author:    chegar
Date:      2012-11-27 17:15 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ddf97baea570

8003833: Spurious NPE from Socket.getIn/OutputStream
Reviewed-by: alanb, dsamersoff

! src/share/classes/java/net/AbstractPlainSocketImpl.java
+ test/java/net/Socket/Streams.java

Changeset: 40311b5f478f
Author:    robm
Date:      2012-11-28 00:47 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40311b5f478f

8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests
Reviewed-by: chegar

+ test/java/net/ResponseCache/Test.java
+ test/java/net/Socket/B6210227.java

Changeset: 39b25d5880c6
Author:    sherman
Date:      2012-11-27 21:51 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39b25d5880c6

4235519: Make sun.misc.BASE64{De,En}coder classes public
Summary: to add java.util.Base64
Reviewed-by: alanb, mduigou

! make/java/java/FILES_java.gmk

Changeset: c6ed2c238d4f
Author:    sherman
Date:      2012-11-27 22:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6ed2c238d4f

8004088: hg push for bug#4235519 failed to push all files
Summary: pushed all base64 files
Reviewed-by: alanb, mduigou

+ src/share/classes/java/util/Base64.java
+ test/java/util/Base64/TestBase64.java
+ test/java/util/Base64/TestBase64Golden.java
+ test/java/util/Base64/baseEncode.txt
+ test/java/util/Base64/mimeEncode.txt
+ test/java/util/Base64/plain.txt
+ test/java/util/Base64/urlEncode.txt

Changeset: 46c627801490
Author:    xuelei
Date:      2012-11-28 05:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/46c627801490

8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg()
Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation
Reviewed-by: xuelei, weijun
Contributed-by: Florian Weimer <fweimer at redhat.com>

! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/HandshakeHash.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java

Changeset: 735b93462eed
Author:    jfranck
Date:      2012-11-28 09:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/735b93462eed

7154390: Add support for repeating annotations in j.l.r.AnnotatedElement
Reviewed-by: darcy

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/annotation/ContainedBy.java
! src/share/classes/java/lang/annotation/ContainerFor.java
+ src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java
! src/share/classes/java/lang/reflect/AccessibleObject.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/sun/misc/JavaLangAccess.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
+ src/share/classes/sun/reflect/annotation/AnnotationSupport.java
! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java
+ test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java
+ test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java

Changeset: 3b6a2fe6d75c
Author:    dfuchs
Date:      2012-11-28 15:14 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b6a2fe6d75c

8003476: Cleanup warnings in com.sun.jmx.snmp code
Reviewed-by: alanb, smarks

! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java
! src/share/classes/com/sun/jmx/snmp/Enumerated.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java
! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java
! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java
! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java
! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java
! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java
! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java
! src/share/classes/sun/management/snmp/AdaptorBootstrap.java

Changeset: 262b3b2f3aa3
Author:    dfuchs
Date:      2012-11-28 10:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/262b3b2f3aa3

Merge


Changeset: 09bef1e118e3
Author:    mchung
Date:      2012-11-28 10:49 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/09bef1e118e3

8003851: MethodHandleNatives dependency on java.sql.DriverManager
Reviewed-by: alanb, dholmes

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

Changeset: 80ddee59a21d
Author:    mchung
Date:      2012-11-28 10:50 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/80ddee59a21d

8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging
Reviewed-by: alanb, dholmes

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

Changeset: 13ec794734f5
Author:    michaelm
Date:      2012-11-29 09:41 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13ec794734f5

7200720: crash in net.dll during NTLM authentication
Reviewed-by: chegar, dsamersoff

! make/java/net/Makefile
! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java
! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c

Changeset: ba5eabd6a37b
Author:    michaelm
Date:      2012-11-29 09:47 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba5eabd6a37b

Merge


Changeset: 2b829a5a46ee
Author:    jgish
Date:      2012-11-29 12:28 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b829a5a46ee

8003380: Compiler warnings in logging test code
Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc.
Reviewed-by: lancea, chegar

! test/java/util/logging/ClassLoaderLeakTest.java
! test/java/util/logging/Listeners.java
! test/java/util/logging/ListenersWithSM.java
! test/java/util/logging/LoggerResourceBundleRace.java
! test/java/util/logging/LoggingDeadlock2.java
! test/java/util/logging/LoggingDeadlock3.java
! test/java/util/logging/LoggingDeadlock4.java
! test/java/util/logging/LoggingMXBeanTest.java
! test/java/util/logging/LoggingMXBeanTest2.java
! test/java/util/logging/MemoryHandlerTest.java
! test/java/util/logging/ParentLoggersTest.java
! test/java/util/logging/SimpleFormatterFormat.java

Changeset: d91e6cb1da41
Author:    shade
Date:      2012-11-29 17:03 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d91e6cb1da41

8004141: UnsafeStaticFieldAccessorImpl#base should be final
Reviewed-by: chegar, alanb
Contributed-by: peter.levart at gmail.com

! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java

Changeset: bf6ceb6b8f80
Author:    mduigou
Date:      2012-11-29 14:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf6ceb6b8f80

7175464: entrySetView field is never updated in NavigableSubMap
Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView.
Reviewed-by: alanb, psandoz

! src/share/classes/java/util/TreeMap.java

Changeset: 75cb07a7b622
Author:    mduigou
Date:      2012-11-29 14:09 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75cb07a7b622

6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation
Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly.
Reviewed-by: alanb

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/String.java

Changeset: 83d9f30ebeed
Author:    smarks
Date:      2012-11-28 17:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/83d9f30ebeed

8004131: move jdi tests out of core testset
Reviewed-by: alanb, chegar

! make/jprt.properties

Changeset: 7ccf93c60c4d
Author:    smarks
Date:      2012-11-29 14:43 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ccf93c60c4d

8004134: More ProblemList.txt updates (11/2012)
Reviewed-by: alanb
Contributed-by: amy.lu at oracle.com

! test/ProblemList.txt

Changeset: 55f8ddc2f9c6
Author:    sla
Date:      2012-11-30 08:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/55f8ddc2f9c6

7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
Reviewed-by: okutsu

! test/java/util/TimeZone/Bug6912560.java

Changeset: e988de7465d4
Author:    zhangshj
Date:      2012-11-30 17:24 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e988de7465d4

8004211: Remove unused dlinfo local variable in launcher code
Reviewed-by: alanb

! src/solaris/bin/java_md_solinux.c

Changeset: 72d3d07b625d
Author:    alanb
Date:      2012-11-30 11:18 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72d3d07b625d

8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties
Reviewed-by: psandoz, mchung

! src/share/classes/java/util/logging/LogManager.java

Changeset: c370048be8fc
Author:    alanb
Date:      2012-11-30 16:29 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c370048be8fc

7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period
Reviewed-by: chegar

! src/share/classes/sun/nio/ch/ThreadPool.java

Changeset: e7edb0da9c6a
Author:    jfranck
Date:      2012-11-30 09:47 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7edb0da9c6a

8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java
Reviewed-by: jjg, darcy

! src/share/classes/sun/reflect/annotation/AnnotationSupport.java

Changeset: 43d2e02c4098
Author:    khazra
Date:      2012-11-30 12:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43d2e02c4098

7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock"
Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests
Reviewed-by: alanb, chegar, weijun, dxu

! test/java/util/prefs/AddNodeChangeListener.java
! test/java/util/prefs/CheckUserPrefsStorage.sh
! test/java/util/prefs/CommentsInXml.java
! test/java/util/prefs/ConflictInFlush.java
! test/java/util/prefs/ExportNode.java
! test/java/util/prefs/ExportSubtree.java
! test/java/util/prefs/PrefsSpi.sh
! test/java/util/prefs/RemoveNullKeyCheck.java
! test/java/util/prefs/RemoveReadOnlyNode.java
! test/java/util/prefs/RemoveUnregedListener.java

Changeset: e66ec5b8c15e
Author:    lana
Date:      2012-11-30 16:33 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e66ec5b8c15e

Merge


Changeset: fd8ba2d8baec
Author:    sherman
Date:      2012-12-01 11:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd8ba2d8baec

8004212: java.util.Base64  methods decodeArray and decodeBuffer should return the number of bytes written
Summary: to return the length instead of position
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: f657adf4fe78
Author:    alanb
Date:      2012-12-02 16:37 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f657adf4fe78

8003846: Override mechanism for currency data should not require creating currency.properties in java.home
Reviewed-by: naoto

! src/share/classes/java/util/Currency.java
! test/java/util/Currency/PropertiesTest.java
! test/java/util/Currency/PropertiesTest.sh

Changeset: 60550cd2b527
Author:    dholmes
Date:      2012-12-02 19:16 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60550cd2b527

7200297: agent code does not handle multiple boot library path elements correctly
Summary: When bug 6819213 was fixed it enabled sun.boot.library.path property to contain multiple paths. Code in agents does not handle multiple paths when attempting to find dependent shared libs.
Reviewed-by: dholmes, sspitsyn, dsamersoff
Contributed-by: Bill Pittore <bill.pittore at oracle.com>

! src/share/back/debugInit.c
! src/share/back/error_messages.c
! src/share/back/transport.c
! src/share/demo/jvmti/hprof/hprof.h
! src/share/demo/jvmti/hprof/hprof_init.c
! src/solaris/back/linker_md.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/solaris/npt/npt_md.h
! src/windows/back/linker_md.c
! src/windows/demo/jvmti/hprof/hprof_md.c
! src/windows/npt/npt_md.h

Changeset: a42da685dfca
Author:    weijun
Date:      2012-12-03 17:14 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a42da685dfca

7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten
Reviewed-by: xuelei

! test/sun/security/tools/keytool/console.sh

Changeset: ead651efb271
Author:    xuelei
Date:      2012-12-03 06:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ead651efb271

8004184: security tests leave JSSEServer running
Summary: Use othervm mode to release resources,  and correct the system properties issues in JSSE
Reviewed-by: chegar

! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java

Changeset: ee9846f351d7
Author:    mullan
Date:      2012-12-03 11:07 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ee9846f351d7

7199143: RFE: OCSP revocation checker should provide possibility to specify connection timeout
Summary: Added com.sun.security.ocsp.timeout system property to control timeout
Reviewed-by: mullan, vinnie
Contributed-by: jason.uh at oracle.com

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

Changeset: 38ec2838dd86
Author:    dxu
Date:      2012-12-04 14:07 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/38ec2838dd86

7142921: (fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04
7144997: (fs) Files.probeContentType returns null on Solaris 64-bit
Reviewed-by: alanb, mduigou

! make/java/nio/Makefile
! make/java/nio/mapfile-linux
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/mapfiles/libnio/mapfile-linux
! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java
+ src/solaris/classes/sun/nio/fs/MagicFileTypeDetector.java
+ src/solaris/classes/sun/nio/fs/MimeTypesFileTypeDetector.java
! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
+ src/solaris/native/sun/nio/fs/MagicFileTypeDetector.c

Changeset: 2e8863c4f7d0
Author:    kmo
Date:      2012-12-04 15:10 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2e8863c4f7d0

8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message
Reviewed-by: twisti, alanb, dholmes

! test/java/lang/Math/DivModTests.java

Changeset: 87028eb3f020
Author:    lana
Date:      2012-12-04 11:46 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/87028eb3f020

Merge


Changeset: b68a5404de60
Author:    lana
Date:      2012-12-10 20:58 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b68a5404de60

Merge

! makefiles/CompileJavaClasses.gmk
- src/share/classes/sun/awt/TextureSizeConstraining.java

Changeset: 379e3dfa521d
Author:    erikj
Date:      2012-12-06 12:09 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/379e3dfa521d

8004104: build-infra: Minor cleanup
Reviewed-by: ohrstrom, tbell

! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk

Changeset: 2689f6cfe835
Author:    erikj
Date:      2012-12-11 12:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2689f6cfe835

8001753: build-infra: mismatch with full debug symbol control for hotspot
Summary: Changing boolean values of ENABLE_DEBUG_SYMBOLS.
Reviewed-by: dholmes, ohair

! makefiles/CompileNativeLibraries.gmk

Changeset: 53fb43e4d614
Author:    katleman
Date:      2012-12-12 13:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/53fb43e4d614

Merge

! makefiles/CompileJavaClasses.gmk
! makefiles/CompileNativeLibraries.gmk

Changeset: 7fd56a5abd94
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7fd56a5abd94

Added tag jdk8-b68 for changeset 53fb43e4d614

! .hgtags


From john.coomes at oracle.com  Fri Dec 14 01:52:15 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 14 Dec 2012 09:52:15 +0000
Subject: hg: hsx/hotspot-main/langtools: 13 new changesets
Message-ID: <20121214095253.A0EE147148@hg.openjdk.java.net>

Changeset: d9fe1f80515d
Author:    vromero
Date:      2012-11-21 18:40 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d9fe1f80515d

7190862: javap shows an incorrect type for operands if the 'wide' prefix is used
7109747: (javap) classfile not treating iinc_w correctly.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/classfile/Instruction.java
! src/share/classes/com/sun/tools/classfile/Opcode.java
+ test/tools/javap/T7190862.java

Changeset: 3746b071d75b
Author:    vromero
Date:      2012-11-21 19:09 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3746b071d75b

6574624: javax.tools.JavaCompiler spec contains errors in sample code
Reviewed-by: jjg, mcimadamore

! src/share/classes/javax/tools/JavaCompiler.java

Changeset: 4d68e2a05b50
Author:    jjg
Date:      2012-11-27 13:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4d68e2a05b50

8004068: Fix build problems caused by on-demand imports
Reviewed-by: jjg
Contributed-by: eric.caspole at amd.com

! src/share/classes/com/sun/tools/javac/code/Types.java

Changeset: 1f41a5758cf7
Author:    vromero
Date:      2012-11-23 15:13 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1f41a5758cf7

7144981: javac should ignore ignorable characters in input
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
+ test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java

Changeset: 969c96b980b7
Author:    vromero
Date:      2012-11-29 09:41 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/969c96b980b7

7153958: add constant pool reference to class containing inlined constants
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java
+ test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java

Changeset: 4f9853659bf1
Author:    mcimadamore
Date:      2012-11-30 15:14 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4f9853659bf1

8004105: Expression statement lambdas should be void-compatible
Summary: Fix lambda compatibility rules as per latest EDR
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! test/tools/javac/lambda/LambdaConv21.java
! test/tools/javac/lambda/LambdaConv21.out
! test/tools/javac/lambda/VoidCompatibility.out

Changeset: 34d1ebaf4645
Author:    mcimadamore
Date:      2012-11-30 15:14 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/34d1ebaf4645

8004102: Add support for generic functional descriptors
Summary: Method references are allowed to have a generic functional interface descriptor target
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
- test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java
+ test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java
+ test/tools/javac/lambda/FunctionalInterfaceConversionTest.java
- test/tools/javac/lambda/LambdaConversionTest.java
+ test/tools/javac/lambda/MethodReference57.java
+ test/tools/javac/lambda/MethodReference58.java
+ test/tools/javac/lambda/MethodReference58.out

Changeset: 9b26c96f5138
Author:    mcimadamore
Date:      2012-11-30 15:14 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9b26c96f5138

8004101: Add checks for method reference well-formedness
Summary: Bring method reference type-checking in sync with latest EDR
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/diags/examples/StaticBoundMref.java
+ test/tools/javac/diags/examples/StaticMrefWithTargs.java
! test/tools/javac/lambda/MethodReference30.java
+ test/tools/javac/lambda/MethodReference55.java
+ test/tools/javac/lambda/MethodReference55.out
+ test/tools/javac/lambda/MethodReference56.java
+ test/tools/javac/lambda/MethodReference56.out
! test/tools/javac/lambda/methodReference/MethodRef1.java
! test/tools/javac/lambda/methodReference/SamConversion.java
! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java

Changeset: f6f1fd261f57
Author:    mcimadamore
Date:      2012-11-30 15:14 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f6f1fd261f57

8002099: Add support for intersection types in cast expression
Summary: Add parser and type-checking support for intersection types in cast expressions
Reviewed-by: jjg

+ src/share/classes/com/sun/source/tree/IntersectionTypeTree.java
! src/share/classes/com/sun/source/tree/Tree.java
! src/share/classes/com/sun/source/tree/TreeVisitor.java
! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java
+ src/share/classes/javax/lang/model/type/IntersectionType.java
! src/share/classes/javax/lang/model/type/TypeKind.java
! src/share/classes/javax/lang/model/type/TypeVisitor.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java
+ test/tools/javac/cast/intersection/IntersectionTypeCastTest.java
+ test/tools/javac/cast/intersection/IntersectionTypeParserTest.java
+ test/tools/javac/cast/intersection/model/Check.java
+ test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java
+ test/tools/javac/cast/intersection/model/Member.java
+ test/tools/javac/cast/intersection/model/Model01.java
+ test/tools/javac/cast/intersection/model/ModelChecker.java
+ test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java
+ test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
+ test/tools/javac/lambda/Intersection01.java
+ test/tools/javac/lambda/Intersection01.out
! test/tools/javac/lambda/LambdaParserTest.java
+ test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java

Changeset: 98e14fc9ee11
Author:    lana
Date:      2012-11-30 16:34 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/98e14fc9ee11

Merge


Changeset: 0e70eb71fec0
Author:    mcimadamore
Date:      2012-12-04 17:19 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0e70eb71fec0

8004360: regression test DefaultMethodRegressionTests fails in langtools
Summary: ignore broken failing test
Reviewed-by: jjg

- test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java
+ test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java

Changeset: 014a6a11dfe5
Author:    lana
Date:      2012-12-10 20:59 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/014a6a11dfe5

Merge

- test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java
- test/tools/javac/lambda/LambdaConversionTest.java

Changeset: 13ccb5269f3d
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/13ccb5269f3d

Added tag jdk8-b68 for changeset 014a6a11dfe5

! .hgtags


From aleksey.shipilev at oracle.com  Fri Dec 14 07:25:58 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 14 Dec 2012 19:25:58 +0400
Subject: RFR (M) #3 CR 8003985: Support @Contended annotation
In-Reply-To: <50C8E9F5.2090904@oracle.com>
References: <50C609EB.2000505@oracle.com>
	<FD538471-91A2-4D33-BEF5-A0C07030AE68@oracle.com>
	<50C72FEE.5060203@oracle.com>
	<A0906C96-DF5A-4C8A-8B02-D54ED88BE4BF@oracle.com>
	<50C89DE9.6080308@oracle.com>
	<C95DA1FC-5CC8-43EC-848E-8F35CA5A36CC@oracle.com>
	<50C8E9F5.2090904@oracle.com>
Message-ID: <50CB4506.8080406@oracle.com>

OK, here's the fix for that latest sentiment :)
 http://shipilev.net/pub/jdk/hotspot/contended/webrev-9/

Testing:
 - JPRT builds completed on all platforms
 - JPRT full-cycle testing in underway
 - (I will also try to submit a couple of VM test suites over the
weekend, but expect no failures, since there was no semantical changes
after the last time)

I think this CR is ready for inclusion. Please let me know is some more
due diligence is required.

-Aleksey.

On 12/13/2012 12:32 AM, Coleen Phillimore wrote:
> 
> Alexey,
> 
> Thank you for not increasing field space.   I had an additional
> comment.  Can you make the printing code from 4116-4142 be a function
> call?   The function parseClassFile is now 1190 lines long, but you
> don't want to make it worse if you don't have to. This badly needs
> refactoring in the future.   This function does too much.
> 
> Thanks,
> Coleen
> 
> On 12/12/2012 3:00 PM, John Rose wrote:
>> On Dec 12, 2012, at 7:08 AM, Aleksey Shipilev wrote:
>>
>>> he updated version is here:
>>>   http://shipilev.net/pub/jdk/hotspot/contended/webrev-8/
>>>
>>> Testing:
>>>   - built and tested on Linux x86_64
>>>   - Test8003985 passes on Linux x86_64
>>>   - JPRT is acting corky today, will try to submit a job later
>>>
>>> Meanwhile, please take a look at the code.
>> It's good.  Ship it!
>>
>> ? John
>>
>> P.S. Your test is the fifth jtreg test to use the hack of grabbing the
>> private field Unsafe.theUnsafe.  If there is an alternative to that,
>> we should use it.  In particular, if jtreg allows test classes to be
>> loaded on the boot class path, then the public method Unsafe.getUnsafe
>> can be used, and that would be much cleaner.
>>
> 


From jesper.wilhelmsson at oracle.com  Fri Dec 14 11:42:02 2012
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 14 Dec 2012 19:42:02 +0000
Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets
Message-ID: <20121214194218.D687547178@hg.openjdk.java.net>

Changeset: 442f942757c0
Author:    johnc
Date:      2012-10-01 09:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/442f942757c0

8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack
Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory.
Reviewed-by: jmasa, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: a14c5698a162
Author:    johnc
Date:      2012-12-07 16:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a14c5698a162

Merge


Changeset: 2aa953165ade
Author:    brutisso
Date:      2012-12-13 10:09 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2aa953165ade

8004661: Comment and function name java_lang_String::toHash is wrong
Summary: renamed to hash_code
Reviewed-by: dholmes, coleenp, brutisso
Contributed-by: erik.helin at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/symbolTable.cpp

Changeset: db8a7163c682
Author:    stefank
Date:      2012-12-13 09:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db8a7163c682

8004674: Add necessary .inline.hpp files to fix non-PCH build
Reviewed-by: stefank, coleenp
Contributed-by: volker.simonis at gmail.com

! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp
! src/share/vm/gc_implementation/shared/gcStats.cpp

Changeset: 4459ef2189f5
Author:    stefank
Date:      2012-12-13 09:06 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4459ef2189f5

Merge



From gary.collins at oracle.com  Fri Dec 14 13:58:41 2012
From: gary.collins at oracle.com (gary.collins at oracle.com)
Date: Fri, 14 Dec 2012 21:58:41 +0000
Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets
Message-ID: <20121214215849.0B4DD4717F@hg.openjdk.java.net>

Changeset: fd74228fd5ca
Author:    jiangli
Date:      2012-12-11 12:41 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd74228fd5ca

8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing.
Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing.
Reviewed-by: coleenp, minqi, jrose

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/method.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 807f1d348f7b
Author:    collins
Date:      2012-12-14 11:45 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/807f1d348f7b

Merge



From ioi.lam at oracle.com  Fri Dec 14 14:04:18 2012
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 14 Dec 2012 14:04:18 -0800
Subject: The magic of self-patching vtable
In-Reply-To: <13F69A76-5D17-414F-865E-A25AF54150FB@oracle.com>
References: <50CAC46C.6020408@oracle.com> <50CB239E.9050705@oracle.com>
	<50CB901D.8000406@oracle.com> <50CB926C.9060504@oracle.com>
	<13F69A76-5D17-414F-865E-A25AF54150FB@oracle.com>
Message-ID: <50CBA262.5010806@oracle.com>

Moving this discussion to hotspot-dev per John's suggestion.

Actually, strictly from the point of view of CDS, it would be OK for 
objects in the RO region to have vtables. This is because the _vptr is 
fixed during dump time, and never modified during runtime.

Only the contents of the vtables (pointed to by _vptr) are updated at 
CDS image load time.

- Ioi


On 12/14/2012 01:31 PM, John Rose wrote:
> This is really interesting.
>
> I'll bet there could be a shell script that could detect and flag unintentional vtables on RO classes, at least on Linux or Solaris. That would be enough to block JPRT submissions.
>
> -- John
>
> On Dec 14, 2012, at 12:56 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> On 12/14/2012 3:46 PM, Ioi Lam wrote:
>>> Hi Coleen,
>>>
>>> Yes, I could find lots comments for 'how' the self-patching vtable works. I just couldn't find a justification for 'why' it needs to be done this way.
>>>
>>> The _vptr of all the Metadata objects in the CDS image are already fixed during dump time. They are never changed at run-time. I.e., immediately after the CDS image is loaded, we have this invariant:
>>>
>>> Universe::boolArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>> Universe::byteArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>> Universe::charArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>> ...
>>>
>>> where
>>>
>>> cds_TypeArrayKlass_vtable points to somewhere slightly above the "md" region of the mapped CDS image.
>>>
>>> If we can find out the size of the vtable for TypeArrayKlass, using the method I proposed below, why can't we simply do this as part of CDS image loading?
>>>
>>> {
>>>     TypeArrayKlass o;
>>>     void * real_vptr = *(void**)(&o);// == o._vptr;
>>>     memcpy(cds_TypeArrayKlass_vtable, real_vptr, sizeof(void*) * num_vtable_slots_TypeArrayKlass);
>>> }
>> Yeah, that would be good except I can't figure out how that works, but I'll take your word for it rather than trying to work it out right now.
>>
>> You'd do this restoration in the function restore_unshareable_info() instead of loading (lazily) though.
>>
>> Coleen
>>
>>> Thanks
>>> - Ioi
>>>
>>> On 12/14/2012 05:03 AM, Coleen Phillimore wrote:
>>>> Hi Ioi,
>>>>
>>>> There are comments about self-patching vtables in memory/universe.cpp and memory/metaspaceShared.cpp and the target dependent metaspaceShared_<cpu>.cpp code.    You have summarized how/why it works quite nicely.     The main reason for vtable patching is that the .text is in different places for the executables which load the shared archive, so we have this code to fix it up in the miscellaneous code section.
>>>>
>>>> The other thing you might have left off which people should be very aware of is that metadata that is shared read-only, like classes ConstMethod, Array<alltypes>, and Symbols. Adding virtual function calls to these will result in them having a self-patching vtable and they will no longer be read only.    Do not add virtual functions to these types!   I hope there are enough comments warning of this.   I cannot think of a programmatic way to disallow this.
>>>>
>>>> I have another comment for your [5]-[6] below.   The cpu dependent code is to create the self patching entries per platform.  We can't tell how long the vtable is so picked 200 for historical purposes.   But we still need the cpu dependent code because we still need vtable patching because of point [2] and it's done with macro assembler.   If the macro assembler was made to be a high level macro assembler, we wouldn't need cpu dependent code. Knowing in advance the size of the vtable would save the hard-coded constant, but that's not really a big benefit.
>>>>
>>>> An aside why 200 was picked.  In the pre-permgen world, the metadata in the shared space were Java objects and were inherited from oopDesc.   Any new virtual function added for GC in oopDesc would regularly blow out the length of the vtable size.   This isn't the case anymore since the base class for these types is Metadata and there aren't very many virtual functions there.   The type Klass* has a lot more, but still way under 200.   A sanity check in debug mode might be useful.
>>>>
>>>> thanks,
>>>> Coleen
>>>>
>>>> On 12/14/2012 1:17 AM, Ioi Lam wrote:
>>>>> Hi,
>>>>>
>>>>> I am reading the CDS code and came upon the rather intriguing concept of "self patching vtables" -- i.e., patch_klass_vtables() and friends in hotspot/src/share/vm/memory/metaspaceShared.cpp.
>>>>>
>>>>> I couldn't find any comments in the source code for the reasons for such a complicated mechanism. Here's my understanding of it. Please let me know if this is correct:
>>>>>
>>>>> [1] Objects of the Metadata types (such as Klass and ConstantPool) have vtables.
>>>>>     In GCC this is the field <Type>::_vptr, i.e., first word in
>>>>>     the object.
>>>>>
>>>>> [2] Addresses of the vtables and the methods may be different across JVM runs,
>>>>>     if libjvm.so is loaded at a different base address.
>>>>>
>>>>> [3] Although all of the Metadata objects are mapped R/W in the CDS image,
>>>>>     at load time, we don't want to rewrite _vptr of each Metadata object
>>>>>     (to maximize sharing).
>>>>>
>>>>> [4] Therefore, we redirect _vptr to our own vtables at CDS image dump time.
>>>>>     Then,we patch our own vtables at run time.
>>>>>
>>>>> [5] The problem with [4] is with most C++ compilers (all?), there is no
>>>>>     easy way to tell the size of the vtable of a given type.
>>>>>
>>>>> [6] We cannot safely copy more than the size of the real vtable, because the
>>>>>     real vtable may be at the end of the code section; reading past its end
>>>>>     would cause the VM to crash.
>>>>>
>>>>> As a result, the current design of the 'self patching vtable' is to
>>>>> create a vtable that's "big enough" (currently with 200 method slots).
>>>>> Each slot points to a generated stub that knows the C++ type and
>>>>> virtual method index of the invoked method. When the stub is invoked,
>>>>> it will look up the real method and patch the vtable accordingly.
>>>>>
>>>>> -----
>>>>>
>>>>> If I am right that the whole reason for the self patching vtables is getting the length of the vtable, wouldn't it be much easier if we do:
>>>>>
>>>>> class InstanceKlassVTableLengthFinder: public InstanceKlass {
>>>>> public:
>>>>>     virtual void ___end_of_vtable_marker();
>>>>> };
>>>>>
>>>>> and then just search for ___end_of_vtable_marker() from the _vptr?
>>>>>
>>>>> That way we can get rid of all the CPU dependent code related to self-patching vtables.
>>>>>
>>>>> - Ioi


From Vasanth.Venkatachalam at amd.com  Fri Dec 14 14:08:29 2012
From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth)
Date: Fri, 14 Dec 2012 22:08:29 +0000
Subject: adding a new ISA
Message-ID: <5DD1503F815BD14889DC81D28643E3A7329CC9BB@sausexdag06.amd.com>

Apologies for the cross-posting, but I thought this would get a wider audience on hotspot-dev...

Modifying the JVM to support a new ISA (such as the GPU) would require extensive changes.
I was wondering what people's thoughts were on the following:


1)      What guidelines do people use for deciding which components of the JVM to start modifying or writing code for? It seems like a good guideline would be to start with the changes that are the most straightforward, such as register definitions or the assembler. Do people have other ideas?

2)      How do people incrementally test components that depend upon the rest of the software which isn't in place yet? For example, if you update the register allocator and nothing else, how would you test this change without having the rest of the JVM in place?

Vasanth

--
Vasanth Venkatachalam
AMD Runtimes
(512)602-6177


From coleen.phillimore at oracle.com  Fri Dec 14 14:10:01 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 14 Dec 2012 17:10:01 -0500
Subject: The magic of self-patching vtable
In-Reply-To: <50CBA262.5010806@oracle.com>
References: <50CAC46C.6020408@oracle.com> <50CB239E.9050705@oracle.com>
	<50CB901D.8000406@oracle.com> <50CB926C.9060504@oracle.com>
	<13F69A76-5D17-414F-865E-A25AF54150FB@oracle.com>
	<50CBA262.5010806@oracle.com>
Message-ID: <50CBA3B9.4070101@oracle.com>

On 12/14/2012 5:04 PM, Ioi Lam wrote:
> Moving this discussion to hotspot-dev per John's suggestion.
>
> Actually, strictly from the point of view of CDS, it would be OK for 
> objects in the RO region to have vtables. This is because the _vptr is 
> fixed during dump time, and never modified during runtime.
>
> Only the contents of the vtables (pointed to by _vptr) are updated at 
> CDS image load time.

The way it works today is that the _vptr in the object is replaced, so 
you'd have to change that.

Coleen

>
> - Ioi
>
>
> On 12/14/2012 01:31 PM, John Rose wrote:
>> This is really interesting.
>>
>> I'll bet there could be a shell script that could detect and flag 
>> unintentional vtables on RO classes, at least on Linux or Solaris. 
>> That would be enough to block JPRT submissions.
>>
>> -- John
>>
>> On Dec 14, 2012, at 12:56 PM, Coleen Phillimore 
>> <coleen.phillimore at oracle.com> wrote:
>>
>>> On 12/14/2012 3:46 PM, Ioi Lam wrote:
>>>> Hi Coleen,
>>>>
>>>> Yes, I could find lots comments for 'how' the self-patching vtable 
>>>> works. I just couldn't find a justification for 'why' it needs to 
>>>> be done this way.
>>>>
>>>> The _vptr of all the Metadata objects in the CDS image are already 
>>>> fixed during dump time. They are never changed at run-time. I.e., 
>>>> immediately after the CDS image is loaded, we have this invariant:
>>>>
>>>> Universe::boolArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>> Universe::byteArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>> Universe::charArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>> ...
>>>>
>>>> where
>>>>
>>>> cds_TypeArrayKlass_vtable points to somewhere slightly above the 
>>>> "md" region of the mapped CDS image.
>>>>
>>>> If we can find out the size of the vtable for TypeArrayKlass, using 
>>>> the method I proposed below, why can't we simply do this as part of 
>>>> CDS image loading?
>>>>
>>>> {
>>>>     TypeArrayKlass o;
>>>>     void * real_vptr = *(void**)(&o);// == o._vptr;
>>>>     memcpy(cds_TypeArrayKlass_vtable, real_vptr, sizeof(void*) * 
>>>> num_vtable_slots_TypeArrayKlass);
>>>> }
>>> Yeah, that would be good except I can't figure out how that works, 
>>> but I'll take your word for it rather than trying to work it out 
>>> right now.
>>>
>>> You'd do this restoration in the function restore_unshareable_info() 
>>> instead of loading (lazily) though.
>>>
>>> Coleen
>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>> On 12/14/2012 05:03 AM, Coleen Phillimore wrote:
>>>>> Hi Ioi,
>>>>>
>>>>> There are comments about self-patching vtables in 
>>>>> memory/universe.cpp and memory/metaspaceShared.cpp and the target 
>>>>> dependent metaspaceShared_<cpu>.cpp code. You have summarized 
>>>>> how/why it works quite nicely.     The main reason for vtable 
>>>>> patching is that the .text is in different places for the 
>>>>> executables which load the shared archive, so we have this code to 
>>>>> fix it up in the miscellaneous code section.
>>>>>
>>>>> The other thing you might have left off which people should be 
>>>>> very aware of is that metadata that is shared read-only, like 
>>>>> classes ConstMethod, Array<alltypes>, and Symbols. Adding virtual 
>>>>> function calls to these will result in them having a self-patching 
>>>>> vtable and they will no longer be read only.    Do not add virtual 
>>>>> functions to these types!   I hope there are enough comments 
>>>>> warning of this.   I cannot think of a programmatic way to 
>>>>> disallow this.
>>>>>
>>>>> I have another comment for your [5]-[6] below.   The cpu dependent 
>>>>> code is to create the self patching entries per platform.  We 
>>>>> can't tell how long the vtable is so picked 200 for historical 
>>>>> purposes.   But we still need the cpu dependent code because we 
>>>>> still need vtable patching because of point [2] and it's done with 
>>>>> macro assembler. If the macro assembler was made to be a high 
>>>>> level macro assembler, we wouldn't need cpu dependent code. 
>>>>> Knowing in advance the size of the vtable would save the 
>>>>> hard-coded constant, but that's not really a big benefit.
>>>>>
>>>>> An aside why 200 was picked.  In the pre-permgen world, the 
>>>>> metadata in the shared space were Java objects and were inherited 
>>>>> from oopDesc.   Any new virtual function added for GC in oopDesc 
>>>>> would regularly blow out the length of the vtable size.   This 
>>>>> isn't the case anymore since the base class for these types is 
>>>>> Metadata and there aren't very many virtual functions there.   The 
>>>>> type Klass* has a lot more, but still way under 200.   A sanity 
>>>>> check in debug mode might be useful.
>>>>>
>>>>> thanks,
>>>>> Coleen
>>>>>
>>>>> On 12/14/2012 1:17 AM, Ioi Lam wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am reading the CDS code and came upon the rather intriguing 
>>>>>> concept of "self patching vtables" -- i.e., patch_klass_vtables() 
>>>>>> and friends in hotspot/src/share/vm/memory/metaspaceShared.cpp.
>>>>>>
>>>>>> I couldn't find any comments in the source code for the reasons 
>>>>>> for such a complicated mechanism. Here's my understanding of it. 
>>>>>> Please let me know if this is correct:
>>>>>>
>>>>>> [1] Objects of the Metadata types (such as Klass and 
>>>>>> ConstantPool) have vtables.
>>>>>>     In GCC this is the field <Type>::_vptr, i.e., first word in
>>>>>>     the object.
>>>>>>
>>>>>> [2] Addresses of the vtables and the methods may be different 
>>>>>> across JVM runs,
>>>>>>     if libjvm.so is loaded at a different base address.
>>>>>>
>>>>>> [3] Although all of the Metadata objects are mapped R/W in the 
>>>>>> CDS image,
>>>>>>     at load time, we don't want to rewrite _vptr of each Metadata 
>>>>>> object
>>>>>>     (to maximize sharing).
>>>>>>
>>>>>> [4] Therefore, we redirect _vptr to our own vtables at CDS image 
>>>>>> dump time.
>>>>>>     Then,we patch our own vtables at run time.
>>>>>>
>>>>>> [5] The problem with [4] is with most C++ compilers (all?), there 
>>>>>> is no
>>>>>>     easy way to tell the size of the vtable of a given type.
>>>>>>
>>>>>> [6] We cannot safely copy more than the size of the real vtable, 
>>>>>> because the
>>>>>>     real vtable may be at the end of the code section; reading 
>>>>>> past its end
>>>>>>     would cause the VM to crash.
>>>>>>
>>>>>> As a result, the current design of the 'self patching vtable' is to
>>>>>> create a vtable that's "big enough" (currently with 200 method 
>>>>>> slots).
>>>>>> Each slot points to a generated stub that knows the C++ type and
>>>>>> virtual method index of the invoked method. When the stub is 
>>>>>> invoked,
>>>>>> it will look up the real method and patch the vtable accordingly.
>>>>>>
>>>>>> -----
>>>>>>
>>>>>> If I am right that the whole reason for the self patching vtables 
>>>>>> is getting the length of the vtable, wouldn't it be much easier 
>>>>>> if we do:
>>>>>>
>>>>>> class InstanceKlassVTableLengthFinder: public InstanceKlass {
>>>>>> public:
>>>>>>     virtual void ___end_of_vtable_marker();
>>>>>> };
>>>>>>
>>>>>> and then just search for ___end_of_vtable_marker() from the _vptr?
>>>>>>
>>>>>> That way we can get rid of all the CPU dependent code related to 
>>>>>> self-patching vtables.
>>>>>>
>>>>>> - Ioi
>


From ioi.lam at oracle.com  Fri Dec 14 14:29:41 2012
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 14 Dec 2012 14:29:41 -0800
Subject: The magic of self-patching vtable
In-Reply-To: <50CBA3B9.4070101@oracle.com>
References: <50CAC46C.6020408@oracle.com> <50CB239E.9050705@oracle.com>
	<50CB901D.8000406@oracle.com> <50CB926C.9060504@oracle.com>
	<13F69A76-5D17-414F-865E-A25AF54150FB@oracle.com>
	<50CBA262.5010806@oracle.com> <50CBA3B9.4070101@oracle.com>
Message-ID: <50CBA855.4050201@oracle.com>

On 12/14/2012 02:10 PM, Coleen Phillimore wrote:
> On 12/14/2012 5:04 PM, Ioi Lam wrote:
>> Moving this discussion to hotspot-dev per John's suggestion.
>>
>> Actually, strictly from the point of view of CDS, it would be OK for 
>> objects in the RO region to have vtables. This is because the _vptr 
>> is fixed during dump time, and never modified during runtime.
>>
>> Only the contents of the vtables (pointed to by _vptr) are updated at 
>> CDS image load time.
>
> The way it works today is that the _vptr in the object is replaced, so 
> you'd have to change that.
>
> Coleen
>

Hi Coleen,

As far as I can see in today's code, _vptr is replaced here 
(metaspaceShared.cpp, version 3823:070d523b96a7), which is called at 
dumping time. During dumping time, the "RO" section is actually writable.

// Assumes the vtable is in first slot in object.
static void patch_klass_vtables(void** vtbl_list, void* new_vtable_start) {
   int n = _global_klass_objects->length();
   for (int i = 0; i < n; i++) {
     Klass* obj = _global_klass_objects->at(i);
     // Note oop_is_instance() is a virtual call.  After patching vtables
     // all virtual calls on the dummy vtables will restore the original!
     if (obj->oop_is_instance()) {
       InstanceKlass* ik = InstanceKlass::cast(obj);
       *(void**)ik = find_matching_vtbl_ptr(vtbl_list, new_vtable_start, 
ik);
       ConstantPool* cp = ik->constants();
       *(void**)cp = find_matching_vtbl_ptr(vtbl_list, new_vtable_start, 
cp);
       for (int j = 0; j < ik->methods()->length(); j++) {
         Method* m = ik->methods()->at(j);
         *(void**)m = find_matching_vtbl_ptr(vtbl_list, 
new_vtable_start, m);
       }
     } else {
       // Array klasses
       Klass* k = obj;
       *(void**)k = find_matching_vtbl_ptr(vtbl_list, new_vtable_start, k);
     }
   }
}

- Ioi

>>
>> - Ioi
>>
>>
>> On 12/14/2012 01:31 PM, John Rose wrote:
>>> This is really interesting.
>>>
>>> I'll bet there could be a shell script that could detect and flag 
>>> unintentional vtables on RO classes, at least on Linux or Solaris. 
>>> That would be enough to block JPRT submissions.
>>>
>>> -- John
>>>
>>> On Dec 14, 2012, at 12:56 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>> On 12/14/2012 3:46 PM, Ioi Lam wrote:
>>>>> Hi Coleen,
>>>>>
>>>>> Yes, I could find lots comments for 'how' the self-patching vtable 
>>>>> works. I just couldn't find a justification for 'why' it needs to 
>>>>> be done this way.
>>>>>
>>>>> The _vptr of all the Metadata objects in the CDS image are already 
>>>>> fixed during dump time. They are never changed at run-time. I.e., 
>>>>> immediately after the CDS image is loaded, we have this invariant:
>>>>>
>>>>> Universe::boolArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>>> Universe::byteArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>>> Universe::charArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>>> ...
>>>>>
>>>>> where
>>>>>
>>>>> cds_TypeArrayKlass_vtable points to somewhere slightly above the 
>>>>> "md" region of the mapped CDS image.
>>>>>
>>>>> If we can find out the size of the vtable for TypeArrayKlass, 
>>>>> using the method I proposed below, why can't we simply do this as 
>>>>> part of CDS image loading?
>>>>>
>>>>> {
>>>>>     TypeArrayKlass o;
>>>>>     void * real_vptr = *(void**)(&o);// == o._vptr;
>>>>>     memcpy(cds_TypeArrayKlass_vtable, real_vptr, sizeof(void*) * 
>>>>> num_vtable_slots_TypeArrayKlass);
>>>>> }
>>>> Yeah, that would be good except I can't figure out how that works, 
>>>> but I'll take your word for it rather than trying to work it out 
>>>> right now.
>>>>
>>>> You'd do this restoration in the function 
>>>> restore_unshareable_info() instead of loading (lazily) though.
>>>>
>>>> Coleen
>>>>
>>>>> Thanks
>>>>> - Ioi
>>>>>
>>>>> On 12/14/2012 05:03 AM, Coleen Phillimore wrote:
>>>>>> Hi Ioi,
>>>>>>
>>>>>> There are comments about self-patching vtables in 
>>>>>> memory/universe.cpp and memory/metaspaceShared.cpp and the target 
>>>>>> dependent metaspaceShared_<cpu>.cpp code. You have summarized 
>>>>>> how/why it works quite nicely.     The main reason for vtable 
>>>>>> patching is that the .text is in different places for the 
>>>>>> executables which load the shared archive, so we have this code 
>>>>>> to fix it up in the miscellaneous code section.
>>>>>>
>>>>>> The other thing you might have left off which people should be 
>>>>>> very aware of is that metadata that is shared read-only, like 
>>>>>> classes ConstMethod, Array<alltypes>, and Symbols. Adding virtual 
>>>>>> function calls to these will result in them having a 
>>>>>> self-patching vtable and they will no longer be read only.    Do 
>>>>>> not add virtual functions to these types! I hope there are enough 
>>>>>> comments warning of this.   I cannot think of a programmatic way 
>>>>>> to disallow this.
>>>>>>
>>>>>> I have another comment for your [5]-[6] below.   The cpu 
>>>>>> dependent code is to create the self patching entries per 
>>>>>> platform.  We can't tell how long the vtable is so picked 200 for 
>>>>>> historical purposes.   But we still need the cpu dependent code 
>>>>>> because we still need vtable patching because of point [2] and 
>>>>>> it's done with macro assembler. If the macro assembler was made 
>>>>>> to be a high level macro assembler, we wouldn't need cpu 
>>>>>> dependent code. Knowing in advance the size of the vtable would 
>>>>>> save the hard-coded constant, but that's not really a big benefit.
>>>>>>
>>>>>> An aside why 200 was picked.  In the pre-permgen world, the 
>>>>>> metadata in the shared space were Java objects and were inherited 
>>>>>> from oopDesc.   Any new virtual function added for GC in oopDesc 
>>>>>> would regularly blow out the length of the vtable size.   This 
>>>>>> isn't the case anymore since the base class for these types is 
>>>>>> Metadata and there aren't very many virtual functions there.   
>>>>>> The type Klass* has a lot more, but still way under 200.   A 
>>>>>> sanity check in debug mode might be useful.
>>>>>>
>>>>>> thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 12/14/2012 1:17 AM, Ioi Lam wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am reading the CDS code and came upon the rather intriguing 
>>>>>>> concept of "self patching vtables" -- i.e., 
>>>>>>> patch_klass_vtables() and friends in 
>>>>>>> hotspot/src/share/vm/memory/metaspaceShared.cpp.
>>>>>>>
>>>>>>> I couldn't find any comments in the source code for the reasons 
>>>>>>> for such a complicated mechanism. Here's my understanding of it. 
>>>>>>> Please let me know if this is correct:
>>>>>>>
>>>>>>> [1] Objects of the Metadata types (such as Klass and 
>>>>>>> ConstantPool) have vtables.
>>>>>>>     In GCC this is the field <Type>::_vptr, i.e., first word in
>>>>>>>     the object.
>>>>>>>
>>>>>>> [2] Addresses of the vtables and the methods may be different 
>>>>>>> across JVM runs,
>>>>>>>     if libjvm.so is loaded at a different base address.
>>>>>>>
>>>>>>> [3] Although all of the Metadata objects are mapped R/W in the 
>>>>>>> CDS image,
>>>>>>>     at load time, we don't want to rewrite _vptr of each 
>>>>>>> Metadata object
>>>>>>>     (to maximize sharing).
>>>>>>>
>>>>>>> [4] Therefore, we redirect _vptr to our own vtables at CDS image 
>>>>>>> dump time.
>>>>>>>     Then,we patch our own vtables at run time.
>>>>>>>
>>>>>>> [5] The problem with [4] is with most C++ compilers (all?), 
>>>>>>> there is no
>>>>>>>     easy way to tell the size of the vtable of a given type.
>>>>>>>
>>>>>>> [6] We cannot safely copy more than the size of the real vtable, 
>>>>>>> because the
>>>>>>>     real vtable may be at the end of the code section; reading 
>>>>>>> past its end
>>>>>>>     would cause the VM to crash.
>>>>>>>
>>>>>>> As a result, the current design of the 'self patching vtable' is to
>>>>>>> create a vtable that's "big enough" (currently with 200 method 
>>>>>>> slots).
>>>>>>> Each slot points to a generated stub that knows the C++ type and
>>>>>>> virtual method index of the invoked method. When the stub is 
>>>>>>> invoked,
>>>>>>> it will look up the real method and patch the vtable accordingly.
>>>>>>>
>>>>>>> -----
>>>>>>>
>>>>>>> If I am right that the whole reason for the self patching 
>>>>>>> vtables is getting the length of the vtable, wouldn't it be much 
>>>>>>> easier if we do:
>>>>>>>
>>>>>>> class InstanceKlassVTableLengthFinder: public InstanceKlass {
>>>>>>> public:
>>>>>>>     virtual void ___end_of_vtable_marker();
>>>>>>> };
>>>>>>>
>>>>>>> and then just search for ___end_of_vtable_marker() from the _vptr?
>>>>>>>
>>>>>>> That way we can get rid of all the CPU dependent code related to 
>>>>>>> self-patching vtables.
>>>>>>>
>>>>>>> - Ioi
>>
>


From bharadwaj.yadavalli at oracle.com  Fri Dec 14 14:34:54 2012
From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli)
Date: Fri, 14 Dec 2012 17:34:54 -0500
Subject: Copying libjvm.{diz,debuginfo}
Message-ID: <50CBA98E.5000206@oracle.com>

I would like to build a debuggable vm (libjvm.so) during OpenJDK build.

I configured using

sh configure --with-debug-level=slowdebug --enable-debug-symbols 
--with-boot-jdk=/path/to/boot/jdk

and then ran

make NEWBUILD=true images

The build does not copy libjvm.diz to 
build/linux-x86_64-normal-server-slowdebug/jdk/lib/amd64/server/

Is there a way to configure the build so that it copies the debug info 
along with libjvm.so each time it is updated?

Bharadwaj


From alejandro.murillo at oracle.com  Fri Dec 14 16:18:25 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 15 Dec 2012 00:18:25 +0000
Subject: hg: hsx/hsx25/hotspot: 11 new changesets
Message-ID: <20121215001853.8312D47182@hg.openjdk.java.net>

Changeset: 8af7d22f1f8f
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8af7d22f1f8f

Added tag jdk8-b68 for changeset 121aa71316af

! .hgtags

Changeset: 4a2ed49abd51
Author:    amurillo
Date:      2012-12-07 10:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a2ed49abd51

8004724: new hotspot build - hs25-b13
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 442f942757c0
Author:    johnc
Date:      2012-10-01 09:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/442f942757c0

8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack
Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory.
Reviewed-by: jmasa, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: a14c5698a162
Author:    johnc
Date:      2012-12-07 16:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a14c5698a162

Merge


Changeset: 2aa953165ade
Author:    brutisso
Date:      2012-12-13 10:09 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2aa953165ade

8004661: Comment and function name java_lang_String::toHash is wrong
Summary: renamed to hash_code
Reviewed-by: dholmes, coleenp, brutisso
Contributed-by: erik.helin at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/symbolTable.cpp

Changeset: db8a7163c682
Author:    stefank
Date:      2012-12-13 09:28 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/db8a7163c682

8004674: Add necessary .inline.hpp files to fix non-PCH build
Reviewed-by: stefank, coleenp
Contributed-by: volker.simonis at gmail.com

! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp
! src/share/vm/gc_implementation/shared/gcStats.cpp

Changeset: 4459ef2189f5
Author:    stefank
Date:      2012-12-13 09:06 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4459ef2189f5

Merge


Changeset: fd74228fd5ca
Author:    jiangli
Date:      2012-12-11 12:41 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fd74228fd5ca

8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing.
Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing.
Reviewed-by: coleenp, minqi, jrose

! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/method.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 807f1d348f7b
Author:    collins
Date:      2012-12-14 11:45 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/807f1d348f7b

Merge


Changeset: b6c9c0109a60
Author:    amurillo
Date:      2012-12-14 14:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b6c9c0109a60

Merge


Changeset: cb8a4e04bc8c
Author:    amurillo
Date:      2012-12-14 14:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cb8a4e04bc8c

Added tag hs25-b13 for changeset b6c9c0109a60

! .hgtags


From tom.deneau at amd.com  Fri Dec 14 17:01:15 2012
From: tom.deneau at amd.com (Deneau, Tom)
Date: Sat, 15 Dec 2012 01:01:15 +0000
Subject: debugging hotspot with gdb 7.5
Message-ID: <BC97738F8E7C8742BABED7F06FB9DF9125CD82C4@sausexdag01.amd.com>

I am trying to debug Hotspot on a newer linux system (Ubuntu 12.10) which has gdb 7.5.
Breakpoints and such work fine but I noticed that when I am at a breakpoint and 
I try to use one of the debug functions such as 
   p universe()

execution of the JVM takes off and runs until exit.  This didn't happen with the previous system
I used which had gdb 7.3.

Is there any workaround for this?

-- Tom Deneau



From vladimir.kozlov at oracle.com  Fri Dec 14 18:16:16 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 15 Dec 2012 02:16:16 +0000
Subject: hg: hsx/hsx24/hotspot: 8004713: Stackoverflowerror thrown when thread
	stack straddles 0x80000000
Message-ID: <20121215021623.249B14718D@hg.openjdk.java.net>

Changeset: 82caec9a04ca
Author:    kvn
Date:      2012-12-13 17:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/82caec9a04ca

8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000
Summary: use unsigned comparison when checking for stack overflow
Reviewed-by: kvn, twisti
Contributed-by: paul.nauman at oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp


From alejandro.murillo at oracle.com  Fri Dec 14 21:54:21 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 15 Dec 2012 05:54:21 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121215055431.EE1B147197@hg.openjdk.java.net>

Changeset: 8af7d22f1f8f
Author:    katleman
Date:      2012-12-13 09:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8af7d22f1f8f

Added tag jdk8-b68 for changeset 121aa71316af

! .hgtags

Changeset: b6c9c0109a60
Author:    amurillo
Date:      2012-12-14 14:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b6c9c0109a60

Merge


Changeset: cb8a4e04bc8c
Author:    amurillo
Date:      2012-12-14 14:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cb8a4e04bc8c

Added tag hs25-b13 for changeset b6c9c0109a60

! .hgtags

Changeset: 1f323009c3ea
Author:    amurillo
Date:      2012-12-14 14:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f323009c3ea

8005036: new hotspot build - hs25-b14
Reviewed-by: jcoomes

! make/hotspot_version


From david.holmes at oracle.com  Sat Dec 15 01:32:16 2012
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 15 Dec 2012 19:32:16 +1000
Subject: Copying libjvm.{diz,debuginfo}
In-Reply-To: <50CBA98E.5000206@oracle.com>
References: <50CBA98E.5000206@oracle.com>
Message-ID: <50CC43A0.8080502@oracle.com>

On 15/12/2012 8:34 AM, Bharadwaj Yadavalli wrote:
> I would like to build a debuggable vm (libjvm.so) during OpenJDK build.
>
> I configured using
>
> sh configure --with-debug-level=slowdebug --enable-debug-symbols
> --with-boot-jdk=/path/to/boot/jdk
>
> and then ran
>
> make NEWBUILD=true images
>
> The build does not copy libjvm.diz to
> build/linux-x86_64-normal-server-slowdebug/jdk/lib/amd64/server/
>
> Is there a way to configure the build so that it copies the debug info
> along with libjvm.so each time it is updated?

It seems to work for me. There was a very recent patch that causes the 
configure "debug-symbols" setting to be passed through to hotspot 
correctly. Check if hotspot-spec.gmk contains a flag to enable 
FULL_DEBUG_SYMBOLS.

David

> Bharadwaj
>

From dl at cs.oswego.edu  Sun Dec 16 15:21:47 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 16 Dec 2012 18:21:47 -0500
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <31D8987F-4713-4FA5-B4E9-CC42D026A5AF@kodewerk.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
	<31D8987F-4713-4FA5-B4E9-CC42D026A5AF@kodewerk.com>
Message-ID: <50CE578B.5000807@cs.oswego.edu>

On 12/14/12 02:17, Kirk Pepperdine wrote:
> Hi Doug et all...
>
> I've been thinking about these intrinsics/annotations and I've been wondering
> if it would be worth exploring somehow setting up intrinsics to allow access
> to the MSRs? With better access to MSR, people might have a better chance of
> using measures to sort out strange effects due to unfortunately alignments of
> data in caches.

I think the main challenge here would be to find some reasonable
light abstraction over MSR-like stuff on all the processors Java
runs on (x86, arm, sparc, power etc) that doesn't lose big by
abstracting away. It took years to figure out JMM
rules that support efficient processor mappings (for
those usages covered by the JMM, which were not enough).
Offhand, this doesn't seem very likely. But it probably
isn't what you want anyway....

>
>  But given that all that is really needed is a
> thin C++ wrapper over a small amount of assembler, it would be so much easier
> to support this either in the JVMTI or in s.m.u.

Here's a plan: Allow C++ code to be embedded in Java code.
Then allow asm to be embedded in the C++ code. Done. :-)

-Doug





From aleksey.shipilev at oracle.com  Mon Dec 17 01:57:21 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Dec 2012 13:57:21 +0400
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <31D8987F-4713-4FA5-B4E9-CC42D026A5AF@kodewerk.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
	<31D8987F-4713-4FA5-B4E9-CC42D026A5AF@kodewerk.com>
Message-ID: <50CEEC81.60301@oracle.com>

On 12/14/2012 11:17 AM, Kirk Pepperdine wrote:
> The source of my objects to these methods is that they can currently 
> only be applied speculatively.

It sounds as if we don't have the native tools that can map the CPU
events back to Java code? Oracle Solaris Studio Performance Analyzer
folks will disagree with you.

> That said, if the decision has been made to open up access to fencing
> and padding and other CPU tricks, I'd argue that we need to consider
> opening up a way to measure the effects.

Sure, please open up a JEP and discuss the ramifications of this work there.

-Aleksey.

From kirk at kodewerk.com  Mon Dec 17 02:09:24 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Mon, 17 Dec 2012 11:09:24 +0100
Subject: JEP 171: Fence Intrinsics
In-Reply-To: <50CEEC81.60301@oracle.com>
References: <20121203173122.95966787@eggemoggin.niobe.net>
	<002562AD-5D6B-45AF-8618-6915A3428470@oracle.com>
	<50BCE743.10705@cs.oswego.edu>
	<31D8987F-4713-4FA5-B4E9-CC42D026A5AF@kodewerk.com>
	<50CEEC81.60301@oracle.com>
Message-ID: <E170D1F3-646E-4F44-A4FC-8BF325ADCE34@kodewerk.com>


On 2012-12-17, at 10:57 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 12/14/2012 11:17 AM, Kirk Pepperdine wrote:
>> The source of my objects to these methods is that they can currently 
>> only be applied speculatively.
> 
> It sounds as if we don't have the native tools that can map the CPU
> events back to Java code? Oracle Solaris Studio Performance Analyzer
> folks will disagree with you.

Yup, and they'd be wrong.. :-) This is a very inaccessible tool and it doesn't run cross platform and is unfortunately heavily marketed with Solaris and has limited Linux support.

> 
>> That said, if the decision has been made to open up access to fencing
>> and padding and other CPU tricks, I'd argue that we need to consider
>> opening up a way to measure the effects.
> 
> Sure, please open up a JEP and discuss the ramifications of this work there.
> 
> -Aleksey.


From goetz.lindenmaier at sap.com  Mon Dec 17 03:50:12 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 17 Dec 2012 12:50:12 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>

Hi,

I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.

On Platfoms with weak memory ordering the taskqueue is not accessed
properly, as the accesses to the fields _bottom and _age are not ordered
correctly. Volatile is not sufficient to enforce this, because it depends on
what the compiler assumes to be necessary for volatile variables.

The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
use the getter/setter methods to access _bottom, _age or the subfields of _age.
On the other hand we can relax constraints for accesses to locals oldAge and newAge.

The OrderAccess routines do simple load/stores on x86_64.

I want to discuss this change here and would like very much to see it taking
it's way into OpenJDK to support ports on platforms with weak memory
ordering, and, in particular, our PPC port.

Best regards,
  Goetz.



From goetz.lindenmaier at sap.com  Mon Dec 17 04:58:09 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 17 Dec 2012 13:58:09 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>

Hi,

Once more, with webrev:
http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
Sorry for that.

I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.

On Platfoms with weak memory ordering the taskqueue is not accessed
properly, as the accesses to the fields _bottom and _age are not ordered
correctly. Volatile is not sufficient to enforce this, because it depends on
what the compiler assumes to be necessary for volatile variables.

The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
use the getter/setter methods to access _bottom, _age or the subfields of _age.
On the other hand we can relax constraints for accesses to locals oldAge and newAge.

The OrderAccess routines do simple load/stores on x86_64.

I want to discuss this change here and would like very much to see it taking
it's way into OpenJDK to support ports on platforms with weak memory
ordering, and, in particular, our PPC port.

Best regards,
  Goetz.



From coleen.phillimore at oracle.com  Mon Dec 17 05:40:05 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 17 Dec 2012 08:40:05 -0500
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50CAC273.5030501@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
	<50C94841.9090100@oracle.com> <50CAC273.5030501@oracle.com>
Message-ID: <50CF20B5.3040806@oracle.com>


This looks good, thank you for making this change.
Coleen

On 12/14/2012 1:08 AM, Erik Helin wrote:
> Coleen,
>
> On 12/13/2012 04:15 AM, Coleen Phillimore wrote:
>> I think this looks reasonable, although someone from GC should comment
>> on the AbstractGangTask's real allocation type.
>
> what do you think of the latest webrev (which keeps the allocation 
> type for AbstractGangTask):
>
> http://cr.openjdk.java.net/~ehelin/8004845/webrev.01/
>
> This webrev keeps VALUE_OBJ_CLASS_SPEC and instead makes the 
> destructor for the classes AbstractGangTask and 
> YieldingFlexibleGangTask non-virtual.
>
> This was changed because I got some great feedback from David:
>
> On 12/13/2012 05:51 AM, David Holmes wrote:
> > But given that operator delete can NOT be called on these classes you
> > can NOT need a virtual destructor. QED. Hence the correct fixes for
> > MemBaseline and AbstractGangtask (and subclasses) would be to remove 
> the
> > "virtual" from the destructor.
>
> Thanks,
> Erik
>
>> Thanks,
>> Coleen
>>
>> On 12/12/2012 8:44 PM, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 12/12/2012 11:13 PM, Erik Helin wrote:
>>>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>>>> class A {
>>>>>> private:
>>>>>> void operator delete(void *) { }
>>>>>> };
>>>>>>
>>>>>> class B : public A {
>>>>>> public:
>>>>>> B() { }
>>>>>> virtual ~B() { }
>>>>>> };
>>>>>>
>>>>>> > g++ -c foo.cpp
>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>> private
>>>>>> foo.cpp:9:18: error: within this context
>>>>>
>>>>> Okay that kind of makes sense. I was thinking more about them 
>>>>> being in
>>>>> the same class.
>>>>>
>>>>> But this just says to me "don't make new/delete private". (Think of
>>>>> them
>>>>> like virtual methods on Object - you can redefine them but they are
>>>>> always public ;-) )
>>>>
>>>> I believe that the benefit of making new/delete private is that we get
>>>> compile time checking instead of maybe finding out via tests in 
>>>> JPRT (if
>>>> the tests does not traverse a code path with incorrect usage, then we
>>>> won't find it).
>>>
>>> Agreed - but that is at odds with the use of the virtual destructor
>>> ... I also have to wonder why that wasn't done in the first place as
>>> it seems an "obvious" way to ensure they don't get called.
>>>
>>>> In my opinion, if a class has a virtual destructor and inherits from
>>>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>>>> or the class should not inherit from _ValueObj or StackObj.
>>>
>>> I don't think these have to be mutually exclusive in a general sense.
>>> But it may be we don't need both capabilities in the current cases.
>>>
>>>> As far as I can see, the only use for a _virtual_ destructor in a 
>>>> class
>>>> is if you want to delete a pointer to that class (and make sure 
>>>> that the
>>>> destructor of any class inheriting from that class also gets called).
>>>
>>> Yes. If at any time you are likely to invoke delete on a derived class
>>> instance through a base class pointer then you want there to be a
>>> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
>>> edition Section 17.5.5) is that any base class with any virtual
>>> functions should also have a virtual destructor.
>>>
>>> I've had to fix a number of bugs in certain variants of hotspot caused
>>> by lack of a virtual destructor. And I doubt that the current codebase
>>> is particularly "clean" in this regard.
>>>
>>>>  From what I understand, deriving from _ValueObj or StackObj means 
>>>> that
>>>> you don't expect this to happen.
>>>>
>>>> What do you think of this?
>>>
>>> I'm not versed enough in the use of all the different types that
>>> derive from ValueObj and StackObj to answer that definitively. It
>>> seems likely to be true to me - particularly for StackObj. But can we
>>> say it is never needed?
>>>
>>> Given these classes must derive from one of the allocation types, the
>>> only option is to remove the virtual from the destructor, so at a
>>> minimum you have to establish for these types that a virtual
>>> destructor will never be needed.
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>
>>>> Thanks for taking your time,
>>>> Erik
>>>>
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> the webrev is located at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj" 
>>>>>>>> and is
>>>>>>>> used to describe that all instances of a given C++ class can
>>>>>>>> never be
>>>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>>>> delete.
>>>>>>>>
>>>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>>>> operators
>>>>>>>> new and delete by calling ShouldNotCallThis which will crash 
>>>>>>>> the VM.
>>>>>>>>
>>>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>>>> and this change instead declares them as private. This has the
>>>>>>>> effect
>>>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>>>
>>>>>>>> The following three classes inherited from _ValueObj even though
>>>>>>>> they
>>>>>>>> made use of either the new or delete operator:
>>>>>>>> - RegMask:
>>>>>>>> The functions Node::out_regMask and Node::in_regMask are 
>>>>>>>> defined as:
>>>>>>>> void RegMask &Node::out_regMask() const {
>>>>>>>> ShouldNotCallThis();
>>>>>>>> return *(new RegMask());
>>>>>>>> }
>>>>>>>> Both out_regMask and in_regMask are overridden by subclasses and
>>>>>>>> they
>>>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>>>> object is allocated with new. There are two solutions to this
>>>>>>>> problem:
>>>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC
>>>>>>>> for
>>>>>>>> RegMask
>>>>>>>> This CR presents a work around to the problem instead of removing
>>>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>>>
>>>>>>>> - MemBaseLine
>>>>>>>> MemBaseLine has a virtual destructor which is not possible 
>>>>>>>> together
>>>>>>>> with a private delete operator. Once again, the 
>>>>>>>> VALUE_OBJ_CLASS_SPEC
>>>>>>>> can be removed, but I chose to make the destructor non-virtual 
>>>>>>>> since
>>>>>>>> no class currently inherits from MemBaseline.
>>>>>>>>
>>>>>>>> - AbstractGangTask
>>>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>>>> defines a virtual destructor in C++ must also have a (working)
>>>>>>>> delete
>>>>>>>> operator in scope. The current delete operator is not working (it
>>>>>>>> only
>>>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>>>
>>>>>>>> How could this work before? I haven't checked that thoroughly, 
>>>>>>>> but I
>>>>>>>> believe that no code calls delete on an AbstractGangTask 
>>>>>>>> pointer. If
>>>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>>>
>>>>>>>> This change also changes the new and delete operations of 
>>>>>>>> "StackObj"
>>>>>>>> to be private (for the same reasons). This did not cause 
>>>>>>>> changes in
>>>>>>>> any
>>>>>>>> other code.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> JPRT
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Erik
>>>>>>
>>>>
>>
>


From erik.helin at oracle.com  Mon Dec 17 05:44:24 2012
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 17 Dec 2012 14:44:24 +0100
Subject: RFR (S): 8004845: Catch incorrect usage of new and delete during
	compile time for value objects and stack objects
In-Reply-To: <50CF20B5.3040806@oracle.com>
References: <50C84FC1.90308@oracle.com> <50C85614.2000900@oracle.com>
	<50C8597F.3060309@oracle.com> <50C86191.7050702@oracle.com>
	<50C882FF.2000006@oracle.com> <50C932EC.9010106@oracle.com>
	<50C94841.9090100@oracle.com> <50CAC273.5030501@oracle.com>
	<50CF20B5.3040806@oracle.com>
Message-ID: <50CF21B8.6050302@oracle.com>

Thanks!

Erik

On 12/17/2012 02:40 PM, Coleen Phillimore wrote:
>
> This looks good, thank you for making this change.
> Coleen
>
> On 12/14/2012 1:08 AM, Erik Helin wrote:
>> Coleen,
>>
>> On 12/13/2012 04:15 AM, Coleen Phillimore wrote:
>>> I think this looks reasonable, although someone from GC should comment
>>> on the AbstractGangTask's real allocation type.
>>
>> what do you think of the latest webrev (which keeps the allocation
>> type for AbstractGangTask):
>>
>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.01/
>>
>> This webrev keeps VALUE_OBJ_CLASS_SPEC and instead makes the
>> destructor for the classes AbstractGangTask and
>> YieldingFlexibleGangTask non-virtual.
>>
>> This was changed because I got some great feedback from David:
>>
>> On 12/13/2012 05:51 AM, David Holmes wrote:
>> > But given that operator delete can NOT be called on these classes you
>> > can NOT need a virtual destructor. QED. Hence the correct fixes for
>> > MemBaseline and AbstractGangtask (and subclasses) would be to remove
>> the
>> > "virtual" from the destructor.
>>
>> Thanks,
>> Erik
>>
>>> Thanks,
>>> Coleen
>>>
>>> On 12/12/2012 8:44 PM, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>> On 12/12/2012 11:13 PM, Erik Helin wrote:
>>>>> On 12/12/2012 11:50 AM, David Holmes wrote:
>>>>>>> class A {
>>>>>>> private:
>>>>>>> void operator delete(void *) { }
>>>>>>> };
>>>>>>>
>>>>>>> class B : public A {
>>>>>>> public:
>>>>>>> B() { }
>>>>>>> virtual ~B() { }
>>>>>>> };
>>>>>>>
>>>>>>> > g++ -c foo.cpp
>>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>> foo.cpp: In destructor ?virtual B::~B()?:
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>> foo.cpp:3:10: error: ?static void A::operator delete(void*)? is
>>>>>>> private
>>>>>>> foo.cpp:9:18: error: within this context
>>>>>>
>>>>>> Okay that kind of makes sense. I was thinking more about them
>>>>>> being in
>>>>>> the same class.
>>>>>>
>>>>>> But this just says to me "don't make new/delete private". (Think of
>>>>>> them
>>>>>> like virtual methods on Object - you can redefine them but they are
>>>>>> always public ;-) )
>>>>>
>>>>> I believe that the benefit of making new/delete private is that we get
>>>>> compile time checking instead of maybe finding out via tests in
>>>>> JPRT (if
>>>>> the tests does not traverse a code path with incorrect usage, then we
>>>>> won't find it).
>>>>
>>>> Agreed - but that is at odds with the use of the virtual destructor
>>>> ... I also have to wonder why that wasn't done in the first place as
>>>> it seems an "obvious" way to ensure they don't get called.
>>>>
>>>>> In my opinion, if a class has a virtual destructor and inherits from
>>>>> _ValueObj or StackObj, then either the destructor shouldn't be virtual
>>>>> or the class should not inherit from _ValueObj or StackObj.
>>>>
>>>> I don't think these have to be mutually exclusive in a general sense.
>>>> But it may be we don't need both capabilities in the current cases.
>>>>
>>>>> As far as I can see, the only use for a _virtual_ destructor in a
>>>>> class
>>>>> is if you want to delete a pointer to that class (and make sure
>>>>> that the
>>>>> destructor of any class inheriting from that class also gets called).
>>>>
>>>> Yes. If at any time you are likely to invoke delete on a derived class
>>>> instance through a base class pointer then you want there to be a
>>>> virtual destructor. Lippman's general rule of thumb (C++ Primer 3rd
>>>> edition Section 17.5.5) is that any base class with any virtual
>>>> functions should also have a virtual destructor.
>>>>
>>>> I've had to fix a number of bugs in certain variants of hotspot caused
>>>> by lack of a virtual destructor. And I doubt that the current codebase
>>>> is particularly "clean" in this regard.
>>>>
>>>>>  From what I understand, deriving from _ValueObj or StackObj means
>>>>> that
>>>>> you don't expect this to happen.
>>>>>
>>>>> What do you think of this?
>>>>
>>>> I'm not versed enough in the use of all the different types that
>>>> derive from ValueObj and StackObj to answer that definitively. It
>>>> seems likely to be true to me - particularly for StackObj. But can we
>>>> say it is never needed?
>>>>
>>>> Given these classes must derive from one of the allocation types, the
>>>> only option is to remove the virtual from the destructor, so at a
>>>> minimum you have to establish for these types that a virtual
>>>> destructor will never be needed.
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>
>>>>> Thanks for taking your time,
>>>>> Erik
>>>>>
>>>>>> David
>>>>>>
>>>>>>> Thanks,
>>>>>>> Erik
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 12/12/2012 7:34 PM, Erik Helin wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> the webrev is located at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~ehelin/8004845/webrev.00/
>>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> When I browsed the code during a code review, I noticed the macro
>>>>>>>>> VALUE_OBJ_CLASS_SPEC which is defined as ": public _ValueObj"
>>>>>>>>> and is
>>>>>>>>> used to describe that all instances of a given C++ class can
>>>>>>>>> never be
>>>>>>>>> placed on (or removed from) the heap with the operations new or
>>>>>>>>> delete.
>>>>>>>>>
>>>>>>>>> This is enforced by the class _ValueObj which implements the
>>>>>>>>> operators
>>>>>>>>> new and delete by calling ShouldNotCallThis which will crash
>>>>>>>>> the VM.
>>>>>>>>>
>>>>>>>>> The operators new and delete in _ValueObj are declared public
>>>>>>>>> and this change instead declares them as private. This has the
>>>>>>>>> effect
>>>>>>>>> of enforcing the above described restrictions at compile time.
>>>>>>>>>
>>>>>>>>> The following three classes inherited from _ValueObj even though
>>>>>>>>> they
>>>>>>>>> made use of either the new or delete operator:
>>>>>>>>> - RegMask:
>>>>>>>>> The functions Node::out_regMask and Node::in_regMask are
>>>>>>>>> defined as:
>>>>>>>>> void RegMask &Node::out_regMask() const {
>>>>>>>>> ShouldNotCallThis();
>>>>>>>>> return *(new RegMask());
>>>>>>>>> }
>>>>>>>>> Both out_regMask and in_regMask are overridden by subclasses and
>>>>>>>>> they
>>>>>>>>> are not meant to be called on a Node object (as can be seen by the
>>>>>>>>> call ShouldNotCallThis). This is the only place where a RegMask
>>>>>>>>> object is allocated with new. There are two solutions to this
>>>>>>>>> problem:
>>>>>>>>> - Removed the VALUE_OBJ_CLASS_SPEC for RegMask
>>>>>>>>> - Implement a work around to be able to keep VALUE_OBJ_CLASS_SPEC
>>>>>>>>> for
>>>>>>>>> RegMask
>>>>>>>>> This CR presents a work around to the problem instead of removing
>>>>>>>>> VALUE_OBJ_CLASS_SPEC.
>>>>>>>>>
>>>>>>>>> - MemBaseLine
>>>>>>>>> MemBaseLine has a virtual destructor which is not possible
>>>>>>>>> together
>>>>>>>>> with a private delete operator. Once again, the
>>>>>>>>> VALUE_OBJ_CLASS_SPEC
>>>>>>>>> can be removed, but I chose to make the destructor non-virtual
>>>>>>>>> since
>>>>>>>>> no class currently inherits from MemBaseline.
>>>>>>>>>
>>>>>>>>> - AbstractGangTask
>>>>>>>>> AbstactGangTask has a virtual destructor _and_ there are classes
>>>>>>>>> inheriting from AbstractGangTask. The problem is that a class that
>>>>>>>>> defines a virtual destructor in C++ must also have a (working)
>>>>>>>>> delete
>>>>>>>>> operator in scope. The current delete operator is not working (it
>>>>>>>>> only
>>>>>>>>> calls ShouldNotReachHere), therefore my suggestion is to remove
>>>>>>>>> VALUE_OBJ_CLASS_SPEC from AbstractGangTask.
>>>>>>>>>
>>>>>>>>> How could this work before? I haven't checked that thoroughly,
>>>>>>>>> but I
>>>>>>>>> believe that no code calls delete on an AbstractGangTask
>>>>>>>>> pointer. If
>>>>>>>>> this is true, then the destructor in AbstractGangTask could be
>>>>>>>>> declared non-virtual, but I don't want to take that risk.
>>>>>>>>>
>>>>>>>>> This change also changes the new and delete operations of
>>>>>>>>> "StackObj"
>>>>>>>>> to be private (for the same reasons). This did not cause
>>>>>>>>> changes in
>>>>>>>>> any
>>>>>>>>> other code.
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> JPRT
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Erik
>>>>>>>
>>>>>
>>>
>>
>


From vladimir.danushevsky at oracle.com  Mon Dec 17 06:33:00 2012
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Mon, 17 Dec 2012 09:33:00 -0500
Subject: RFR: 8004051: ARM: assert(_oprs_len[mode] < maxNumberOfOperands)
	failed: array overflow
Message-ID: <B2FD1CD2-3100-4BC0-BF36-B91CB3CB1ACD@oracle.com>

Hi,

An updated ARM Linux port Java calling convention increases number of  
possible register based arguments up to 20 (up to 4 integer args + up  
to 16 float args).
Several issues are observed in product builds while the debug build  
fails with an assert as described in the JIRA issue below:
https://jbs.oracle.com/bugs/browse/JDK-8004051

The proposed change increases limit of register based arguments to 20  
across all platforms (the runtime memory space waste is small).

http://cr.openjdk.java.net/~vladidan/8004051/webrev.00

The change will be applied to both JDK7u12 and JDK8.

Thanks,
Vlad

From joel.franck at oracle.com  Mon Dec 17 08:47:53 2012
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Mon, 17 Dec 2012 17:47:53 +0100
Subject: RFR: 8004823: Add VM support for type annotation reflection
Message-ID: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>

Hi,

Here is a webrev for adding VM support for type annotation reflection: http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/

Type annotations are coming with JDK 8, the proposed language changes can be found from here: http://openjdk.java.net/projects/type-annotations/

Since runtime visible type annotations probably won't  be that common I have tried to minimise overhead when there are no type annotations. This is done by adding a pointer to a type annotation Annotations instance from the regular annotations Annotations instance, see annotations.hpp. This means that if there are no runtime visible annotations there is no additional overhead with this patch since no Annotations instance will be allocated at all. If there is runtime visible annotations but no runtime visible type annotations there is an additional overhead of 1 pointer with this patch. If you use type annotations there will also be storage overhead, but that is to be expected.

This patch also fixes  that Annotations were never deallocated when InstanceKlass::deallocate_contents() were called.

There is currently no redefineClass support for type annotations. This will be added later. In order avoid ship possibly broken bytes to java-land, type annotations are nulled out and deallocated after a redefineClass.

This patch also exports a new method from jvm.h, JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are included for review.

Testing done:
- vm.quick.testlis both on b67 and on a jdk that is patched with the new fields to Field, Method and Constructor
- jprt full forrest build
- jdk_lang in both b67 and the patched jdk
- manual tests that we get the correct bytes out from the VM. These tests can be added once some more changes have propagated from the jdk repo

FYI, The initial set of jdk changes are being reviewed on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html

cheers
/Joel

From christian.thalinger at oracle.com  Mon Dec 17 12:12:15 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 17 Dec 2012 12:12:15 -0800
Subject: adding a new ISA
In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7329CC9BB@sausexdag06.amd.com>
References: <5DD1503F815BD14889DC81D28643E3A7329CC9BB@sausexdag06.amd.com>
Message-ID: <4D483F35-B2D5-4723-8719-520DFC096D5F@oracle.com>


On Dec 14, 2012, at 2:08 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> Apologies for the cross-posting, but I thought this would get a wider audience on hotspot-dev...
> 
> Modifying the JVM to support a new ISA (such as the GPU) would require extensive changes.
> I was wondering what people's thoughts were on the following:
> 
> 
> 1)      What guidelines do people use for deciding which components of the JVM to start modifying or writing code for? It seems like a good guideline would be to start with the changes that are the most straightforward, such as register definitions or the assembler. Do people have other ideas?

Since we knew for some time now that new architectures will be coming to the JVM I decided to go ahead a do something I wanted to do for a long time.

Current HotSpot AD files don't describe the ISA at all.  So the Assembler for an architecture has to be written by hand.  I always wanted to have some sort of AD file that describes the ISA as well and which can be used to generate various things:  Assembler, format printing methods for existing AD files (format %{ %} directive; PrintOptoAssembly), and disassembler (possibly).

Since our only open-source RISC architecture right now is SPARC I started to write such a new AD file for SPARC as a first step and example others can build on.  The work is almost done; it's just a lot of testing.

I tried to design the ISA description to be simple and readable.  The goal was that you can take an instruction set manual and "copy" the contents into a file.

Here is an example of an instruction description (SPARC register add):

add(rs1, rs2, rd)  { fmt { "ADD" rs1 "," rs2 "," rd }  enc { 0b10 | rd:5 | 0b000000 | rs1:5 | 0b0 | 0b00000000 | rs2:5 } }

fmt will be used to generate format printing methods.  enc is the bit encoding of the instruction.  Operands are defined in a separate section.

There are only a couple of instructions left to be converted on SPARC so I should have something soon for review.

-- Chris

P.S.:  It would be great if the ARM64 port from RedHat could already use that tool.  Let me know if/how I can help.

> 
> 2)      How do people incrementally test components that depend upon the rest of the software which isn't in place yet? For example, if you update the register allocator and nothing else, how would you test this change without having the rest of the JVM in place?
> 
> Vasanth
> 
> --
> Vasanth Venkatachalam
> AMD Runtimes
> (512)602-6177
> 


From zhengyu.gu at oracle.com  Mon Dec 17 12:11:31 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 17 Dec 2012 15:11:31 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to just
	show the # defined classes
Message-ID: <50CF7C73.7010608@oracle.com>

Current NMT implementation reports number of loaded classes at query 
time, but number of defined classes is what is expected.

This changset reflects two major changes:

1. It counts number of defined classes vs. number of loaded classes
2. It counts number of defined classes for each generation, vs. counts 
at query time. In this way, the number of defined classes that NMT 
reports, should match the corresponding class metadata data. As the 
result, the data should be more accurate.


Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/


Thanks,

-Zhengyu

From coleen.phillimore at oracle.com  Mon Dec 17 12:53:56 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 17 Dec 2012 15:53:56 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50CF7C73.7010608@oracle.com>
References: <50CF7C73.7010608@oracle.com>
Message-ID: <50CF8664.5040001@oracle.com>


Zhengyu,
This looks good.  I have a couple of comments:

http://cr.openjdk.java.net/~zgu/8005048/webrev.00/src/share/vm/services/memTrackWorker.cpp.udiff.html

Looks like number_of_classes is still a 'long' in the declaration of the 
function at_sync_point() instead of jint.

instanceKlass.*

I think the number of classes might be generally useful and not using 
lots of space in code or footprint, so I don't think it is worth having 
it conditionalized with INCLUDE_NMT.

Thanks,
Coleen


On 12/17/2012 03:11 PM, Zhengyu Gu wrote:
> Current NMT implementation reports number of loaded classes at query 
> time, but number of defined classes is what is expected.
>
> This changset reflects two major changes:
>
> 1. It counts number of defined classes vs. number of loaded classes
> 2. It counts number of defined classes for each generation, vs. counts 
> at query time. In this way, the number of defined classes that NMT 
> reports, should match the corresponding class metadata data. As the 
> result, the data should be more accurate.
>
>
> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>
>
> Thanks,
>
> -Zhengyu


From zhengyu.gu at oracle.com  Mon Dec 17 13:33:46 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 17 Dec 2012 16:33:46 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50CF8664.5040001@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CF8664.5040001@oracle.com>
Message-ID: <50CF8FBA.9090606@oracle.com>

Thanks for review.

On 12/17/2012 3:53 PM, Coleen Phillimore wrote:
>
> Zhengyu,
> This looks good.  I have a couple of comments:
>
> http://cr.openjdk.java.net/~zgu/8005048/webrev.00/src/share/vm/services/memTrackWorker.cpp.udiff.html 
>
>
> Looks like number_of_classes is still a 'long' in the declaration of 
> the function at_sync_point() instead of jint.
>
Yes, I missed here and a few other places. I will change them to "int"

> instanceKlass.*
>
> I think the number of classes might be generally useful and not using 
> lots of space in code or footprint, so I don't think it is worth 
> having it conditionalized with INCLUDE_NMT.
>
I will consult embedded team on this.

Thanks,

-Zhengyu

> Thanks,
> Coleen
>
>
> On 12/17/2012 03:11 PM, Zhengyu Gu wrote:
>> Current NMT implementation reports number of loaded classes at query 
>> time, but number of defined classes is what is expected.
>>
>> This changset reflects two major changes:
>>
>> 1. It counts number of defined classes vs. number of loaded classes
>> 2. It counts number of defined classes for each generation, vs. 
>> counts at query time. In this way, the number of defined classes that 
>> NMT reports, should match the corresponding class metadata data. As 
>> the result, the data should be more accurate.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>
>>
>> Thanks,
>>
>> -Zhengyu
>

From coleen.phillimore at oracle.com  Mon Dec 17 13:40:17 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 17 Dec 2012 16:40:17 -0500
Subject: The magic of self-patching vtable
In-Reply-To: <50CBA855.4050201@oracle.com>
References: <50CAC46C.6020408@oracle.com> <50CB239E.9050705@oracle.com>
	<50CB901D.8000406@oracle.com> <50CB926C.9060504@oracle.com>
	<13F69A76-5D17-414F-865E-A25AF54150FB@oracle.com>
	<50CBA262.5010806@oracle.com> <50CBA3B9.4070101@oracle.com>
	<50CBA855.4050201@oracle.com>
Message-ID: <50CF9141.1000404@oracle.com>


On 12/14/2012 05:29 PM, Ioi Lam wrote:
> On 12/14/2012 02:10 PM, Coleen Phillimore wrote:
>> On 12/14/2012 5:04 PM, Ioi Lam wrote:
>>> Moving this discussion to hotspot-dev per John's suggestion.
>>>
>>> Actually, strictly from the point of view of CDS, it would be OK for 
>>> objects in the RO region to have vtables. This is because the _vptr 
>>> is fixed during dump time, and never modified during runtime.
>>>
>>> Only the contents of the vtables (pointed to by _vptr) are updated 
>>> at CDS image load time.
>>
>> The way it works today is that the _vptr in the object is replaced, 
>> so you'd have to change that.
>>
>> Coleen
>>
>
> Hi Coleen,
>
> As far as I can see in today's code, _vptr is replaced here 
> (metaspaceShared.cpp, version 3823:070d523b96a7), which is called at 
> dumping time. During dumping time, the "RO" section is actually writable.

Yes, you are correct.   When you run Java during dumping time, the RO 
section is writable.   When Java runs again with -XX:+UseSharedSpaces 
(-Xshare:auto which means "use the shared region if possible"), the 
regions are mmap'ed back again, and the RO section is mapped 
read-only.   See
MetaspaceShared::map_shared_spaces() in metaspaceShared.cpp.

This comment is trying to document an issue I ran into while working on 
this.  I had an oop_is_instance() call after the self-patching vtables 
were installed in the dumping phase, which nicely restored the original 
vtable for me.   Then when rerunning with UseSharedSpaces, the vtable 
pointed to some text from a terminated process.

Your original idea of generating these vtables without machine dependent 
code sounded really good.

Thanks,
Coleen

>
> // Assumes the vtable is in first slot in object.
> static void patch_klass_vtables(void** vtbl_list, void* 
> new_vtable_start) {
>   int n = _global_klass_objects->length();
>   for (int i = 0; i < n; i++) {
>     Klass* obj = _global_klass_objects->at(i);
>     // Note oop_is_instance() is a virtual call.  After patching vtables
>     // all virtual calls on the dummy vtables will restore the original!
>     if (obj->oop_is_instance()) {
>       InstanceKlass* ik = InstanceKlass::cast(obj);
>       *(void**)ik = find_matching_vtbl_ptr(vtbl_list, 
> new_vtable_start, ik);
>       ConstantPool* cp = ik->constants();
>       *(void**)cp = find_matching_vtbl_ptr(vtbl_list, 
> new_vtable_start, cp);
>       for (int j = 0; j < ik->methods()->length(); j++) {
>         Method* m = ik->methods()->at(j);
>         *(void**)m = find_matching_vtbl_ptr(vtbl_list, 
> new_vtable_start, m);
>       }
>     } else {
>       // Array klasses
>       Klass* k = obj;
>       *(void**)k = find_matching_vtbl_ptr(vtbl_list, new_vtable_start, 
> k);
>     }
>   }
> }
>
> - Ioi
>
>>>
>>> - Ioi
>>>
>>>
>>> On 12/14/2012 01:31 PM, John Rose wrote:
>>>> This is really interesting.
>>>>
>>>> I'll bet there could be a shell script that could detect and flag 
>>>> unintentional vtables on RO classes, at least on Linux or Solaris. 
>>>> That would be enough to block JPRT submissions.
>>>>
>>>> -- John
>>>>
>>>> On Dec 14, 2012, at 12:56 PM, Coleen Phillimore 
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>> On 12/14/2012 3:46 PM, Ioi Lam wrote:
>>>>>> Hi Coleen,
>>>>>>
>>>>>> Yes, I could find lots comments for 'how' the self-patching 
>>>>>> vtable works. I just couldn't find a justification for 'why' it 
>>>>>> needs to be done this way.
>>>>>>
>>>>>> The _vptr of all the Metadata objects in the CDS image are 
>>>>>> already fixed during dump time. They are never changed at 
>>>>>> run-time. I.e., immediately after the CDS image is loaded, we 
>>>>>> have this invariant:
>>>>>>
>>>>>> Universe::boolArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>>>> Universe::byteArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>>>> Universe::charArrayKlassObj()->_vptr == cds_TypeArrayKlass_vtable
>>>>>> ...
>>>>>>
>>>>>> where
>>>>>>
>>>>>> cds_TypeArrayKlass_vtable points to somewhere slightly above the 
>>>>>> "md" region of the mapped CDS image.
>>>>>>
>>>>>> If we can find out the size of the vtable for TypeArrayKlass, 
>>>>>> using the method I proposed below, why can't we simply do this as 
>>>>>> part of CDS image loading?
>>>>>>
>>>>>> {
>>>>>>     TypeArrayKlass o;
>>>>>>     void * real_vptr = *(void**)(&o);// == o._vptr;
>>>>>>     memcpy(cds_TypeArrayKlass_vtable, real_vptr, sizeof(void*) * 
>>>>>> num_vtable_slots_TypeArrayKlass);
>>>>>> }
>>>>> Yeah, that would be good except I can't figure out how that works, 
>>>>> but I'll take your word for it rather than trying to work it out 
>>>>> right now.
>>>>>
>>>>> You'd do this restoration in the function 
>>>>> restore_unshareable_info() instead of loading (lazily) though.
>>>>>
>>>>> Coleen
>>>>>
>>>>>> Thanks
>>>>>> - Ioi
>>>>>>
>>>>>> On 12/14/2012 05:03 AM, Coleen Phillimore wrote:
>>>>>>> Hi Ioi,
>>>>>>>
>>>>>>> There are comments about self-patching vtables in 
>>>>>>> memory/universe.cpp and memory/metaspaceShared.cpp and the 
>>>>>>> target dependent metaspaceShared_<cpu>.cpp code. You have 
>>>>>>> summarized how/why it works quite nicely.     The main reason 
>>>>>>> for vtable patching is that the .text is in different places for 
>>>>>>> the executables which load the shared archive, so we have this 
>>>>>>> code to fix it up in the miscellaneous code section.
>>>>>>>
>>>>>>> The other thing you might have left off which people should be 
>>>>>>> very aware of is that metadata that is shared read-only, like 
>>>>>>> classes ConstMethod, Array<alltypes>, and Symbols. Adding 
>>>>>>> virtual function calls to these will result in them having a 
>>>>>>> self-patching vtable and they will no longer be read only.    Do 
>>>>>>> not add virtual functions to these types! I hope there are 
>>>>>>> enough comments warning of this.   I cannot think of a 
>>>>>>> programmatic way to disallow this.
>>>>>>>
>>>>>>> I have another comment for your [5]-[6] below.   The cpu 
>>>>>>> dependent code is to create the self patching entries per 
>>>>>>> platform.  We can't tell how long the vtable is so picked 200 
>>>>>>> for historical purposes.   But we still need the cpu dependent 
>>>>>>> code because we still need vtable patching because of point [2] 
>>>>>>> and it's done with macro assembler. If the macro assembler was 
>>>>>>> made to be a high level macro assembler, we wouldn't need cpu 
>>>>>>> dependent code. Knowing in advance the size of the vtable would 
>>>>>>> save the hard-coded constant, but that's not really a big benefit.
>>>>>>>
>>>>>>> An aside why 200 was picked.  In the pre-permgen world, the 
>>>>>>> metadata in the shared space were Java objects and were 
>>>>>>> inherited from oopDesc.   Any new virtual function added for GC 
>>>>>>> in oopDesc would regularly blow out the length of the vtable 
>>>>>>> size. This isn't the case anymore since the base class for these 
>>>>>>> types is Metadata and there aren't very many virtual functions 
>>>>>>> there.   The type Klass* has a lot more, but still way under 
>>>>>>> 200.   A sanity check in debug mode might be useful.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 12/14/2012 1:17 AM, Ioi Lam wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am reading the CDS code and came upon the rather intriguing 
>>>>>>>> concept of "self patching vtables" -- i.e., 
>>>>>>>> patch_klass_vtables() and friends in 
>>>>>>>> hotspot/src/share/vm/memory/metaspaceShared.cpp.
>>>>>>>>
>>>>>>>> I couldn't find any comments in the source code for the reasons 
>>>>>>>> for such a complicated mechanism. Here's my understanding of 
>>>>>>>> it. Please let me know if this is correct:
>>>>>>>>
>>>>>>>> [1] Objects of the Metadata types (such as Klass and 
>>>>>>>> ConstantPool) have vtables.
>>>>>>>>     In GCC this is the field <Type>::_vptr, i.e., first word in
>>>>>>>>     the object.
>>>>>>>>
>>>>>>>> [2] Addresses of the vtables and the methods may be different 
>>>>>>>> across JVM runs,
>>>>>>>>     if libjvm.so is loaded at a different base address.
>>>>>>>>
>>>>>>>> [3] Although all of the Metadata objects are mapped R/W in the 
>>>>>>>> CDS image,
>>>>>>>>     at load time, we don't want to rewrite _vptr of each 
>>>>>>>> Metadata object
>>>>>>>>     (to maximize sharing).
>>>>>>>>
>>>>>>>> [4] Therefore, we redirect _vptr to our own vtables at CDS 
>>>>>>>> image dump time.
>>>>>>>>     Then,we patch our own vtables at run time.
>>>>>>>>
>>>>>>>> [5] The problem with [4] is with most C++ compilers (all?), 
>>>>>>>> there is no
>>>>>>>>     easy way to tell the size of the vtable of a given type.
>>>>>>>>
>>>>>>>> [6] We cannot safely copy more than the size of the real 
>>>>>>>> vtable, because the
>>>>>>>>     real vtable may be at the end of the code section; reading 
>>>>>>>> past its end
>>>>>>>>     would cause the VM to crash.
>>>>>>>>
>>>>>>>> As a result, the current design of the 'self patching vtable' 
>>>>>>>> is to
>>>>>>>> create a vtable that's "big enough" (currently with 200 method 
>>>>>>>> slots).
>>>>>>>> Each slot points to a generated stub that knows the C++ type and
>>>>>>>> virtual method index of the invoked method. When the stub is 
>>>>>>>> invoked,
>>>>>>>> it will look up the real method and patch the vtable accordingly.
>>>>>>>>
>>>>>>>> -----
>>>>>>>>
>>>>>>>> If I am right that the whole reason for the self patching 
>>>>>>>> vtables is getting the length of the vtable, wouldn't it be 
>>>>>>>> much easier if we do:
>>>>>>>>
>>>>>>>> class InstanceKlassVTableLengthFinder: public InstanceKlass {
>>>>>>>> public:
>>>>>>>>     virtual void ___end_of_vtable_marker();
>>>>>>>> };
>>>>>>>>
>>>>>>>> and then just search for ___end_of_vtable_marker() from the _vptr?
>>>>>>>>
>>>>>>>> That way we can get rid of all the CPU dependent code related 
>>>>>>>> to self-patching vtables.
>>>>>>>>
>>>>>>>> - Ioi
>>>
>>
>


From david.holmes at oracle.com  Mon Dec 17 16:23:36 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Dec 2012 10:23:36 +1000
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
Message-ID: <50CFB788.7080106@oracle.com>

Hi Goetz,

On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> Once more, with webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/

I can see that this function needs a storestore barrier:

  237   void set_empty() {
  238     _bottom = 0;
  239     _age.set(0);
  240   }

to preserve ordering. Are there other functions to which we can 
constrain the loadload and storestore barriers rather than using the 
setters/getters the way you have defined? This is always about a pair 
(sometimes groups) of accesses so I'd rather deal with the pairs than 
treat each field as if it were a Java volatile.

Thanks,
David Holmes


> Sorry for that.
>
> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>
> On Platfoms with weak memory ordering the taskqueue is not accessed
> properly, as the accesses to the fields _bottom and _age are not ordered
> correctly. Volatile is not sufficient to enforce this, because it depends on
> what the compiler assumes to be necessary for volatile variables.
>
> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
> use the getter/setter methods to access _bottom, _age or the subfields of _age.
> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>
> The OrderAccess routines do simple load/stores on x86_64.
>
> I want to discuss this change here and would like very much to see it taking
> it's way into OpenJDK to support ports on platforms with weak memory
> ordering, and, in particular, our PPC port.
>
> Best regards,
>    Goetz.
>
>

From vitalyd at gmail.com  Mon Dec 17 16:24:45 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 17 Dec 2012 19:24:45 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50CF7C73.7010608@oracle.com>
References: <50CF7C73.7010608@oracle.com>
Message-ID: <CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>

Hi Zhengyu,

In GenerationData::reset() you delete _recorder_list.  Since this list is
built from callers (I.e. caller adds recorders) is it good to delete the
head here? I guess this class takes ownership of added recorders? If so,
who deletes the rest of the recorders in the list? I'd expect to see a loop
here deleting all recorders in the list.

Thanks

Sent from my phone
On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com> wrote:

> Current NMT implementation reports number of loaded classes at query time,
> but number of defined classes is what is expected.
>
> This changset reflects two major changes:
>
> 1. It counts number of defined classes vs. number of loaded classes
> 2. It counts number of defined classes for each generation, vs. counts at
> query time. In this way, the number of defined classes that NMT reports,
> should match the corresponding class metadata data. As the result, the data
> should be more accurate.
>
>
> Webrev: http://cr.openjdk.java.net/~**zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>
>
>
> Thanks,
>
> -Zhengyu
>

From david.holmes at oracle.com  Mon Dec 17 18:22:09 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Dec 2012 12:22:09 +1000
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
Message-ID: <50CFD351.5090700@oracle.com>

Hi Joel,

This all looks fine to me. I have no comments. Didn't even see any nits 
to pick. :)

Thanks,
David

On 18/12/2012 2:47 AM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Here is a webrev for adding VM support for type annotation reflection: http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>
> Type annotations are coming with JDK 8, the proposed language changes can be found from here: http://openjdk.java.net/projects/type-annotations/
>
> Since runtime visible type annotations probably won't  be that common I have tried to minimise overhead when there are no type annotations. This is done by adding a pointer to a type annotation Annotations instance from the regular annotations Annotations instance, see annotations.hpp. This means that if there are no runtime visible annotations there is no additional overhead with this patch since no Annotations instance will be allocated at all. If there is runtime visible annotations but no runtime visible type annotations there is an additional overhead of 1 pointer with this patch. If you use type annotations there will also be storage overhead, but that is to be expected.
>
> This patch also fixes  that Annotations were never deallocated when InstanceKlass::deallocate_contents() were called.
>
> There is currently no redefineClass support for type annotations. This will be added later. In order avoid ship possibly broken bytes to java-land, type annotations are nulled out and deallocated after a redefineClass.
>
> This patch also exports a new method from jvm.h, JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are included for review.
>
> Testing done:
> - vm.quick.testlis both on b67 and on a jdk that is patched with the new fields to Field, Method and Constructor
> - jprt full forrest build
> - jdk_lang in both b67 and the patched jdk
> - manual tests that we get the correct bytes out from the VM. These tests can be added once some more changes have propagated from the jdk repo
>
> FYI, The initial set of jdk changes are being reviewed on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html
>
> cheers
> /Joel

From david.holmes at oracle.com  Mon Dec 17 18:41:19 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Dec 2012 12:41:19 +1000
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50CF7C73.7010608@oracle.com>
References: <50CF7C73.7010608@oracle.com>
Message-ID: <50CFD7CF.1010408@oracle.com>

Hi Zhengyu,

On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
> Current NMT implementation reports number of loaded classes at query
> time, but number of defined classes is what is expected.
>
> This changset reflects two major changes:
>
> 1. It counts number of defined classes vs. number of loaded classes

Can you explain what the distinction is please? I don't know what a 
"defined class" is.

> 2. It counts number of defined classes for each generation, vs. counts
> at query time. In this way, the number of defined classes that NMT
> reports, should match the corresponding class metadata data. As the
> result, the data should be more accurate.
>
>
> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/

I think we could benefit from NMT_ONLY(x) macros to get rid of the 
one-line conditional blocks eg in instanceKlass.cpp

---

src/share/vm/oops/instanceKlass.hpp

+ #if INCLUDE_NMT
+   static int number_of_instance_classes() { return 
(int)_total_instanceKlass_count; }
+
+  private:
+   static volatile jint _total_instanceKlass_count;
+ #endif

Why are we mixing int and jint here?

---

I can't comment on the detailed memory management of the GenerationData.

David
-----


>
> Thanks,
>
> -Zhengyu

From bengt.rutisson at oracle.com  Mon Dec 17 23:09:24 2012
From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com)
Date: Tue, 18 Dec 2012 07:09:24 +0000
Subject: hg: hsx/hsx24/hotspot: 7173959: Jvm crashed during coherence exabus
	(tmb) testing
Message-ID: <20121218070929.7FD9247206@hg.openjdk.java.net>

Changeset: e1d9b04b560b
Author:    brutisso
Date:      2012-12-17 08:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e1d9b04b560b

7173959: Jvm crashed during coherence exabus (tmb) testing
Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com
Reviewed-by: dholmes, coleenp, zgu

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp


From joel.franck at oracle.com  Tue Dec 18 02:41:55 2012
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 18 Dec 2012 11:41:55 +0100
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
Message-ID: <50D04872.1040801@oracle.com>

Hi again,

I noticed that my editor replaced all tabs with spaces in 
make/bsd/makefiles/mapfile-vers-product

This was unintentional and I will fix this.

cheers
/Joel

On 12/17/2012 05:47 PM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Here is a webrev for adding VM support for type annotation reflection: http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>
> Type annotations are coming with JDK 8, the proposed language changes can be found from here: http://openjdk.java.net/projects/type-annotations/
>
> Since runtime visible type annotations probably won't  be that common I have tried to minimise overhead when there are no type annotations. This is done by adding a pointer to a type annotation Annotations instance from the regular annotations Annotations instance, see annotations.hpp. This means that if there are no runtime visible annotations there is no additional overhead with this patch since no Annotations instance will be allocated at all. If there is runtime visible annotations but no runtime visible type annotations there is an additional overhead of 1 pointer with this patch. If you use type annotations there will also be storage overhead, but that is to be expected.
>
> This patch also fixes  that Annotations were never deallocated when InstanceKlass::deallocate_contents() were called.
>
> There is currently no redefineClass support for type annotations. This will be added later. In order avoid ship possibly broken bytes to java-land, type annotations are nulled out and deallocated after a redefineClass.
>
> This patch also exports a new method from jvm.h, JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are included for review.
>
> Testing done:
> - vm.quick.testlis both on b67 and on a jdk that is patched with the new fields to Field, Method and Constructor
> - jprt full forrest build
> - jdk_lang in both b67 and the patched jdk
> - manual tests that we get the correct bytes out from the VM. These tests can be added once some more changes have propagated from the jdk repo
>
> FYI, The initial set of jdk changes are being reviewed on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html
>
> cheers
> /Joel
>

From goetz.lindenmaier at sap.com  Tue Dec 18 02:47:32 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 18 Dec 2012 11:47:32 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <50CFB788.7080106@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>

Hi David,

why do you think only these two accesses have to be ordered?

As I understand, any two accesses in one thread to these fields have to be 
orderered and must be written to memory to become visible in the proper order 
to other threads.  The PPC compiler really takes all advantages given by the 
C-Standard to optimize this, and the processor reorders heavily.

The specification of volatile in 
       Age get() const volatile { return _data; }
says that it must be read from memory, not that it can not be reordered.

Also, doing 
      OrderAccess::load_acquire((volatile idx_t*) &(_age._fields._top))
is better wrt. to optimizations by C-compilers, as there first 
is the whole address computation, and then the cast to volatile. 
If we use
      _age.top()
with 
      idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*) &(_fields._top); }
compilers don't optimize that well.  (We saw this on hpia64.)
Further, the access to, e.g., old_age.top() in pop_local_slow() would do 
the OrderAccess, which is useless overhead.

Best regards,
  Goetz.


-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 18. Dezember 2012 01:24
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): Memory ordering in taskqueue.hpp

Hi Goetz,

On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> Once more, with webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/

I can see that this function needs a storestore barrier:

  237   void set_empty() {
  238     _bottom = 0;
  239     _age.set(0);
  240   }

to preserve ordering. Are there other functions to which we can 
constrain the loadload and storestore barriers rather than using the 
setters/getters the way you have defined? This is always about a pair 
(sometimes groups) of accesses so I'd rather deal with the pairs than 
treat each field as if it were a Java volatile.

Thanks,
David Holmes


> Sorry for that.
>
> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>
> On Platfoms with weak memory ordering the taskqueue is not accessed
> properly, as the accesses to the fields _bottom and _age are not ordered
> correctly. Volatile is not sufficient to enforce this, because it depends on
> what the compiler assumes to be necessary for volatile variables.
>
> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
> use the getter/setter methods to access _bottom, _age or the subfields of _age.
> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>
> The OrderAccess routines do simple load/stores on x86_64.
>
> I want to discuss this change here and would like very much to see it taking
> it's way into OpenJDK to support ports on platforms with weak memory
> ordering, and, in particular, our PPC port.
>
> Best regards,
>    Goetz.
>
>

From neil.richards at ngmr.net  Tue Dec 18 02:50:05 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 18 Dec 2012 10:50:05 +0000
Subject: A JEP draft for documenting the Class Library/JVM interfaces
In-Reply-To: <CAOo=rxUN7ePnSrL7RZ3o8ssA7LgYBcKbaWpxP97QPgRjVRUCLg@mail.gmail.com>
References: <CAOo=rxUN7ePnSrL7RZ3o8ssA7LgYBcKbaWpxP97QPgRjVRUCLg@mail.gmail.com>
Message-ID: <1355827806.6578.9.camel@chalkhill>

I am cross-posting this to the hotspot-dev mailing list, as people there
may be interested in this proposed JEP.

Note that the proposal is to document the VM interfaces upon which the
class library relies in the /jdk repository (as opposed to documenting
the interfaces the Hotspot VM provides in the /hotspot repository, in
case there is any discrepancy between these two).

Feedback on this (to the cvmi-dev list, please) would be most welcome.

Regards,
Neil


On Wed, 2012-12-05 at 18:20 +0800, Sean Chou wrote:
> Hi all,
> 
> I'm working with Neil on the project of improving the documentation of
> Class Library/JVM interfaces [1]. We created a simple demo about what
> the documentation work would look like, as well we wrote a JEP draft
> based on the demo.
> 
> We hope to get enough comments and put it into JEP process before
> next Friday(Dec 14).
> 
> Here is the content of the draft(also in attachment):
> 
> 
> Title: Building documents for Class Library/JVM interfaces
> Author:
> Organization: IBM
> Owner:
> Created: 2012/12/01
> Type: Informational
> State: Draft
> Exposure: Open
> Component: core/libs, vm/--
> Discussion: cvmi dash dev at openjdk dot java dot net
> Start: 2013/Q1
> Effort: S
> Duration: S
> Template: 1.0
> Internal-refs:
> Reviewed-by:
> Endorsed-by:
> Funded-by:
> 
> 
> Summary
> -------
> 
> Enable the build infrastructure to build documents for Class Library/JVM
> interfaces
> 
> 
> Goals
> -----
> 
> 1. Enable the build infrastructure to generate documentation for Class
> Library/JVM
> interfaces.
> 2. Document the Class Library/JVM interfaces in a format supported by
> doxygen.
> 
> 
> Non-Goals
> ---------
> 
> This JEP does not cover creating additional documentation.
> 
> 
> Success Metrics
> ---------------
> 
> When docs of jdk is built, the document contains the Class Library/JVM
> interfaces.
> 
> 
> Motivation
> ----------
> 
> Besides JNI and JVMTI, the JVM still has a lot functions defined as
> library/JVM
> interfaces. Creating documentation for these functions can help class
> library
> develpers utilize the functions provided JVM. As well, it will help
> alternative JVM to use RI class library.
> 
> 
> Description
> -----------
> 
> This JEP is to add a build option to build the documents for Class
> Library/JVM
> interfaces. The exported JVM functions in jdk/src/share/javavm/export
> directories are used as the Class Library/JVM interfaces.
> 
> The JEP includes following changes:
> 1. Doxygen will be added as a build dependency.
> 2. The build scripted will be modified to include the option of building
> the document.
> 3. The comment format in library/JVM interfaces needs to be updated to
> doxygen format.
> 4. A doxygen configuration file will be added.
> 
> Here is an example what's the document and configuration file would look
> like.
> The built docs:
>     http://cr.openjdk.java.net/~zhouyx/cvmi/interface_doc/
> An example of commented function:
> 
> http://cr.openjdk.java.net/~zhouyx/cvmi/interface_doc/jvm_8h.html#a05f1ec06295884dbb7519ddcf20f0e56
>     http://cr.openjdk.java.net/~zhouyx/cvmi/comment_modi/
> The configuration file:
>     http://cr.openjdk.java.net/~zhouyx/cvmi/config_file/cvmi.conf
> 
> The configuration file quite long, but most of it is created by template;
> the modification is samll. Following is the template and modification.
>     http://cr.openjdk.java.net/~zhouyx/cvmi/config_file/template.conf
>     http://cr.openjdk.java.net/~zhouyx/cvmi/config_file/config.diff
> 
> 
> Alternatives
> ------------
> 
> Write additional specification to document the interface like JNI and
> JVMTI specification.
> 
> 
> Dependences
> -----------
> 
> It is needed to add doxygen to build dependency, and the library/JVM
> interfaces needs to be documented in doxgen supported format.
> 
> 
> Impact
> ------
> 
> The Class Library/JVM interface will get its documents while building.
> 
> 
> 
> 
> ///////// End
> 
> [1] http://mail.openjdk.java.net/pipermail/cvmi-dev/2012-May/000043.html
> 


-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From david.holmes at oracle.com  Tue Dec 18 03:18:42 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Dec 2012 21:18:42 +1000
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
Message-ID: <50D05112.70506@oracle.com>

Hi Goetz,

On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> why do you think only these two accesses have to be ordered?

I didn't say that. I said these two need to be ordered and asked which 
other paired accesses to these variables need to be ordered.

> As I understand, any two accesses in one thread to these fields have to be
> orderered and must be written to memory to become visible in the proper order
> to other threads.

That depends on how they are used. It is the overall lock-free algorithm 
that is important here. There may be places where the order of access 
does not matter (and there may not be).

> The PPC compiler really takes all advantages given by the
> C-Standard to optimize this, and the processor reorders heavily.

Yes I understand. Though we have not run into this particular issue. Did 
it arise in the context of a particular GC?

> The specification of volatile in
>         Age get() const volatile { return _data; }
> says that it must be read from memory, not that it can not be reordered.

I didn't say anything about C/C++ volatile (which doesn't even say it 
must be read from memory - except perhaps in latest MT C++ standard?). I 
said that what you were doing was effectively treating the C++ variables 
as if they were Java volatile variables. That's not the way we handle 
these issues in the VM we tend to place fences/barriers at the places in 
lock-free algorithms that need them, rather than wrap the variables in 
accessors that impose fences/barriers that are not always needed.

Cheers,
David

> Also, doing
>        OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
> is better wrt. to optimizations by C-compilers, as there first
> is the whole address computation, and then the cast to volatile.
> If we use
>        _age.top()
> with
>        idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
> compilers don't optimize that well.  (We saw this on hpia64.)
> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
> the OrderAccess, which is useless overhead.
>
> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 18. Dezember 2012 01:24
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> Hi Goetz,
>
> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> Once more, with webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>
> I can see that this function needs a storestore barrier:
>
>    237   void set_empty() {
>    238     _bottom = 0;
>    239     _age.set(0);
>    240   }
>
> to preserve ordering. Are there other functions to which we can
> constrain the loadload and storestore barriers rather than using the
> setters/getters the way you have defined? This is always about a pair
> (sometimes groups) of accesses so I'd rather deal with the pairs than
> treat each field as if it were a Java volatile.
>
> Thanks,
> David Holmes
>
>
>> Sorry for that.
>>
>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>
>> On Platfoms with weak memory ordering the taskqueue is not accessed
>> properly, as the accesses to the fields _bottom and _age are not ordered
>> correctly. Volatile is not sufficient to enforce this, because it depends on
>> what the compiler assumes to be necessary for volatile variables.
>>
>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
>> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
>> use the getter/setter methods to access _bottom, _age or the subfields of _age.
>> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>>
>> The OrderAccess routines do simple load/stores on x86_64.
>>
>> I want to discuss this change here and would like very much to see it taking
>> it's way into OpenJDK to support ports on platforms with weak memory
>> ordering, and, in particular, our PPC port.
>>
>> Best regards,
>>     Goetz.
>>
>>

From kevin.walls at oracle.com  Tue Dec 18 03:57:25 2012
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Tue, 18 Dec 2012 11:57:25 +0000
Subject: hg: hsx/hsx24/hotspot: 3 new changesets
Message-ID: <20121218115739.D9A8C47217@hg.openjdk.java.net>

Changeset: 72610d66a199
Author:    kevinw
Date:      2012-09-19 15:24 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/72610d66a199

7196045: Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
Reviewed-by: sspitsyn, dholmes

! src/share/vm/services/management.cpp
+ test/runtime/7196045/Test7196045.java

Changeset: 33ce1725aae9
Author:    kevinw
Date:      2012-09-30 23:24 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/33ce1725aae9

7200145: runtime/7196045/Test7196045.java fails with No class provided for `main'
Reviewed-by: dholmes, dsamersoff

! test/runtime/7196045/Test7196045.java

Changeset: 5ba336ab9b4b
Author:    kevinw
Date:      2012-12-18 02:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5ba336ab9b4b

Merge



From zhengyu.gu at oracle.com  Tue Dec 18 06:43:44 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 18 Dec 2012 09:43:44 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50CFD7CF.1010408@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
Message-ID: <50D08120.2020306@oracle.com>

Hi David,

Thanks for reviewing.

On 12/17/2012 9:41 PM, David Holmes wrote:
> Hi Zhengyu,
>
> On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>> Current NMT implementation reports number of loaded classes at query
>> time, but number of defined classes is what is expected.
>>
>> This changset reflects two major changes:
>>
>> 1. It counts number of defined classes vs. number of loaded classes
>
> Can you explain what the distinction is please? I don't know what a 
> "defined class" is.
>
"defined class" refers to class definition (InstanceKlass), "loaded 
class" refers to instance.

>> 2. It counts number of defined classes for each generation, vs. counts
>> at query time. In this way, the number of defined classes that NMT
>> reports, should match the corresponding class metadata data. As the
>> result, the data should be more accurate.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>
> I think we could benefit from NMT_ONLY(x) macros to get rid of the 
> one-line conditional blocks eg in instanceKlass.cpp
After consulting Chris Plummer, it does not have to exclude for 
embedded. But yes, have NMT_ONLY() macros will be very helpful, I will 
keep this in mind.

>
> ---
>
> src/share/vm/oops/instanceKlass.hpp
>
> + #if INCLUDE_NMT
> +   static int number_of_instance_classes() { return 
> (int)_total_instanceKlass_count; }
> +
> +  private:
> +   static volatile jint _total_instanceKlass_count;
> + #endif
>
> Why are we mixing int and jint here?
Yes, it is bad idea. Will change to "int"

Thanks,

-Zhengyu
>
> ---
>
> I can't comment on the detailed memory management of the GenerationData.
>
> David
> -----
>
>
>>
>> Thanks,
>>
>> -Zhengyu

From zhengyu.gu at oracle.com  Tue Dec 18 06:53:58 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 18 Dec 2012 09:53:58 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com>
	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>
Message-ID: <50D08386.6060200@oracle.com>

Hi Vitaly,

Thanks for reviewing.

On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>
> Hi Zhengyu,
>
> In GenerationData::reset() you delete _recorder_list.  Since this list 
> is built from callers (I.e. caller adds recorders) is it good to 
> delete the head here? I guess this class takes ownership of added 
> recorders?
>
Yes, releasing recorder via MemTracker::release_thread_recorder() is 
cleaner solution, I will make change.


> If so, who deletes the rest of the recorders in the list? I'd expect 
> to see a loop here deleting all recorders in the list.
>
Recorder deletion in coded in recursive manner, in 
MemRecorer::~MemRecorder()

if (_next != NULL)  delete _next;

Thanks,

-Zhengyu


> Thanks
>
> Sent from my phone
>
> On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com 
> <mailto:zhengyu.gu at oracle.com>> wrote:
>
>     Current NMT implementation reports number of loaded classes at
>     query time, but number of defined classes is what is expected.
>
>     This changset reflects two major changes:
>
>     1. It counts number of defined classes vs. number of loaded classes
>     2. It counts number of defined classes for each generation, vs.
>     counts at query time. In this way, the number of defined classes
>     that NMT reports, should match the corresponding class metadata
>     data. As the result, the data should be more accurate.
>
>
>     Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>     <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>
>
>     Thanks,
>
>     -Zhengyu
>

From vitalyd at gmail.com  Tue Dec 18 07:31:49 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 18 Dec 2012 10:31:49 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D08386.6060200@oracle.com>
References: <50CF7C73.7010608@oracle.com>
	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>
	<50D08386.6060200@oracle.com>
Message-ID: <CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>

Ah yes, I see the destructor in MemRecorder now - thanks.

Sent from my phone
On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com> wrote:

> **
> Hi Vitaly,
>
> Thanks for reviewing.
>
> On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>
> Hi Zhengyu,
>
> In GenerationData::reset() you delete _recorder_list.  Since this list is
> built from callers (I.e. caller adds recorders) is it good to delete the
> head here? I guess this class takes ownership of added recorders?
>
> Yes, releasing recorder via MemTracker::release_thread_recorder() is
> cleaner solution, I will make change.
>
>
>  If so, who deletes the rest of the recorders in the list? I'd expect to
> see a loop here deleting all recorders in the list.
>
> Recorder deletion in coded in recursive manner, in
> MemRecorer::~MemRecorder()
>
> if (_next != NULL)  delete _next;
>
> Thanks,
>
> -Zhengyu
>
>
>  Thanks
>
> Sent from my phone
> On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com> wrote:
>
>> Current NMT implementation reports number of loaded classes at query
>> time, but number of defined classes is what is expected.
>>
>> This changset reflects two major changes:
>>
>> 1. It counts number of defined classes vs. number of loaded classes
>> 2. It counts number of defined classes for each generation, vs. counts at
>> query time. In this way, the number of defined classes that NMT reports,
>> should match the corresponding class metadata data. As the result, the data
>> should be more accurate.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>
>

From vitalyd at gmail.com  Tue Dec 18 07:34:23 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 18 Dec 2012 10:34:23 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com>
	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>
	<50D08386.6060200@oracle.com>
	<CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>
Message-ID: <CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>

By the way, no chance of blowing the stack here if small stack size is
used, right?

Sent from my phone
On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Ah yes, I see the destructor in MemRecorder now - thanks.
>
> Sent from my phone
> On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com> wrote:
>
>> **
>> Hi Vitaly,
>>
>> Thanks for reviewing.
>>
>> On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>
>> Hi Zhengyu,
>>
>> In GenerationData::reset() you delete _recorder_list.  Since this list is
>> built from callers (I.e. caller adds recorders) is it good to delete the
>> head here? I guess this class takes ownership of added recorders?
>>
>> Yes, releasing recorder via MemTracker::release_thread_recorder() is
>> cleaner solution, I will make change.
>>
>>
>>  If so, who deletes the rest of the recorders in the list? I'd expect to
>> see a loop here deleting all recorders in the list.
>>
>> Recorder deletion in coded in recursive manner, in
>> MemRecorer::~MemRecorder()
>>
>> if (_next != NULL)  delete _next;
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>  Thanks
>>
>> Sent from my phone
>> On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com> wrote:
>>
>>> Current NMT implementation reports number of loaded classes at query
>>> time, but number of defined classes is what is expected.
>>>
>>> This changset reflects two major changes:
>>>
>>> 1. It counts number of defined classes vs. number of loaded classes
>>> 2. It counts number of defined classes for each generation, vs. counts
>>> at query time. In this way, the number of defined classes that NMT reports,
>>> should match the corresponding class metadata data. As the result, the data
>>> should be more accurate.
>>>
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>

From zhengyu.gu at oracle.com  Tue Dec 18 07:39:12 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 18 Dec 2012 10:39:12 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com>	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>	<50D08386.6060200@oracle.com>	<CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>
	<CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>
Message-ID: <50D08E20.3000703@oracle.com>

Not likely, but I will convert it to loop, just to eliminate the 
concerns ...

Thanks,

-Zhengyu

On 12/18/2012 10:34 AM, Vitaly Davidovich wrote:
>
> By the way, no chance of blowing the stack here if small stack size is 
> used, right?
>
> Sent from my phone
>
> On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com 
> <mailto:vitalyd at gmail.com>> wrote:
>
>     Ah yes, I see the destructor in MemRecorder now - thanks.
>
>     Sent from my phone
>
>     On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>     <mailto:zhengyu.gu at oracle.com>> wrote:
>
>         Hi Vitaly,
>
>         Thanks for reviewing.
>
>         On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>
>>         Hi Zhengyu,
>>
>>         In GenerationData::reset() you delete _recorder_list.  Since
>>         this list is built from callers (I.e. caller adds recorders)
>>         is it good to delete the head here? I guess this class takes
>>         ownership of added recorders?
>>
>         Yes, releasing recorder via
>         MemTracker::release_thread_recorder() is cleaner solution, I
>         will make change.
>
>
>>         If so, who deletes the rest of the recorders in the list? I'd
>>         expect to see a loop here deleting all recorders in the list.
>>
>         Recorder deletion in coded in recursive manner, in
>         MemRecorer::~MemRecorder()
>
>         if (_next != NULL)  delete _next;
>
>         Thanks,
>
>         -Zhengyu
>
>
>>         Thanks
>>
>>         Sent from my phone
>>
>>         On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>         <mailto:zhengyu.gu at oracle.com>> wrote:
>>
>>             Current NMT implementation reports number of loaded
>>             classes at query time, but number of defined classes is
>>             what is expected.
>>
>>             This changset reflects two major changes:
>>
>>             1. It counts number of defined classes vs. number of
>>             loaded classes
>>             2. It counts number of defined classes for each
>>             generation, vs. counts at query time. In this way, the
>>             number of defined classes that NMT reports, should match
>>             the corresponding class metadata data. As the result, the
>>             data should be more accurate.
>>
>>
>>             Webrev:
>>             http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>             <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>>
>>
>>             Thanks,
>>
>>             -Zhengyu
>>

From christian.tornqvist at oracle.com  Tue Dec 18 08:25:43 2012
From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=)
Date: Tue, 18 Dec 2012 08:25:43 -0800 (PST)
Subject: RFR (XXS): 8005163: Add keys to test.root to better support testing
	infrastructure
Message-ID: <54b38a5e-0cf3-4567-b57b-8d02d72d341c@default>

Hi everyone,

?

This is a very small change, adding a few keys to TEST.ROOT so that they can be used in our testing infrastructure.

?

Webrev can be found at:

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

?

Thanks,

Christian

From kelly.ohair at oracle.com  Tue Dec 18 08:59:19 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 18 Dec 2012 08:59:19 -0800
Subject: RFR (XXS): 8005163: Add keys to test.root to better support
	testing infrastructure
In-Reply-To: <54b38a5e-0cf3-4567-b57b-8d02d72d341c@default>
References: <54b38a5e-0cf3-4567-b57b-8d02d72d341c@default>
Message-ID: <950842EE-09A5-4239-8A06-62EC3F998B71@oracle.com>

Have you checked with Jonathan Gibbons or anyone about these?

I seem to recall that someone keeps track of these things or the spelling of them or something.

-kto

On Dec 18, 2012, at 8:25 AM, Christian T?rnqvist wrote:

> Hi everyone,
> 
>  
> 
> This is a very small change, adding a few keys to TEST.ROOT so that they can be used in our testing infrastructure.
> 
>  
> 
> Webrev can be found at:
> 
> http://cr.openjdk.java.net/~ehelin/8005163/webrev.00/
> 
>  
> 
> Thanks,
> 
> Christian


From joel.franck at oracle.com  Tue Dec 18 09:02:05 2012
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 18 Dec 2012 18:02:05 +0100
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <50CFD351.5090700@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50CFD351.5090700@oracle.com>
Message-ID: <50D0A18D.8040308@oracle.com>

Thanks for the review David!

cheers
/Joel

On 12/18/2012 03:22 AM, David Holmes wrote:
> Hi Joel,
>
> This all looks fine to me. I have no comments. Didn't even see any nits
> to pick. :)
>
> Thanks,
> David
>
> On 18/12/2012 2:47 AM, Joel Borggr?n-Franck wrote:
>> Hi,
>>
>> Here is a webrev for adding VM support for type annotation reflection:
>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>>
>> Type annotations are coming with JDK 8, the proposed language changes
>> can be found from here:
>> http://openjdk.java.net/projects/type-annotations/
>>
>> Since runtime visible type annotations probably won't  be that common
>> I have tried to minimise overhead when there are no type annotations.
>> This is done by adding a pointer to a type annotation Annotations
>> instance from the regular annotations Annotations instance, see
>> annotations.hpp. This means that if there are no runtime visible
>> annotations there is no additional overhead with this patch since no
>> Annotations instance will be allocated at all. If there is runtime
>> visible annotations but no runtime visible type annotations there is
>> an additional overhead of 1 pointer with this patch. If you use type
>> annotations there will also be storage overhead, but that is to be
>> expected.
>>
>> This patch also fixes  that Annotations were never deallocated when
>> InstanceKlass::deallocate_contents() were called.
>>
>> There is currently no redefineClass support for type annotations. This
>> will be added later. In order avoid ship possibly broken bytes to
>> java-land, type annotations are nulled out and deallocated after a
>> redefineClass.
>>
>> This patch also exports a new method from jvm.h,
>> JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are
>> included for review.
>>
>> Testing done:
>> - vm.quick.testlis both on b67 and on a jdk that is patched with the
>> new fields to Field, Method and Constructor
>> - jprt full forrest build
>> - jdk_lang in both b67 and the patched jdk
>> - manual tests that we get the correct bytes out from the VM. These
>> tests can be added once some more changes have propagated from the jdk
>> repo
>>
>> FYI, The initial set of jdk changes are being reviewed on
>> core-libs-dev:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html
>>
>>
>> cheers
>> /Joel

From joel.franck at oracle.com  Tue Dec 18 09:05:11 2012
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 18 Dec 2012 18:05:11 +0100
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
Message-ID: <50D0A247.20502@oracle.com>

New webrev up:

http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/

- I had to rename the field name for the type annotation byte[] in 
Field, Constructor and Method.

Also fixed:

- I fixed the mapfile that got reindented.
- Added back a comment that I accidentally removed.

cheers
/Joel

On 12/17/2012 05:47 PM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Here is a webrev for adding VM support for type annotation reflection: http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>
> Type annotations are coming with JDK 8, the proposed language changes can be found from here: http://openjdk.java.net/projects/type-annotations/
>
> Since runtime visible type annotations probably won't  be that common I have tried to minimise overhead when there are no type annotations. This is done by adding a pointer to a type annotation Annotations instance from the regular annotations Annotations instance, see annotations.hpp. This means that if there are no runtime visible annotations there is no additional overhead with this patch since no Annotations instance will be allocated at all. If there is runtime visible annotations but no runtime visible type annotations there is an additional overhead of 1 pointer with this patch. If you use type annotations there will also be storage overhead, but that is to be expected.
>
> This patch also fixes  that Annotations were never deallocated when InstanceKlass::deallocate_contents() were called.
>
> There is currently no redefineClass support for type annotations. This will be added later. In order avoid ship possibly broken bytes to java-land, type annotations are nulled out and deallocated after a redefineClass.
>
> This patch also exports a new method from jvm.h, JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are included for review.
>
> Testing done:
> - vm.quick.testlis both on b67 and on a jdk that is patched with the new fields to Field, Method and Constructor
> - jprt full forrest build
> - jdk_lang in both b67 and the patched jdk
> - manual tests that we get the correct bytes out from the VM. These tests can be added once some more changes have propagated from the jdk repo
>
> FYI, The initial set of jdk changes are being reviewed on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html
>
> cheers
> /Joel
>

From kelly.ohair at oracle.com  Tue Dec 18 09:19:38 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 18 Dec 2012 09:19:38 -0800
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <50D0A18D.8040308@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50CFD351.5090700@oracle.com> <50D0A18D.8040308@oracle.com>
Message-ID: <5281ABCC-E0B9-4596-B8F7-1C2A3288B93F@oracle.com>

mapfiles look fine.

-kto

On Dec 18, 2012, at 9:02 AM, Joel Borggr?n-Franck wrote:

> Thanks for the review David!
> 
> cheers
> /Joel
> 
> On 12/18/2012 03:22 AM, David Holmes wrote:
>> Hi Joel,
>> 
>> This all looks fine to me. I have no comments. Didn't even see any nits
>> to pick. :)
>> 
>> Thanks,
>> David
>> 
>> On 18/12/2012 2:47 AM, Joel Borggr?n-Franck wrote:
>>> Hi,
>>> 
>>> Here is a webrev for adding VM support for type annotation reflection:
>>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>>> 
>>> Type annotations are coming with JDK 8, the proposed language changes
>>> can be found from here:
>>> http://openjdk.java.net/projects/type-annotations/
>>> 
>>> Since runtime visible type annotations probably won't  be that common
>>> I have tried to minimise overhead when there are no type annotations.
>>> This is done by adding a pointer to a type annotation Annotations
>>> instance from the regular annotations Annotations instance, see
>>> annotations.hpp. This means that if there are no runtime visible
>>> annotations there is no additional overhead with this patch since no
>>> Annotations instance will be allocated at all. If there is runtime
>>> visible annotations but no runtime visible type annotations there is
>>> an additional overhead of 1 pointer with this patch. If you use type
>>> annotations there will also be storage overhead, but that is to be
>>> expected.
>>> 
>>> This patch also fixes  that Annotations were never deallocated when
>>> InstanceKlass::deallocate_contents() were called.
>>> 
>>> There is currently no redefineClass support for type annotations. This
>>> will be added later. In order avoid ship possibly broken bytes to
>>> java-land, type annotations are nulled out and deallocated after a
>>> redefineClass.
>>> 
>>> This patch also exports a new method from jvm.h,
>>> JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are
>>> included for review.
>>> 
>>> Testing done:
>>> - vm.quick.testlis both on b67 and on a jdk that is patched with the
>>> new fields to Field, Method and Constructor
>>> - jprt full forrest build
>>> - jdk_lang in both b67 and the patched jdk
>>> - manual tests that we get the correct bytes out from the VM. These
>>> tests can be added once some more changes have propagated from the jdk
>>> repo
>>> 
>>> FYI, The initial set of jdk changes are being reviewed on
>>> core-libs-dev:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html
>>> 
>>> 
>>> cheers
>>> /Joel


From zhengyu.gu at oracle.com  Tue Dec 18 11:59:17 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 18 Dec 2012 14:59:17 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D08E20.3000703@oracle.com>
References: <50CF7C73.7010608@oracle.com>	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>	<50D08386.6060200@oracle.com>	<CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>	<CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>
	<50D08E20.3000703@oracle.com>
Message-ID: <50D0CB15.8060708@oracle.com>

Hi,

I updated the webrev to reflect the suggestions.

Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.01/

Thanks,

-Zhengyu


On 12/18/2012 10:39 AM, Zhengyu Gu wrote:
> Not likely, but I will convert it to loop, just to eliminate the 
> concerns ...
>
> Thanks,
>
> -Zhengyu
>
> On 12/18/2012 10:34 AM, Vitaly Davidovich wrote:
>>
>> By the way, no chance of blowing the stack here if small stack size 
>> is used, right?
>>
>> Sent from my phone
>>
>> On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com 
>> <mailto:vitalyd at gmail.com>> wrote:
>>
>>     Ah yes, I see the destructor in MemRecorder now - thanks.
>>
>>     Sent from my phone
>>
>>     On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>
>>         Hi Vitaly,
>>
>>         Thanks for reviewing.
>>
>>         On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>>
>>>         Hi Zhengyu,
>>>
>>>         In GenerationData::reset() you delete _recorder_list.  Since
>>>         this list is built from callers (I.e. caller adds recorders)
>>>         is it good to delete the head here? I guess this class takes
>>>         ownership of added recorders?
>>>
>>         Yes, releasing recorder via
>>         MemTracker::release_thread_recorder() is cleaner solution, I
>>         will make change.
>>
>>
>>>         If so, who deletes the rest of the recorders in the list? I'd
>>>         expect to see a loop here deleting all recorders in the list.
>>>
>>         Recorder deletion in coded in recursive manner, in
>>         MemRecorer::~MemRecorder()
>>
>>         if (_next != NULL)  delete _next;
>>
>>         Thanks,
>>
>>         -Zhengyu
>>
>>
>>>         Thanks
>>>
>>>         Sent from my phone
>>>
>>>         On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>
>>>             Current NMT implementation reports number of loaded
>>>             classes at query time, but number of defined classes is
>>>             what is expected.
>>>
>>>             This changset reflects two major changes:
>>>
>>>             1. It counts number of defined classes vs. number of
>>>             loaded classes
>>>             2. It counts number of defined classes for each
>>>             generation, vs. counts at query time. In this way, the
>>>             number of defined classes that NMT reports, should match
>>>             the corresponding class metadata data. As the result, the
>>>             data should be more accurate.
>>>
>>>
>>>             Webrev:
>>>             http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>> <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>>>
>>>
>>>             Thanks,
>>>
>>>             -Zhengyu
>>>

From david.holmes at oracle.com  Tue Dec 18 14:40:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Dec 2012 08:40:27 +1000
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <50D0A247.20502@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50D0A247.20502@oracle.com>
Message-ID: <50D0F0DB.50900@oracle.com>

Thumbs up.

David

On 19/12/2012 3:05 AM, Joel Borggr?n-Franck wrote:
> New webrev up:
>
> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/
>
> - I had to rename the field name for the type annotation byte[] in
> Field, Constructor and Method.
>
> Also fixed:
>
> - I fixed the mapfile that got reindented.
> - Added back a comment that I accidentally removed.
>
> cheers
> /Joel
>
> On 12/17/2012 05:47 PM, Joel Borggr?n-Franck wrote:
>> Hi,
>>
>> Here is a webrev for adding VM support for type annotation reflection:
>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>>
>> Type annotations are coming with JDK 8, the proposed language changes
>> can be found from here:
>> http://openjdk.java.net/projects/type-annotations/
>>
>> Since runtime visible type annotations probably won't be that common I
>> have tried to minimise overhead when there are no type annotations.
>> This is done by adding a pointer to a type annotation Annotations
>> instance from the regular annotations Annotations instance, see
>> annotations.hpp. This means that if there are no runtime visible
>> annotations there is no additional overhead with this patch since no
>> Annotations instance will be allocated at all. If there is runtime
>> visible annotations but no runtime visible type annotations there is
>> an additional overhead of 1 pointer with this patch. If you use type
>> annotations there will also be storage overhead, but that is to be
>> expected.
>>
>> This patch also fixes that Annotations were never deallocated when
>> InstanceKlass::deallocate_contents() were called.
>>
>> There is currently no redefineClass support for type annotations. This
>> will be added later. In order avoid ship possibly broken bytes to
>> java-land, type annotations are nulled out and deallocated after a
>> redefineClass.
>>
>> This patch also exports a new method from jvm.h,
>> JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are
>> included for review.
>>
>> Testing done:
>> - vm.quick.testlis both on b67 and on a jdk that is patched with the
>> new fields to Field, Method and Constructor
>> - jprt full forrest build
>> - jdk_lang in both b67 and the patched jdk
>> - manual tests that we get the correct bytes out from the VM. These
>> tests can be added once some more changes have propagated from the jdk
>> repo
>>
>> FYI, The initial set of jdk changes are being reviewed on
>> core-libs-dev:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html
>>
>>
>> cheers
>> /Joel
>>

From zhengyu.gu at oracle.com  Tue Dec 18 14:48:25 2012
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Tue, 18 Dec 2012 22:48:25 +0000
Subject: hg: hsx/hsx24/hotspot: 2 new changesets
Message-ID: <20121218224830.EC9D94723A@hg.openjdk.java.net>

Changeset: f0ea4cc93756
Author:    zgu
Date:      2012-12-17 13:14 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f0ea4cc93756

8004802: jcmd VM.native_memory baseline=false crashes VM
Summary: NMT has to check option's value also to determine which command to execute
Reviewed-by: acorn, coleenp, hseigel

! src/share/vm/services/nmtDCmd.cpp

Changeset: 9e00e448460e
Author:    zgu
Date:      2012-12-18 11:28 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9e00e448460e

Merge



From david.holmes at oracle.com  Tue Dec 18 15:29:16 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Dec 2012 09:29:16 +1000
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D08120.2020306@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com>
Message-ID: <50D0FC4C.4050009@oracle.com>

On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
> Hi David,
>
> Thanks for reviewing.
>
> On 12/17/2012 9:41 PM, David Holmes wrote:
>> Hi Zhengyu,
>>
>> On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>>> Current NMT implementation reports number of loaded classes at query
>>> time, but number of defined classes is what is expected.
>>>
>>> This changset reflects two major changes:
>>>
>>> 1. It counts number of defined classes vs. number of loaded classes
>>
>> Can you explain what the distinction is please? I don't know what a
>> "defined class" is.
>>
> "defined class" refers to class definition (InstanceKlass), "loaded
> class" refers to instance.

Sorry that didn't help. I don't understand what these two different 
things are (InstanceKlass vs. "instance" ???). Can you explain in terms 
of Java level class loading - when is a class "defined" versus "loaded"?

Thanks,
David

>
>>> 2. It counts number of defined classes for each generation, vs. counts
>>> at query time. In this way, the number of defined classes that NMT
>>> reports, should match the corresponding class metadata data. As the
>>> result, the data should be more accurate.
>>>
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>
>> I think we could benefit from NMT_ONLY(x) macros to get rid of the
>> one-line conditional blocks eg in instanceKlass.cpp
> After consulting Chris Plummer, it does not have to exclude for
> embedded. But yes, have NMT_ONLY() macros will be very helpful, I will
> keep this in mind.
>
>>
>> ---
>>
>> src/share/vm/oops/instanceKlass.hpp
>>
>> + #if INCLUDE_NMT
>> + static int number_of_instance_classes() { return
>> (int)_total_instanceKlass_count; }
>> +
>> + private:
>> + static volatile jint _total_instanceKlass_count;
>> + #endif
>>
>> Why are we mixing int and jint here?
> Yes, it is bad idea. Will change to "int"
>
> Thanks,
>
> -Zhengyu
>>
>> ---
>>
>> I can't comment on the detailed memory management of the GenerationData.
>>
>> David
>> -----
>>
>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu

From vitalyd at gmail.com  Tue Dec 18 16:54:27 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 18 Dec 2012 19:54:27 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D0FC4C.4050009@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com> <50D0FC4C.4050009@oracle.com>
Message-ID: <CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>

David,

I suspect this is referring to the fact that InstanceKlass (VM
representation of java.lang.Class) can be in several states:
defined/allocated, loaded, linked/verified, etc.

Perhaps Classloader.define() and loadClass() are the classloader level
distinctions you're interested in?

Sent from my phone
On Dec 18, 2012 6:30 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>
>> Hi David,
>>
>> Thanks for reviewing.
>>
>> On 12/17/2012 9:41 PM, David Holmes wrote:
>>
>>> Hi Zhengyu,
>>>
>>> On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>>>
>>>> Current NMT implementation reports number of loaded classes at query
>>>> time, but number of defined classes is what is expected.
>>>>
>>>> This changset reflects two major changes:
>>>>
>>>> 1. It counts number of defined classes vs. number of loaded classes
>>>>
>>>
>>> Can you explain what the distinction is please? I don't know what a
>>> "defined class" is.
>>>
>>>  "defined class" refers to class definition (InstanceKlass), "loaded
>> class" refers to instance.
>>
>
> Sorry that didn't help. I don't understand what these two different things
> are (InstanceKlass vs. "instance" ???). Can you explain in terms of Java
> level class loading - when is a class "defined" versus "loaded"?
>
> Thanks,
> David
>
>
>>  2. It counts number of defined classes for each generation, vs. counts
>>>> at query time. In this way, the number of defined classes that NMT
>>>> reports, should match the corresponding class metadata data. As the
>>>> result, the data should be more accurate.
>>>>
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~**zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>
>>>>
>>>
>>> I think we could benefit from NMT_ONLY(x) macros to get rid of the
>>> one-line conditional blocks eg in instanceKlass.cpp
>>>
>> After consulting Chris Plummer, it does not have to exclude for
>> embedded. But yes, have NMT_ONLY() macros will be very helpful, I will
>> keep this in mind.
>>
>>
>>> ---
>>>
>>> src/share/vm/oops/**instanceKlass.hpp
>>>
>>> + #if INCLUDE_NMT
>>> + static int number_of_instance_classes() { return
>>> (int)_total_instanceKlass_**count; }
>>> +
>>> + private:
>>> + static volatile jint _total_instanceKlass_count;
>>> + #endif
>>>
>>> Why are we mixing int and jint here?
>>>
>> Yes, it is bad idea. Will change to "int"
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>>
>>> ---
>>>
>>> I can't comment on the detailed memory management of the GenerationData.
>>>
>>> David
>>> -----
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>

From david.holmes at oracle.com  Tue Dec 18 16:59:51 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Dec 2012 10:59:51 +1000
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com> <50D0FC4C.4050009@oracle.com>
	<CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>
Message-ID: <50D11187.3000701@oracle.com>

On 19/12/2012 10:54 AM, Vitaly Davidovich wrote:
> David,
>
> I suspect this is referring to the fact that InstanceKlass (VM
> representation of java.lang.Class) can be in several states:
> defined/allocated, loaded, linked/verified, etc.

Okay. It would be good to be clear on that.

> Perhaps Classloader.define() and loadClass() are the classloader level
> distinctions you're interested in?

define() is the final step of loadClass(): first find the bytes for the 
class then send them to the VM via defineClass to actually load the 
class. "define" is not a state at the Java level.

Thanks,
David

>
> Sent from my phone
>
> On Dec 18, 2012 6:30 PM, "David Holmes" <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>
>         Hi David,
>
>         Thanks for reviewing.
>
>         On 12/17/2012 9:41 PM, David Holmes wrote:
>
>             Hi Zhengyu,
>
>             On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>
>                 Current NMT implementation reports number of loaded
>                 classes at query
>                 time, but number of defined classes is what is expected.
>
>                 This changset reflects two major changes:
>
>                 1. It counts number of defined classes vs. number of
>                 loaded classes
>
>
>             Can you explain what the distinction is please? I don't know
>             what a
>             "defined class" is.
>
>         "defined class" refers to class definition (InstanceKlass), "loaded
>         class" refers to instance.
>
>
>     Sorry that didn't help. I don't understand what these two different
>     things are (InstanceKlass vs. "instance" ???). Can you explain in
>     terms of Java level class loading - when is a class "defined" versus
>     "loaded"?
>
>     Thanks,
>     David
>
>
>                 2. It counts number of defined classes for each
>                 generation, vs. counts
>                 at query time. In this way, the number of defined
>                 classes that NMT
>                 reports, should match the corresponding class metadata
>                 data. As the
>                 result, the data should be more accurate.
>
>
>                 Webrev:
>                 http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/
>                 <http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>
>
>
>             I think we could benefit from NMT_ONLY(x) macros to get rid
>             of the
>             one-line conditional blocks eg in instanceKlass.cpp
>
>         After consulting Chris Plummer, it does not have to exclude for
>         embedded. But yes, have NMT_ONLY() macros will be very helpful,
>         I will
>         keep this in mind.
>
>
>             ---
>
>             src/share/vm/oops/__instanceKlass.hpp
>
>             + #if INCLUDE_NMT
>             + static int number_of_instance_classes() { return
>             (int)_total_instanceKlass___count; }
>             +
>             + private:
>             + static volatile jint _total_instanceKlass_count;
>             + #endif
>
>             Why are we mixing int and jint here?
>
>         Yes, it is bad idea. Will change to "int"
>
>         Thanks,
>
>         -Zhengyu
>
>
>             ---
>
>             I can't comment on the detailed memory management of the
>             GenerationData.
>
>             David
>             -----
>
>
>
>                 Thanks,
>
>                 -Zhengyu
>

From vitalyd at gmail.com  Tue Dec 18 17:05:21 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 18 Dec 2012 20:05:21 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D11187.3000701@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com> <50D0FC4C.4050009@oracle.com>
	<CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>
	<50D11187.3000701@oracle.com>
Message-ID: <CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>

You sure define is last step? Even classloader javadoc says it still needs
to be resolved (linked and verified, I presume).

Sent from my phone
On Dec 18, 2012 7:59 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 19/12/2012 10:54 AM, Vitaly Davidovich wrote:
>
>> David,
>>
>> I suspect this is referring to the fact that InstanceKlass (VM
>> representation of java.lang.Class) can be in several states:
>> defined/allocated, loaded, linked/verified, etc.
>>
>
> Okay. It would be good to be clear on that.
>
>  Perhaps Classloader.define() and loadClass() are the classloader level
>> distinctions you're interested in?
>>
>
> define() is the final step of loadClass(): first find the bytes for the
> class then send them to the VM via defineClass to actually load the class.
> "define" is not a state at the Java level.
>
> Thanks,
> David
>
>
>> Sent from my phone
>>
>> On Dec 18, 2012 6:30 PM, "David Holmes" <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>> wrote:
>>
>>     On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>>
>>         Hi David,
>>
>>         Thanks for reviewing.
>>
>>         On 12/17/2012 9:41 PM, David Holmes wrote:
>>
>>             Hi Zhengyu,
>>
>>             On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>>
>>                 Current NMT implementation reports number of loaded
>>                 classes at query
>>                 time, but number of defined classes is what is expected.
>>
>>                 This changset reflects two major changes:
>>
>>                 1. It counts number of defined classes vs. number of
>>                 loaded classes
>>
>>
>>             Can you explain what the distinction is please? I don't know
>>             what a
>>             "defined class" is.
>>
>>         "defined class" refers to class definition (InstanceKlass),
>> "loaded
>>         class" refers to instance.
>>
>>
>>     Sorry that didn't help. I don't understand what these two different
>>     things are (InstanceKlass vs. "instance" ???). Can you explain in
>>     terms of Java level class loading - when is a class "defined" versus
>>     "loaded"?
>>
>>     Thanks,
>>     David
>>
>>
>>                 2. It counts number of defined classes for each
>>                 generation, vs. counts
>>                 at query time. In this way, the number of defined
>>                 classes that NMT
>>                 reports, should match the corresponding class metadata
>>                 data. As the
>>                 result, the data should be more accurate.
>>
>>
>>                 Webrev:
>>                 http://cr.openjdk.java.net/~__**zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/>
>>                 <http://cr.openjdk.java.net/~**zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>
>> >
>>
>>
>>             I think we could benefit from NMT_ONLY(x) macros to get rid
>>             of the
>>             one-line conditional blocks eg in instanceKlass.cpp
>>
>>         After consulting Chris Plummer, it does not have to exclude for
>>         embedded. But yes, have NMT_ONLY() macros will be very helpful,
>>         I will
>>         keep this in mind.
>>
>>
>>             ---
>>
>>             src/share/vm/oops/__**instanceKlass.hpp
>>
>>             + #if INCLUDE_NMT
>>             + static int number_of_instance_classes() { return
>>             (int)_total_instanceKlass___**count; }
>>             +
>>             + private:
>>             + static volatile jint _total_instanceKlass_count;
>>             + #endif
>>
>>             Why are we mixing int and jint here?
>>
>>         Yes, it is bad idea. Will change to "int"
>>
>>         Thanks,
>>
>>         -Zhengyu
>>
>>
>>             ---
>>
>>             I can't comment on the detailed memory management of the
>>             GenerationData.
>>
>>             David
>>             -----
>>
>>
>>
>>                 Thanks,
>>
>>                 -Zhengyu
>>
>>

From david.holmes at oracle.com  Tue Dec 18 17:15:09 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Dec 2012 11:15:09 +1000
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com> <50D0FC4C.4050009@oracle.com>
	<CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>
	<50D11187.3000701@oracle.com>
	<CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>
Message-ID: <50D1151D.5030802@oracle.com>

On 19/12/2012 11:05 AM, Vitaly Davidovich wrote:
> You sure define is last step? Even classloader javadoc says it still
> needs to be resolved (linked and verified, I presume).

Sorry I was being imprecise. After class definition the class is loaded 
but may still need to be resolved (linked).

A loaded Class at the Java level can be in one of three states:
- loaded, unlinked, uninitialized
- loaded, linked, uninitialized
- loaded, linked, initialized

Thanks,
David

> Sent from my phone
>
> On Dec 18, 2012 7:59 PM, "David Holmes" <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 19/12/2012 10:54 AM, Vitaly Davidovich wrote:
>
>         David,
>
>         I suspect this is referring to the fact that InstanceKlass (VM
>         representation of java.lang.Class) can be in several states:
>         defined/allocated, loaded, linked/verified, etc.
>
>
>     Okay. It would be good to be clear on that.
>
>         Perhaps Classloader.define() and loadClass() are the classloader
>         level
>         distinctions you're interested in?
>
>
>     define() is the final step of loadClass(): first find the bytes for
>     the class then send them to the VM via defineClass to actually load
>     the class. "define" is not a state at the Java level.
>
>     Thanks,
>     David
>
>
>         Sent from my phone
>
>         On Dec 18, 2012 6:30 PM, "David Holmes" <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>
>                  Hi David,
>
>                  Thanks for reviewing.
>
>                  On 12/17/2012 9:41 PM, David Holmes wrote:
>
>                      Hi Zhengyu,
>
>                      On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>
>                          Current NMT implementation reports number of loaded
>                          classes at query
>                          time, but number of defined classes is what is
>         expected.
>
>                          This changset reflects two major changes:
>
>                          1. It counts number of defined classes vs.
>         number of
>                          loaded classes
>
>
>                      Can you explain what the distinction is please? I
>         don't know
>                      what a
>         "defined class" is.
>
>         "defined class" refers to class definition (InstanceKlass), "loaded
>                  class" refers to instance.
>
>
>              Sorry that didn't help. I don't understand what these two
>         different
>              things are (InstanceKlass vs. "instance" ???). Can you
>         explain in
>              terms of Java level class loading - when is a class
>         "defined" versus
>         "loaded"?
>
>              Thanks,
>              David
>
>
>                          2. It counts number of defined classes for each
>                          generation, vs. counts
>                          at query time. In this way, the number of defined
>                          classes that NMT
>                          reports, should match the corresponding class
>         metadata
>                          data. As the
>                          result, the data should be more accurate.
>
>
>                          Webrev:
>         http://cr.openjdk.java.net/~____zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/>
>         <http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>>
>
>
>                      I think we could benefit from NMT_ONLY(x) macros to
>         get rid
>                      of the
>                      one-line conditional blocks eg in instanceKlass.cpp
>
>                  After consulting Chris Plummer, it does not have to
>         exclude for
>                  embedded. But yes, have NMT_ONLY() macros will be very
>         helpful,
>                  I will
>                  keep this in mind.
>
>
>                      ---
>
>                      src/share/vm/oops/____instanceKlass.hpp
>
>                      + #if INCLUDE_NMT
>                      + static int number_of_instance_classes() { return
>                      (int)_total_instanceKlass_____count; }
>                      +
>                      + private:
>                      + static volatile jint _total_instanceKlass_count;
>                      + #endif
>
>                      Why are we mixing int and jint here?
>
>                  Yes, it is bad idea. Will change to "int"
>
>                  Thanks,
>
>                  -Zhengyu
>
>
>                      ---
>
>                      I can't comment on the detailed memory management
>         of the
>                      GenerationData.
>
>                      David
>                      -----
>
>
>
>                          Thanks,
>
>                          -Zhengyu
>

From david.holmes at oracle.com  Tue Dec 18 17:15:20 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Dec 2012 11:15:20 +1000
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com> <50D0FC4C.4050009@oracle.com>
	<CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>
	<50D11187.3000701@oracle.com>
	<CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>
Message-ID: <50D11528.8000704@oracle.com>

On 19/12/2012 11:05 AM, Vitaly Davidovich wrote:
> You sure define is last step? Even classloader javadoc says it still
> needs to be resolved (linked and verified, I presume).

Sorry I was being imprecise. After class definition the class is loaded 
but may still need to be resolved (linked).

A loaded Class at the Java level can be in one of three states:
- loaded, unlinked, uninitialized
- loaded, linked, uninitialized
- loaded, linked, initialized

Thanks,
David

> Sent from my phone
>
> On Dec 18, 2012 7:59 PM, "David Holmes" <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 19/12/2012 10:54 AM, Vitaly Davidovich wrote:
>
>         David,
>
>         I suspect this is referring to the fact that InstanceKlass (VM
>         representation of java.lang.Class) can be in several states:
>         defined/allocated, loaded, linked/verified, etc.
>
>
>     Okay. It would be good to be clear on that.
>
>         Perhaps Classloader.define() and loadClass() are the classloader
>         level
>         distinctions you're interested in?
>
>
>     define() is the final step of loadClass(): first find the bytes for
>     the class then send them to the VM via defineClass to actually load
>     the class. "define" is not a state at the Java level.
>
>     Thanks,
>     David
>
>
>         Sent from my phone
>
>         On Dec 18, 2012 6:30 PM, "David Holmes" <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>
>                  Hi David,
>
>                  Thanks for reviewing.
>
>                  On 12/17/2012 9:41 PM, David Holmes wrote:
>
>                      Hi Zhengyu,
>
>                      On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>
>                          Current NMT implementation reports number of loaded
>                          classes at query
>                          time, but number of defined classes is what is
>         expected.
>
>                          This changset reflects two major changes:
>
>                          1. It counts number of defined classes vs.
>         number of
>                          loaded classes
>
>
>                      Can you explain what the distinction is please? I
>         don't know
>                      what a
>         "defined class" is.
>
>         "defined class" refers to class definition (InstanceKlass), "loaded
>                  class" refers to instance.
>
>
>              Sorry that didn't help. I don't understand what these two
>         different
>              things are (InstanceKlass vs. "instance" ???). Can you
>         explain in
>              terms of Java level class loading - when is a class
>         "defined" versus
>         "loaded"?
>
>              Thanks,
>              David
>
>
>                          2. It counts number of defined classes for each
>                          generation, vs. counts
>                          at query time. In this way, the number of defined
>                          classes that NMT
>                          reports, should match the corresponding class
>         metadata
>                          data. As the
>                          result, the data should be more accurate.
>
>
>                          Webrev:
>         http://cr.openjdk.java.net/~____zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/>
>         <http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>>
>
>
>                      I think we could benefit from NMT_ONLY(x) macros to
>         get rid
>                      of the
>                      one-line conditional blocks eg in instanceKlass.cpp
>
>                  After consulting Chris Plummer, it does not have to
>         exclude for
>                  embedded. But yes, have NMT_ONLY() macros will be very
>         helpful,
>                  I will
>                  keep this in mind.
>
>
>                      ---
>
>                      src/share/vm/oops/____instanceKlass.hpp
>
>                      + #if INCLUDE_NMT
>                      + static int number_of_instance_classes() { return
>                      (int)_total_instanceKlass_____count; }
>                      +
>                      + private:
>                      + static volatile jint _total_instanceKlass_count;
>                      + #endif
>
>                      Why are we mixing int and jint here?
>
>                  Yes, it is bad idea. Will change to "int"
>
>                  Thanks,
>
>                  -Zhengyu
>
>
>                      ---
>
>                      I can't comment on the detailed memory management
>         of the
>                      GenerationData.
>
>                      David
>                      -----
>
>
>
>                          Thanks,
>
>                          -Zhengyu
>

From vitalyd at gmail.com  Tue Dec 18 17:41:36 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 18 Dec 2012 20:41:36 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D11528.8000704@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D08120.2020306@oracle.com> <50D0FC4C.4050009@oracle.com>
	<CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>
	<50D11187.3000701@oracle.com>
	<CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>
	<50D11528.8000704@oracle.com>
Message-ID: <CAHjP37HwCcQm77Umec157h4SRrA=Anuxfc3_0vriypn3ZtFSWw@mail.gmail.com>

OK yeah, that makes sense.  Looking at oops/InstanceKlass.hpp, it looks
like there's a precursor state(ClassState::allocated) in the VM.

Sent from my phone
On Dec 18, 2012 8:15 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 19/12/2012 11:05 AM, Vitaly Davidovich wrote:
>
>> You sure define is last step? Even classloader javadoc says it still
>> needs to be resolved (linked and verified, I presume).
>>
>
> Sorry I was being imprecise. After class definition the class is loaded
> but may still need to be resolved (linked).
>
> A loaded Class at the Java level can be in one of three states:
> - loaded, unlinked, uninitialized
> - loaded, linked, uninitialized
> - loaded, linked, initialized
>
> Thanks,
> David
>
>  Sent from my phone
>>
>> On Dec 18, 2012 7:59 PM, "David Holmes" <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>> wrote:
>>
>>     On 19/12/2012 10:54 AM, Vitaly Davidovich wrote:
>>
>>         David,
>>
>>         I suspect this is referring to the fact that InstanceKlass (VM
>>         representation of java.lang.Class) can be in several states:
>>         defined/allocated, loaded, linked/verified, etc.
>>
>>
>>     Okay. It would be good to be clear on that.
>>
>>         Perhaps Classloader.define() and loadClass() are the classloader
>>         level
>>         distinctions you're interested in?
>>
>>
>>     define() is the final step of loadClass(): first find the bytes for
>>     the class then send them to the VM via defineClass to actually load
>>     the class. "define" is not a state at the Java level.
>>
>>     Thanks,
>>     David
>>
>>
>>         Sent from my phone
>>
>>         On Dec 18, 2012 6:30 PM, "David Holmes" <david.holmes at oracle.com
>>         <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>
>>         <mailto:david.holmes at oracle.__**com
>>         <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>>>
>> wrote:
>>
>>              On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>>
>>                  Hi David,
>>
>>                  Thanks for reviewing.
>>
>>                  On 12/17/2012 9:41 PM, David Holmes wrote:
>>
>>                      Hi Zhengyu,
>>
>>                      On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>>
>>                          Current NMT implementation reports number of
>> loaded
>>                          classes at query
>>                          time, but number of defined classes is what is
>>         expected.
>>
>>                          This changset reflects two major changes:
>>
>>                          1. It counts number of defined classes vs.
>>         number of
>>                          loaded classes
>>
>>
>>                      Can you explain what the distinction is please? I
>>         don't know
>>                      what a
>>         "defined class" is.
>>
>>         "defined class" refers to class definition (InstanceKlass),
>> "loaded
>>                  class" refers to instance.
>>
>>
>>              Sorry that didn't help. I don't understand what these two
>>         different
>>              things are (InstanceKlass vs. "instance" ???). Can you
>>         explain in
>>              terms of Java level class loading - when is a class
>>         "defined" versus
>>         "loaded"?
>>
>>              Thanks,
>>              David
>>
>>
>>                          2. It counts number of defined classes for each
>>                          generation, vs. counts
>>                          at query time. In this way, the number of defined
>>                          classes that NMT
>>                          reports, should match the corresponding class
>>         metadata
>>                          data. As the
>>                          result, the data should be more accurate.
>>
>>
>>                          Webrev:
>>         http://cr.openjdk.java.net/~__**__zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~____zgu/8005048/webrev.00/>
>>         <http://cr.openjdk.java.net/~_**_zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/>
>> >
>>         <http://cr.openjdk.java.net/~_**_zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/>
>>         <http://cr.openjdk.java.net/~**zgu/8005048/webrev.00/<http://cr.openjdk.java.net/~zgu/8005048/webrev.00/>
>> >>
>>
>>
>>                      I think we could benefit from NMT_ONLY(x) macros to
>>         get rid
>>                      of the
>>                      one-line conditional blocks eg in instanceKlass.cpp
>>
>>                  After consulting Chris Plummer, it does not have to
>>         exclude for
>>                  embedded. But yes, have NMT_ONLY() macros will be very
>>         helpful,
>>                  I will
>>                  keep this in mind.
>>
>>
>>                      ---
>>
>>                      src/share/vm/oops/____**instanceKlass.hpp
>>
>>                      + #if INCLUDE_NMT
>>                      + static int number_of_instance_classes() { return
>>                      (int)_total_instanceKlass_____**count; }
>>                      +
>>                      + private:
>>                      + static volatile jint _total_instanceKlass_count;
>>                      + #endif
>>
>>                      Why are we mixing int and jint here?
>>
>>                  Yes, it is bad idea. Will change to "int"
>>
>>                  Thanks,
>>
>>                  -Zhengyu
>>
>>
>>                      ---
>>
>>                      I can't comment on the detailed memory management
>>         of the
>>                      GenerationData.
>>
>>                      David
>>                      -----
>>
>>
>>
>>                          Thanks,
>>
>>                          -Zhengyu
>>
>>

From vladimir.kozlov at oracle.com  Tue Dec 18 18:00:15 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Wed, 19 Dec 2012 02:00:15 +0000
Subject: hg: hsx/hotspot-main/jdk: 8004318: JEP-171: Support Unsafe fences
	intrinsics
Message-ID: <20121219020110.E3AC74724D@hg.openjdk.java.net>

Changeset: ad6097d547e1
Author:    kvn
Date:      2012-12-18 17:47 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad6097d547e1

8004318: JEP-171: Support Unsafe fences intrinsics
Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class.
Reviewed-by: twisti, kvn
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! src/share/classes/sun/misc/Unsafe.java


From goetz.lindenmaier at sap.com  Wed Dec 19 08:48:41 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 19 Dec 2012 17:48:41 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <50D05112.70506@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>

Hi David, 

first, thanks for the fast replies. Sorry it took me a day now!

> I didn't say that. I said these two need to be ordered and asked which 
> other paired accesses to these variables need to be ordered.
Together with a colleague I looked at the code. To us it seems 
very hard to identify places where access ordering is not needed.
Especially we think there will be places in the users of the 
task queue that would need barriers to ensure ordering.
But we think, the algorithm should be self-contained, doing all the
required ordering itself. 

Further, a barrier will spoil performance on x86 etc, because there it
issues a lock instruction, which is not needed. 


> I said that what you were doing was effectively treating the C++ variables 
> as if they were Java volatile variables. That's not the way we handle 
> these issues in the VM we tend to place fences/barriers at the places in 
> lock-free algorithms that need them, rather than wrap the variables in 
> accessors that impose fences/barriers that are not always needed.

As we understand, the C compilers on x86, sparc etc, enforce far more
than required to implement C++ volatile, basically treating the fields
like Java volatiles.  Therefore your code is fine on your platforms.
The C++ compilers on PPC optimize far more, maxing out
what the standard allows and the processer supports, leading to
immediate errors, but also to very subtle ones.

Our change makes explicit what the C compilers (except for PPC) do
anyways, and what is required by the algorithm. (Maybe one could now
even omit the volatile keywords - but we dare not try.) Thus, we get
it right without any overhead on your platforms.


> Though we have not run into this particular issue. Did 
> it arise in the context of a particular GC?
Issues are only on PPC, at least in parallelScavenge. I reproduced
some of the immediate errors, but I don't think this really helps with
the discussion.  I will try G1 soon.  Tell me if you want to know
more, then I'll try to come up with a wrap-up of our past fixes.

Best regards,
  Goetz.


-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Dienstag, 18. Dezember 2012 12:19
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): Memory ordering in taskqueue.hpp

Hi Goetz,

On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
> Hi David,
>
> why do you think only these two accesses have to be ordered?

I didn't say that. I said these two need to be ordered and asked which 
other paired accesses to these variables need to be ordered.

> As I understand, any two accesses in one thread to these fields have to be
> orderered and must be written to memory to become visible in the proper order
> to other threads.

That depends on how they are used. It is the overall lock-free algorithm 
that is important here. There may be places where the order of access 
does not matter (and there may not be).

> The PPC compiler really takes all advantages given by the
> C-Standard to optimize this, and the processor reorders heavily.

Yes I understand. Though we have not run into this particular issue. Did 
it arise in the context of a particular GC?

> The specification of volatile in
>         Age get() const volatile { return _data; }
> says that it must be read from memory, not that it can not be reordered.

I didn't say anything about C/C++ volatile (which doesn't even say it 
must be read from memory - except perhaps in latest MT C++ standard?). I 
said that what you were doing was effectively treating the C++ variables 
as if they were Java volatile variables. That's not the way we handle 
these issues in the VM we tend to place fences/barriers at the places in 
lock-free algorithms that need them, rather than wrap the variables in 
accessors that impose fences/barriers that are not always needed.

Cheers,
David

> Also, doing
>        OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
> is better wrt. to optimizations by C-compilers, as there first
> is the whole address computation, and then the cast to volatile.
> If we use
>        _age.top()
> with
>        idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
> compilers don't optimize that well.  (We saw this on hpia64.)
> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
> the OrderAccess, which is useless overhead.
>
> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 18. Dezember 2012 01:24
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> Hi Goetz,
>
> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> Once more, with webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>
> I can see that this function needs a storestore barrier:
>
>    237   void set_empty() {
>    238     _bottom = 0;
>    239     _age.set(0);
>    240   }
>
> to preserve ordering. Are there other functions to which we can
> constrain the loadload and storestore barriers rather than using the
> setters/getters the way you have defined? This is always about a pair
> (sometimes groups) of accesses so I'd rather deal with the pairs than
> treat each field as if it were a Java volatile.
>
> Thanks,
> David Holmes
>
>
>> Sorry for that.
>>
>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>
>> On Platfoms with weak memory ordering the taskqueue is not accessed
>> properly, as the accesses to the fields _bottom and _age are not ordered
>> correctly. Volatile is not sufficient to enforce this, because it depends on
>> what the compiler assumes to be necessary for volatile variables.
>>
>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
>> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
>> use the getter/setter methods to access _bottom, _age or the subfields of _age.
>> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>>
>> The OrderAccess routines do simple load/stores on x86_64.
>>
>> I want to discuss this change here and would like very much to see it taking
>> it's way into OpenJDK to support ports on platforms with weak memory
>> ordering, and, in particular, our PPC port.
>>
>> Best regards,
>>     Goetz.
>>
>>

From eric.mccorkle at oracle.com  Wed Dec 19 11:46:06 2012
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 19 Dec 2012 14:46:06 -0500
Subject: Review request:Updated JDK-8004728 Add hotspot support for parameter
	reflection
Message-ID: <50D2197E.6090201@oracle.com>

Hello,

I have made some nontrivial changes to the hotspot side of parameter
reflection.  Please review again.

The original summary of the feature is as follows:

This is the VM side of the implementation of method parameter
reflection.  The implementation has been tested by building and running
regression tests with javac hardwired to produce classfiles containing
MethodParameters attributes.


Updates:

I have fixed issues with Method* vs methodHandle, some errors that arose
while testing the reflection API, and some suggested cosmetic changes.
There were also some additional changes that were necessitated by
changes in the reflection API implementation.


The new feature is here:
http://bugs.sun.com/view_bug.do?bug_id=8004728


The open webrev is here:
http://oklahoma.us.oracle.com/~cphillim/webrev/eric.webrev2/



The most recent version of the feature specification can be found here:
http://cr.openjdk.java.net/~abuckley/8misc.pdf

Thanks,
Eric

From coleen.phillimore at oracle.com  Wed Dec 19 12:41:11 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 19 Dec 2012 15:41:11 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50CFD7CF.1010408@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
Message-ID: <50D22667.3040106@oracle.com>

On 12/17/2012 9:41 PM, David Holmes wrote:
> Hi Zhengyu,
>
> On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>> Current NMT implementation reports number of loaded classes at query
>> time, but number of defined classes is what is expected.
>>
>> This changset reflects two major changes:
>>
>> 1. It counts number of defined classes vs. number of loaded classes
>
> Can you explain what the distinction is please? I don't know what a 
> "defined class" is.

I think what the bug is complaining about is that NMT returned the 
number of entries in the SystemDictionary which includes entries for 
classes for their initiating loader.   So for each VM representation of 
class, there were several entries, and only one is useful for counting 
how many classes were loaded (where class loader of the dictionary entry 
matches the class loader for the Klass*).   See code in 
systemDictionary.cpp classes_do().

When the class is parsed, the state is set to InstanceKlass::allocated.  
Right before the class is added to the system dictionary, it's changed 
to InstanceKlass::loaded, it's linked and initialized later.

Zhengyu's change counts the classes at the point where they are 
allocated.   So he's actually counting the allocated classes before they 
are loaded.  This is a relatively small window, though.   It's probably 
better to move the atomic add of this counter to the point where the 
class is added to the system dictionary (dictionary()->add_klass()) and 
remove it when the class is unloaded.   Note that the counter enables 
NMT not to lock the system dictionary to count the entries.

This change as is misses deleting anonymous classes, but counts adding 
them, since they are not added to the system dictionary. That count 
atomic add should be added to SystemDictionary::parse_stream() and 
decremented in ClassLoaderData::unload() for the anonymous class case.

Thanks,
Coleen

>
>> 2. It counts number of defined classes for each generation, vs. counts
>> at query time. In this way, the number of defined classes that NMT
>> reports, should match the corresponding class metadata data. As the
>> result, the data should be more accurate.
>>
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>
> I think we could benefit from NMT_ONLY(x) macros to get rid of the 
> one-line conditional blocks eg in instanceKlass.cpp
>
> ---
>
> src/share/vm/oops/instanceKlass.hpp
>
> + #if INCLUDE_NMT
> +   static int number_of_instance_classes() { return 
> (int)_total_instanceKlass_count; }
> +
> +  private:
> +   static volatile jint _total_instanceKlass_count;
> + #endif
>
> Why are we mixing int and jint here?
>
> ---
>
> I can't comment on the detailed memory management of the GenerationData.
>
> David
> -----
>
>
>>
>> Thanks,
>>
>> -Zhengyu


From karen.kinnear at oracle.com  Wed Dec 19 15:12:49 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 19 Dec 2012 18:12:49 -0500
Subject: Code review request: JDK-8005048,
	NMT: #loaded classes needs to just show the # defined classes
In-Reply-To: <50D22667.3040106@oracle.com>
References: <50CF7C73.7010608@oracle.com> <50CFD7CF.1010408@oracle.com>
	<50D22667.3040106@oracle.com>
Message-ID: <0F777E12-0A08-4940-8062-9CB6A7D06543@oracle.com>

Sorry I missed this. Good points Coleen about catching anonymous classes.

So I should have been clearer - the goal is to print the information about the number of classes for which
there is metadata using space.

So if we were to increment when the IK is allocated and decrement when the IK is freed, this would be 
the accuracy that we are looking for.

I believe that would also cover the anonymous classes - right?

So if you don't want to call it "defined" we can call it "allocated" - would that be clearer?

thanks,
Karen

On Dec 19, 2012, at 3:41 PM, Coleen Phillimore wrote:

> On 12/17/2012 9:41 PM, David Holmes wrote:
>> Hi Zhengyu,
>> 
>> On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>>> Current NMT implementation reports number of loaded classes at query
>>> time, but number of defined classes is what is expected.
>>> 
>>> This changset reflects two major changes:
>>> 
>>> 1. It counts number of defined classes vs. number of loaded classes
>> 
>> Can you explain what the distinction is please? I don't know what a "defined class" is.
> 
> I think what the bug is complaining about is that NMT returned the number of entries in the SystemDictionary which includes entries for classes for their initiating loader.   So for each VM representation of class, there were several entries, and only one is useful for counting how many classes were loaded (where class loader of the dictionary entry matches the class loader for the Klass*).   See code in systemDictionary.cpp classes_do().
> 
> When the class is parsed, the state is set to InstanceKlass::allocated.  Right before the class is added to the system dictionary, it's changed to InstanceKlass::loaded, it's linked and initialized later.
> 
> Zhengyu's change counts the classes at the point where they are allocated.   So he's actually counting the allocated classes before they are loaded.  This is a relatively small window, though.   It's probably better to move the atomic add of this counter to the point where the class is added to the system dictionary (dictionary()->add_klass()) and remove it when the class is unloaded.   Note that the counter enables NMT not to lock the system dictionary to count the entries.
> 
> This change as is misses deleting anonymous classes, but counts adding them, since they are not added to the system dictionary. That count atomic add should be added to SystemDictionary::parse_stream() and decremented in ClassLoaderData::unload() for the anonymous class case.
> 
> Thanks,
> Coleen
> 
>> 
>>> 2. It counts number of defined classes for each generation, vs. counts
>>> at query time. In this way, the number of defined classes that NMT
>>> reports, should match the corresponding class metadata data. As the
>>> result, the data should be more accurate.
>>> 
>>> 
>>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>> 
>> I think we could benefit from NMT_ONLY(x) macros to get rid of the one-line conditional blocks eg in instanceKlass.cpp
>> 
>> ---
>> 
>> src/share/vm/oops/instanceKlass.hpp
>> 
>> + #if INCLUDE_NMT
>> +   static int number_of_instance_classes() { return (int)_total_instanceKlass_count; }
>> +
>> +  private:
>> +   static volatile jint _total_instanceKlass_count;
>> + #endif
>> 
>> Why are we mixing int and jint here?
>> 
>> ---
>> 
>> I can't comment on the detailed memory management of the GenerationData.
>> 
>> David
>> -----
>> 
>> 
>>> 
>>> Thanks,
>>> 
>>> -Zhengyu
> 


From david.holmes at oracle.com  Wed Dec 19 17:36:01 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Dec 2012 11:36:01 +1000
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
Message-ID: <50D26B81.8080903@oracle.com>

On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
> first, thanks for the fast replies. Sorry it took me a day now!

No problem. I can't guarantee response times either :)

>> I didn't say that. I said these two need to be ordered and asked which
>> other paired accesses to these variables need to be ordered.
> Together with a colleague I looked at the code. To us it seems
> very hard to identify places where access ordering is not needed.
> Especially we think there will be places in the users of the
> task queue that would need barriers to ensure ordering.
> But we think, the algorithm should be self-contained, doing all the
> required ordering itself.

I agree the algorithm should be self-contained. My point is that in 
other places where we implement lock-free algorithm was put in the 
barriers/fences in the algorithmic code in the places needed we don't 
automatically wrap all of the variables accesses with code that 
introduces pre/post barriers (of whatever form).

> Further, a barrier will spoil performance on x86 etc, because there it
> issues a lock instruction, which is not needed.

You issue the appropriate barrier/fence for the situation and they 
should be implemented in whatever form needed for the given platform 
(modulo OrderAccess is far from perfect and has some outstanding issues).

>> I said that what you were doing was effectively treating the C++ variables
>> as if they were Java volatile variables. That's not the way we handle
>> these issues in the VM we tend to place fences/barriers at the places in
>> lock-free algorithms that need them, rather than wrap the variables in
>> accessors that impose fences/barriers that are not always needed.
>
> As we understand, the C compilers on x86, sparc etc, enforce far more
> than required to implement C++ volatile, basically treating the fields
> like Java volatiles.  Therefore your code is fine on your platforms.

I think you are confusing things. The existing C/C++ compilers do very 
little in regard to "volatile". It is only the latest multi-threading 
variant of the C++ standard that even addresses this! Our C/C++ 
compilers never issue any kind of memory barriers in response to a 
load/store of a volatile variable.

> The C++ compilers on PPC optimize far more, maxing out
> what the standard allows and the processer supports, leading to
> immediate errors, but also to very subtle ones.
>
> Our change makes explicit what the C compilers (except for PPC) do
> anyways, and what is required by the algorithm. (Maybe one could now
> even omit the volatile keywords - but we dare not try.) Thus, we get
> it right without any overhead on your platforms.

This is getting things confused. The lock-free algorithms should be 
written for the most lenient of memory-models and make no assumptions 
about ordering. They should use the appropriate OrderAccess method where 
needed for algorithmic correctness.

You proposal wraps the C variable in accessors that use OrderAccess 
operations on every access - in a similar way to how we have to handle 
Java volatile accesses. And as I have said that is not the style we use 
in hotspot's lock-free code. This has nothing to do with our compiler 
versus your compiler (though if you have one that issues memory-barriers 
directly then you'll get too much overhead.)

>> Though we have not run into this particular issue. Did
>> it arise in the context of a particular GC?
> Issues are only on PPC, at least in parallelScavenge. I reproduced
> some of the immediate errors, but I don't think this really helps with
> the discussion.  I will try G1 soon.  Tell me if you want to know
> more, then I'll try to come up with a wrap-up of our past fixes.

We have a PPC product and as I said we have not encountered this 
problem, but we also run with limited GCs so may not have been 
exercising this code.

Thanks,
David

> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 18. Dezember 2012 12:19
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> Hi Goetz,
>
> On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> why do you think only these two accesses have to be ordered?
>
> I didn't say that. I said these two need to be ordered and asked which
> other paired accesses to these variables need to be ordered.
>
>> As I understand, any two accesses in one thread to these fields have to be
>> orderered and must be written to memory to become visible in the proper order
>> to other threads.
>
> That depends on how they are used. It is the overall lock-free algorithm
> that is important here. There may be places where the order of access
> does not matter (and there may not be).
>
>> The PPC compiler really takes all advantages given by the
>> C-Standard to optimize this, and the processor reorders heavily.
>
> Yes I understand. Though we have not run into this particular issue. Did
> it arise in the context of a particular GC?
>
>> The specification of volatile in
>>          Age get() const volatile { return _data; }
>> says that it must be read from memory, not that it can not be reordered.
>
> I didn't say anything about C/C++ volatile (which doesn't even say it
> must be read from memory - except perhaps in latest MT C++ standard?). I
> said that what you were doing was effectively treating the C++ variables
> as if they were Java volatile variables. That's not the way we handle
> these issues in the VM we tend to place fences/barriers at the places in
> lock-free algorithms that need them, rather than wrap the variables in
> accessors that impose fences/barriers that are not always needed.
>
> Cheers,
> David
>
>> Also, doing
>>         OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
>> is better wrt. to optimizations by C-compilers, as there first
>> is the whole address computation, and then the cast to volatile.
>> If we use
>>         _age.top()
>> with
>>         idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
>> compilers don't optimize that well.  (We saw this on hpia64.)
>> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
>> the OrderAccess, which is useless overhead.
>>
>> Best regards,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 18. Dezember 2012 01:24
>> To: Lindenmaier, Goetz
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>
>> Hi Goetz,
>>
>> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Once more, with webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>>
>> I can see that this function needs a storestore barrier:
>>
>>     237   void set_empty() {
>>     238     _bottom = 0;
>>     239     _age.set(0);
>>     240   }
>>
>> to preserve ordering. Are there other functions to which we can
>> constrain the loadload and storestore barriers rather than using the
>> setters/getters the way you have defined? This is always about a pair
>> (sometimes groups) of accesses so I'd rather deal with the pairs than
>> treat each field as if it were a Java volatile.
>>
>> Thanks,
>> David Holmes
>>
>>
>>> Sorry for that.
>>>
>>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>>
>>> On Platfoms with weak memory ordering the taskqueue is not accessed
>>> properly, as the accesses to the fields _bottom and _age are not ordered
>>> correctly. Volatile is not sufficient to enforce this, because it depends on
>>> what the compiler assumes to be necessary for volatile variables.
>>>
>>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
>>> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
>>> use the getter/setter methods to access _bottom, _age or the subfields of _age.
>>> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>>>
>>> The OrderAccess routines do simple load/stores on x86_64.
>>>
>>> I want to discuss this change here and would like very much to see it taking
>>> it's way into OpenJDK to support ports on platforms with weak memory
>>> ordering, and, in particular, our PPC port.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>

From bengt.rutisson at oracle.com  Wed Dec 19 20:20:53 2012
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 20 Dec 2012 05:20:53 +0100
Subject: CFV: New HSX Reviewer: Stefan Karlsson
Message-ID: <50D29225.7000009@oracle.com>


I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].

Stefan is on his third year as a Committer on the HSX project. He is a 
key contributor in the Hotspot's GC group, working on all GCs.  He has 
contributed 32 significant changesets as a Committer and is thus 
well-qualified to be a Reviewer on the HSX project.

Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week 
voting period).

Only current HSX project Reviewers [2] are eligible to vote on this 
nomination.

For Three-Vote Consensus voting instructions, see [3].

Regards,
Bengt Rutisson

[0] http://openjdk.java.net/census/#hsx
[1] http://openjdk.java.net/bylaws#reviewer
[2] http://openjdk.java.net/projects/#reviewer-vote
[3] http://openjdk.java.net/bylaws#three-vote-consensus


From daniel.daugherty at oracle.com  Wed Dec 19 20:32:47 2012
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 19 Dec 2012 21:32:47 -0700
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <50D294EF.9050603@oracle.com>

Vote: yes

Dan

On 12/19/12 9:20 PM, Bengt Rutisson wrote:
>
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
>
> Stefan is on his third year as a Committer on the HSX project. He is a 
> key contributor in the Hotspot's GC group, working on all GCs.  He has 
> contributed 32 significant changesets as a Committer and is thus 
> well-qualified to be a Reviewer on the HSX project.
>
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week 
> voting period).
>
> Only current HSX project Reviewers [2] are eligible to vote on this 
> nomination.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> Regards,
> Bengt Rutisson
>
> [0] http://openjdk.java.net/census/#hsx
> [1] http://openjdk.java.net/bylaws#reviewer
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://openjdk.java.net/bylaws#three-vote-consensus
>


From vladimir.kozlov at oracle.com  Wed Dec 19 20:36:36 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 19 Dec 2012 20:36:36 -0800
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <50D295D4.5080406@oracle.com>

Vote: yes

On 12/19/12 8:20 PM, Bengt Rutisson wrote:
>
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
>
> Stefan is on his third year as a Committer on the HSX project. He is a
> key contributor in the Hotspot's GC group, working on all GCs.  He has
> contributed 32 significant changesets as a Committer and is thus
> well-qualified to be a Reviewer on the HSX project.
>
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week
> voting period).
>
> Only current HSX project Reviewers [2] are eligible to vote on this
> nomination.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> Regards,
> Bengt Rutisson
>
> [0] http://openjdk.java.net/census/#hsx
> [1] http://openjdk.java.net/bylaws#reviewer
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://openjdk.java.net/bylaws#three-vote-consensus
>

From david.holmes at oracle.com  Wed Dec 19 23:40:23 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Dec 2012 17:40:23 +1000
Subject: HotSpot Changes in 7u
In-Reply-To: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
Message-ID: <50D2C0E7.6080903@oracle.com>

Hi Andrew,

cc'ing hotspot-dev

On 20/12/2012 3:11 AM, Andrew Hughes wrote:
> Hi,
>
> What is the process for getting into HotSpot changes into 7u?
> Can individual changesets be suggested and committed or do we have
> to wait for a bulk update?  And who decides what goes in these bulk
> updates?

Disclaimer: This is my observation not a reflection of any written 
policies etc.

Most (all?) Hotspot changes come in via the hsX forest (currently hs24 
for 7u12). Most backports come about from things "we" know we need in 7; 
some come from individual engineers sponsoring the jdk8 change and then 
the backport (I've done a few of those).

Individual changesets can be suggested, but only hsx committers can 
commit them, so you likely need a sponsor (as was likely needed for the 
8/hs25 changeset anyway). The decision process is similar for 7u in 
general - we need to look at the nature of the problem and the fix and 
whether it is suitable for an update release (ie we won't backport 
perm-gen removal just because someone asks :) ). Backport complexity can 
also be an issue because of the significant changes between 7u and 
present 8 hotspot sources.

> We'd like to see the following changesets in 7u:
>
> 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/75982791ddb6

This seems reasonable to me. Though I will note that a few developers on 
the JDK disliked the appearance of the ""**NOTICE** Dtrace support 
disabled: ..." message in their build output.

> 8000622: Forgot to hg add and check in test for JDK-7170638
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/26351ce8c4b0

Again seems reasonable to me.

> 8000780: make Zero build and run with JDK8
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5

And again.

I'd suggest approaching the original engineers who sponsored these 
fixes. But please bear in mind that we are hitting an extremely busy 
period with JDK 8.

David
-----

> Thanks,

From david.holmes at oracle.com  Wed Dec 19 23:44:35 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Dec 2012 17:44:35 +1000
Subject: Review request:Updated JDK-8004728 Add hotspot support for
	parameter reflection
In-Reply-To: <50D2197E.6090201@oracle.com>
References: <50D2197E.6090201@oracle.com>
Message-ID: <50D2C1E3.6000607@oracle.com>

 > The open webrev is here:
 > http://oklahoma.us.oracle.com/~cphillim/webrev/eric.webrev2/

That's not an open webrev :)

Please relocate to cr.openjdk.java.net

Thanks,
David

On 20/12/2012 5:46 AM, Eric McCorkle wrote:
> Hello,
>
> I have made some nontrivial changes to the hotspot side of parameter
> reflection.  Please review again.
>
> The original summary of the feature is as follows:
>
> This is the VM side of the implementation of method parameter
> reflection.  The implementation has been tested by building and running
> regression tests with javac hardwired to produce classfiles containing
> MethodParameters attributes.
>
>
> Updates:
>
> I have fixed issues with Method* vs methodHandle, some errors that arose
> while testing the reflection API, and some suggested cosmetic changes.
> There were also some additional changes that were necessitated by
> changes in the reflection API implementation.
>
>
> The new feature is here:
> http://bugs.sun.com/view_bug.do?bug_id=8004728
>
>
> The open webrev is here:
> http://oklahoma.us.oracle.com/~cphillim/webrev/eric.webrev2/
>
>
>
> The most recent version of the feature specification can be found here:
> http://cr.openjdk.java.net/~abuckley/8misc.pdf
>
> Thanks,
> Eric

From yumin.qi at oracle.com  Thu Dec 20 01:01:17 2012
From: yumin.qi at oracle.com (yumin.qi at oracle.com)
Date: Thu, 20 Dec 2012 09:01:17 +0000
Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets
Message-ID: <20121220090138.BB79B472C7@hg.openjdk.java.net>

Changeset: 892acf0431ef
Author:    dcubed
Date:      2012-12-14 10:06 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/892acf0431ef

7153050: remove crufty '_g' support from HotSpot repo makefiles
Summary: Phase 1 is removing '_g' support from the Makefiles.
Reviewed-by: dcubed, sspitsyn, coleenp, tbell
Contributed-by: ron.durbin at oracle.com

! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/debug.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/fastdebug.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jsig.make
! make/bsd/makefiles/jvmg.make
! make/bsd/makefiles/optimized.make
! make/bsd/makefiles/product.make
! make/bsd/makefiles/saproc.make
! make/bsd/makefiles/vm.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/debug.make
! make/linux/makefiles/fastdebug.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/jsig.make
! make/linux/makefiles/jvmg.make
! make/linux/makefiles/optimized.make
! make/linux/makefiles/product.make
! make/linux/makefiles/saproc.make
! make/linux/makefiles/vm.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/debug.make
! make/solaris/makefiles/dtrace.make
! make/solaris/makefiles/fastdebug.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/jsig.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/product.make
! make/solaris/makefiles/saproc.make
! make/solaris/makefiles/vm.make
! make/windows/build.make
! make/windows/projectfiles/compiler2/ADLCompiler.dsp
! make/windows/projectfiles/tiered/ADLCompiler.dsp

Changeset: 30866cd626b0
Author:    coleenp
Date:      2012-12-12 11:39 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/30866cd626b0

8004883: NPG: clean up anonymous class fix
Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not.
Reviewed-by: stefank, jrose

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.hpp

Changeset: 18712b1caf7a
Author:    rkennke
Date:      2012-12-12 21:40 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/18712b1caf7a

8004898: library_call.cpp build error after 7172640 with GCC 4.7.2
Summary: fix opto/library_call.cpp compilation errors
Reviewed-by: twisti, coleenp

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

Changeset: 8580f22db905
Author:    coleenp
Date:      2012-12-14 16:43 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8580f22db905

Merge


Changeset: 3f84e17b6bca
Author:    zgu
Date:      2012-12-17 13:14 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3f84e17b6bca

8004802: jcmd VM.native_memory baseline=false crashes VM
Summary: NMT has to check option's value also to determine which command to execute
Reviewed-by: acorn, coleenp, hseigel

! src/share/vm/services/nmtDCmd.cpp

Changeset: 805aa223d540
Author:    zgu
Date:      2012-12-17 10:40 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/805aa223d540

Merge


Changeset: 594b9b2119ed
Author:    minqi
Date:      2012-12-19 16:10 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/594b9b2119ed

Merge



From joel.franck at oracle.com  Thu Dec 20 01:11:52 2012
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 20 Dec 2012 10:11:52 +0100
Subject: Review request:Updated JDK-8004728 Add hotspot support for
	parameter reflection
In-Reply-To: <50D2197E.6090201@oracle.com>
References: <50D2197E.6090201@oracle.com>
Message-ID: <50D2D658.9060206@oracle.com>

On 12/19/2012 08:46 PM, Eric McCorkle wrote:
> Hello,
>
> I have made some nontrivial changes to the hotspot side of parameter
> reflection.  Please review again.
>
>
> The open webrev is here:
> http://oklahoma.us.oracle.com/~cphillim/webrev/eric.webrev2/
>

Hi Eric,

I looked over the code since I have been doing changes in the same area 
for type annotations. A few comments:

In vmSymbols.hpp:

239   template(executable_name,  "executable")

and

477   template(executable_signature, "Ljava/lang/reflect/executable;")

do you need to add these? if so shouldn't these be 'Executable' with a 
capital E? I noticed you add Parameter to systemDictionary.hpp but not 
Executable is this intentional?

jvm.cpp:

1580   // method is a handle to a java.lang.reflect.Method object
1581   Method* const m = jvm_get_method_common(method, CHECK_NULL)

Nit, I don't think this comment is correct in a non-permgen world.

cheers
/Joel

From ysr1729 at gmail.com  Thu Dec 20 01:22:42 2012
From: ysr1729 at gmail.com (Srinivas Ramakrishna)
Date: Thu, 20 Dec 2012 01:22:42 -0800
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <CABzyjynNhnZpwrV+zAfKrJt8ZVcNsEs0n0b5rfqGhokFjmho-g@mail.gmail.com>

Vote: yes

-- ramki (openjdk: ysr)

On Wed, Dec 19, 2012 at 8:20 PM, Bengt Rutisson
<bengt.rutisson at oracle.com>wrote:

>
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
>
> Stefan is on his third year as a Committer on the HSX project. He is a key
> contributor in the Hotspot's GC group, working on all GCs.  He has
> contributed 32 significant changesets as a Committer and is thus
> well-qualified to be a Reviewer on the HSX project.
>
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week
> voting period).
>
> Only current HSX project Reviewers [2] are eligible to vote on this
> nomination.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> Regards,
> Bengt Rutisson
>
> [0] http://openjdk.java.net/**census/#hsx<http://openjdk.java.net/census/#hsx>
> [1] http://openjdk.java.net/**bylaws#reviewer<http://openjdk.java.net/bylaws#reviewer>
> [2] http://openjdk.java.net/**projects/#reviewer-vote<http://openjdk.java.net/projects/#reviewer-vote>
> [3] http://openjdk.java.net/**bylaws#three-vote-consensus<http://openjdk.java.net/bylaws#three-vote-consensus>
>
>

From goetz.lindenmaier at sap.com  Thu Dec 20 02:18:08 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 20 Dec 2012 11:18:08 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <50D26B81.8080903@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF7650697@DEWDFECCR03.wdf.sap.corp>

Hi David, 

I'll split this up, and first answer the easy one:

> We have a PPC product and as I said we have not encountered this 
> problem, but we also run with limited GCs so may not have been 
> exercising this code.
I know.  That's only 32 bit, right, and for embedded?
We also wondered why you are not experiencing the same problems
there. A reason might be that 32-bit PPC behaves different from
64-bit. E.g., the compiler might be more conservative on 32-bit.

Some of our problems are easy to reproduce, see the attached file. 
To produce the errors in the attached file I removed the 
taskqueue change from our port.  It did not fail with CMS
(-XX:+UseConcMarkSweepGC -XX:SurvivorRatio=4).

We also had issues that were much harder to detect.
In general, since we get more machines with many processor 
threads (e.g., 32), we also see more errors with memory ordering
issues.   Maybe you want to have a look at the fixes I already put into 
the port:
 
(taskqueue: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/ca3cac6a53bd you know this one)
 opto:        http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/3cd0e8951ecc
C-interpreter: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/6c726fea31d4
Other:     http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/07fd72d0ca47


It took us a row of fixes to end up at the solution for taskqueue I contributed.
In 2006, we added OrderAccess in OopTaskQueue::push() and 
GenTaskQueue::push().  We also added volatiles that were 
gone from your implementation for a while.

In 2008, we wrapped all accesses to _bottom in functions with
release/aquire (as it is still the case).  We added release/acquire in
get_age, get_top, set_age.  We did this after debugging a bug on PPC
where two threads GC'ed the same oop.

This was all done with #ifdefs for PPC.  Later we decided to remove the 
#ifdefs and only use the code with the release/acquire access functions. 
On x86 etc. this results in the same code, as the OrderAccess routines only do
a cast to volatile.  On ia64 we found a considerable performance
increase, because the HP C-compiler did better inlining.

When Oracle introduced Age::top() to replace SuperTaskQueue::get_top() etc,
the access ordering got lost in our code due to a wrong integration to our code 
in 2010.  Half a year later we again identified a bug, and added OrderAccess in Age::top().
This didn't suffice so 3 months later we replaced Age::top() by 
SuperTaskQueue::get_age_top().  Since that we had no issues with the taskqueue.


Now I'll go back and address the other issues ...

Best regards,
  Goetz.


















Thanks,
David

> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 18. Dezember 2012 12:19
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> Hi Goetz,
>
> On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> why do you think only these two accesses have to be ordered?
>
> I didn't say that. I said these two need to be ordered and asked which
> other paired accesses to these variables need to be ordered.
>
>> As I understand, any two accesses in one thread to these fields have to be
>> orderered and must be written to memory to become visible in the proper order
>> to other threads.
>
> That depends on how they are used. It is the overall lock-free algorithm
> that is important here. There may be places where the order of access
> does not matter (and there may not be).
>
>> The PPC compiler really takes all advantages given by the
>> C-Standard to optimize this, and the processor reorders heavily.
>
> Yes I understand. Though we have not run into this particular issue. Did
> it arise in the context of a particular GC?
>
>> The specification of volatile in
>>          Age get() const volatile { return _data; }
>> says that it must be read from memory, not that it can not be reordered.
>
> I didn't say anything about C/C++ volatile (which doesn't even say it
> must be read from memory - except perhaps in latest MT C++ standard?). I
> said that what you were doing was effectively treating the C++ variables
> as if they were Java volatile variables. That's not the way we handle
> these issues in the VM we tend to place fences/barriers at the places in
> lock-free algorithms that need them, rather than wrap the variables in
> accessors that impose fences/barriers that are not always needed.
>
> Cheers,
> David
>
>> Also, doing
>>         OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
>> is better wrt. to optimizations by C-compilers, as there first
>> is the whole address computation, and then the cast to volatile.
>> If we use
>>         _age.top()
>> with
>>         idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
>> compilers don't optimize that well.  (We saw this on hpia64.)
>> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
>> the OrderAccess, which is useless overhead.
>>
>> Best regards,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 18. Dezember 2012 01:24
>> To: Lindenmaier, Goetz
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>
>> Hi Goetz,
>>
>> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Once more, with webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>>
>> I can see that this function needs a storestore barrier:
>>
>>     237   void set_empty() {
>>     238     _bottom = 0;
>>     239     _age.set(0);
>>     240   }
>>
>> to preserve ordering. Are there other functions to which we can
>> constrain the loadload and storestore barriers rather than using the
>> setters/getters the way you have defined? This is always about a pair
>> (sometimes groups) of accesses so I'd rather deal with the pairs than
>> treat each field as if it were a Java volatile.
>>
>> Thanks,
>> David Holmes
>>
>>
>>> Sorry for that.
>>>
>>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>>
>>> On Platfoms with weak memory ordering the taskqueue is not accessed
>>> properly, as the accesses to the fields _bottom and _age are not ordered
>>> correctly. Volatile is not sufficient to enforce this, because it depends on
>>> what the compiler assumes to be necessary for volatile variables.
>>>
>>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
>>> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
>>> use the getter/setter methods to access _bottom, _age or the subfields of _age.
>>> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>>>
>>> The OrderAccess routines do simple load/stores on x86_64.
>>>
>>> I want to discuss this change here and would like very much to see it taking
>>> it's way into OpenJDK to support ports on platforms with weak memory
>>> ordering, and, in particular, our PPC port.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: taskqueue-failures.txt
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20121220/9ce08f58/taskqueue-failures-0001.txt 

From neugens at redhat.com  Thu Dec 20 04:04:15 2012
From: neugens at redhat.com (Mario Torre)
Date: Thu, 20 Dec 2012 13:04:15 +0100
Subject: HotSpot Changes in 7u
In-Reply-To: <50D2C0E7.6080903@oracle.com>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
	<50D2C0E7.6080903@oracle.com>
Message-ID: <1356005055.25310.27.camel@pegasus>

Il giorno gio, 20/12/2012 alle 17.40 +1000, David Holmes ha scritto:

> I'd suggest approaching the original engineers who sponsored these 
> fixes. But please bear in mind that we are hitting an extremely busy 
> period with JDK 8.

We could offer quality manpower if we had access to those repos like the
rest of the jdk.

Cheers,
Mario



From karen.kinnear at oracle.com  Thu Dec 20 05:06:35 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 20 Dec 2012 08:06:35 -0500
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <7272B689-848F-4B75-9D3A-C870A1143EF1@oracle.com>

Vote: yes

thanks,
Karen

On Dec 19, 2012, at 11:20 PM, Bengt Rutisson wrote:

> 
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
> 
> Stefan is on his third year as a Committer on the HSX project. He is a key contributor in the Hotspot's GC group, working on all GCs.  He has contributed 32 significant changesets as a Committer and is thus well-qualified to be a Reviewer on the HSX project.
> 
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week voting period).
> 
> Only current HSX project Reviewers [2] are eligible to vote on this nomination.
> 
> For Three-Vote Consensus voting instructions, see [3].
> 
> Regards,
> Bengt Rutisson
> 
> [0] http://openjdk.java.net/census/#hsx
> [1] http://openjdk.java.net/bylaws#reviewer
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://openjdk.java.net/bylaws#three-vote-consensus
> 


From zhengyu.gu at oracle.com  Thu Dec 20 06:08:27 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 20 Dec 2012 09:08:27 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <CAHjP37HwCcQm77Umec157h4SRrA=Anuxfc3_0vriypn3ZtFSWw@mail.gmail.com>
References: <50CF7C73.7010608@oracle.com>	<50CFD7CF.1010408@oracle.com>	<50D08120.2020306@oracle.com>	<50D0FC4C.4050009@oracle.com>	<CAHjP37Fdp5uWd3QVa7+HOuExNoz6Cop_YSGmZzy4N6FyiOUqow@mail.gmail.com>	<50D11187.3000701@oracle.com>	<CAHjP37Hw8OQAyN2bUDGgGNG4AtRxex=nWA5Owow5y_fWbcUqsA@mail.gmail.com>	<50D11528.8000704@oracle.com>
	<CAHjP37HwCcQm77Umec157h4SRrA=Anuxfc3_0vriypn3ZtFSWw@mail.gmail.com>
Message-ID: <50D31BDB.6080000@oracle.com>

Sorry for replying late. This CR actually is less about class state, but 
about the accuracy between the number of classes vs. size of class metadata.

Current implementation uses the number of  entries in system dictionary 
for the number of classes, which is inaccurate, which it does not 
contain anonymous classes and can have multiple entries

Thanks,

-Zhengyu

On 12/18/2012 8:41 PM, Vitaly Davidovich wrote:
>
> OK yeah, that makes sense.  Looking at oops/InstanceKlass.hpp, it 
> looks like there's a precursor state(ClassState::allocated) in the VM.
>
> Sent from my phone
>
> On Dec 18, 2012 8:15 PM, "David Holmes" <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 19/12/2012 11:05 AM, Vitaly Davidovich wrote:
>
>         You sure define is last step? Even classloader javadoc says it
>         still
>         needs to be resolved (linked and verified, I presume).
>
>
>     Sorry I was being imprecise. After class definition the class is
>     loaded but may still need to be resolved (linked).
>
>     A loaded Class at the Java level can be in one of three states:
>     - loaded, unlinked, uninitialized
>     - loaded, linked, uninitialized
>     - loaded, linked, initialized
>
>     Thanks,
>     David
>
>         Sent from my phone
>
>         On Dec 18, 2012 7:59 PM, "David Holmes"
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>             On 19/12/2012 10:54 AM, Vitaly Davidovich wrote:
>
>                 David,
>
>                 I suspect this is referring to the fact that
>         InstanceKlass (VM
>                 representation of java.lang.Class) can be in several
>         states:
>                 defined/allocated, loaded, linked/verified, etc.
>
>
>             Okay. It would be good to be clear on that.
>
>                 Perhaps Classloader.define() and loadClass() are the
>         classloader
>                 level
>                 distinctions you're interested in?
>
>
>             define() is the final step of loadClass(): first find the
>         bytes for
>             the class then send them to the VM via defineClass to
>         actually load
>             the class. "define" is not a state at the Java level.
>
>             Thanks,
>             David
>
>
>                 Sent from my phone
>
>                 On Dec 18, 2012 6:30 PM, "David Holmes"
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
>         <mailto:david.holmes at oracle. <mailto:david.holmes at oracle.>__com
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>>> wrote:
>
>                      On 19/12/2012 12:43 AM, Zhengyu Gu wrote:
>
>                          Hi David,
>
>                          Thanks for reviewing.
>
>                          On 12/17/2012 9:41 PM, David Holmes wrote:
>
>                              Hi Zhengyu,
>
>                              On 18/12/2012 6:11 AM, Zhengyu Gu wrote:
>
>                                  Current NMT implementation reports
>         number of loaded
>                                  classes at query
>                                  time, but number of defined classes
>         is what is
>                 expected.
>
>                                  This changset reflects two major changes:
>
>                                  1. It counts number of defined
>         classes vs.
>                 number of
>                                  loaded classes
>
>
>                              Can you explain what the distinction is
>         please? I
>                 don't know
>                              what a
>                 "defined class" is.
>
>                 "defined class" refers to class definition
>         (InstanceKlass), "loaded
>                          class" refers to instance.
>
>
>                      Sorry that didn't help. I don't understand what
>         these two
>                 different
>                      things are (InstanceKlass vs. "instance" ???).
>         Can you
>                 explain in
>                      terms of Java level class loading - when is a class
>                 "defined" versus
>                 "loaded"?
>
>                      Thanks,
>                      David
>
>
>                                  2. It counts number of defined
>         classes for each
>                                  generation, vs. counts
>                                  at query time. In this way, the
>         number of defined
>                                  classes that NMT
>                                  reports, should match the
>         corresponding class
>                 metadata
>                                  data. As the
>                                  result, the data should be more accurate.
>
>
>                                  Webrev:
>         http://cr.openjdk.java.net/~____zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/%7E____zgu/8005048/webrev.00/>
>         <http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/%7E__zgu/8005048/webrev.00/>>
>         <http://cr.openjdk.java.net/~__zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/%7E__zgu/8005048/webrev.00/>
>         <http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>         <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>>>
>
>
>                              I think we could benefit from NMT_ONLY(x)
>         macros to
>                 get rid
>                              of the
>                              one-line conditional blocks eg in
>         instanceKlass.cpp
>
>                          After consulting Chris Plummer, it does not
>         have to
>                 exclude for
>                          embedded. But yes, have NMT_ONLY() macros
>         will be very
>                 helpful,
>                          I will
>                          keep this in mind.
>
>
>                              ---
>
>                              src/share/vm/oops/____instanceKlass.hpp
>
>                              + #if INCLUDE_NMT
>                              + static int number_of_instance_classes()
>         { return
>                              (int)_total_instanceKlass_____count; }
>                              +
>                              + private:
>                              + static volatile jint
>         _total_instanceKlass_count;
>                              + #endif
>
>                              Why are we mixing int and jint here?
>
>                          Yes, it is bad idea. Will change to "int"
>
>                          Thanks,
>
>                          -Zhengyu
>
>
>                              ---
>
>                              I can't comment on the detailed memory
>         management
>                 of the
>                              GenerationData.
>
>                              David
>                              -----
>
>
>
>                                  Thanks,
>
>                                  -Zhengyu
>

From gnu.andrew at redhat.com  Thu Dec 20 07:38:00 2012
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 20 Dec 2012 10:38:00 -0500 (EST)
Subject: HotSpot Changes in 7u
In-Reply-To: <50D2C0E7.6080903@oracle.com>
Message-ID: <1114081852.18426091.1356017880979.JavaMail.root@redhat.com>

----- Original Message -----
> Hi Andrew,
> 
> cc'ing hotspot-dev
> 
> On 20/12/2012 3:11 AM, Andrew Hughes wrote:
> > Hi,
> >
> > What is the process for getting into HotSpot changes into 7u?
> > Can individual changesets be suggested and committed or do we have
> > to wait for a bulk update?  And who decides what goes in these bulk
> > updates?
> 
> Disclaimer: This is my observation not a reflection of any written
> policies etc.
> 

Understood.  We probably do need a written policy on this on the 7u
pages as it's not obvious what happens here.

Edvard?  Dalibor?

> Most (all?) Hotspot changes come in via the hsX forest (currently
> hs24
> for 7u12). Most backports come about from things "we" know we need in
> 7;
> some come from individual engineers sponsoring the jdk8 change and
> then
> the backport (I've done a few of those).
> 
> Individual changesets can be suggested, but only hsx committers can
> commit them, so you likely need a sponsor (as was likely needed for
> the
> 8/hs25 changeset anyway). The decision process is similar for 7u in
> general - we need to look at the nature of the problem and the fix
> and
> whether it is suitable for an update release (ie we won't backport
> perm-gen removal just because someone asks :) ). Backport complexity
> can
> also be an issue because of the significant changes between 7u and
> present 8 hotspot sources.

Is this the same JPRT issue as with HotSpot in OpenJDK8?  Is there any
progress on resolving this?

> 
> > We'd like to see the following changesets in 7u:
> >
> > 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
> > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/75982791ddb6
> 
> This seems reasonable to me. Though I will note that a few developers
> on
> the JDK disliked the appearance of the ""**NOTICE** Dtrace support
> disabled: ..." message in their build output.
> 

I'm not aware of these messages.  Do you have a link to this issue?

> > 8000622: Forgot to hg add and check in test for JDK-7170638
> > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/26351ce8c4b0
> 
> Again seems reasonable to me.
> 

Yeah, it's really part of 7170638.

> > 8000780: make Zero build and run with JDK8
> > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5
> 
> And again.
> 

The alternative without this fix is that Zero doesn't currently build
on 7u.  So it's pretty necessary :-)

> I'd suggest approaching the original engineers who sponsored these
> fixes. But please bear in mind that we are hitting an extremely busy
> period with JDK 8.
> 

Ok.  This sounds like more reason to expedite the process of opening up
the process of committing HotSpot fixes to those outside Oracle.  The current
system is creating unnecessary bottlenecks.

All three of these patches relate to functionality which, I believe, is never
used by Oracle (SystemTap & Zero), but is important to Red Hat and the various
GNU/Linux distributions.

> David
> -----
> 
> > Thanks,
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From coleen.phillimore at oracle.com  Thu Dec 20 07:40:56 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 20 Dec 2012 10:40:56 -0500
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <50D33188.3050602@oracle.com>


Vote: yes

On 12/19/2012 11:20 PM, Bengt Rutisson wrote:
>
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
>
> Stefan is on his third year as a Committer on the HSX project. He is a 
> key contributor in the Hotspot's GC group, working on all GCs.  He has 
> contributed 32 significant changesets as a Committer and is thus 
> well-qualified to be a Reviewer on the HSX project.
>
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week 
> voting period).
>
> Only current HSX project Reviewers [2] are eligible to vote on this 
> nomination.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> Regards,
> Bengt Rutisson
>
> [0] http://openjdk.java.net/census/#hsx
> [1] http://openjdk.java.net/bylaws#reviewer
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://openjdk.java.net/bylaws#three-vote-consensus
>


From coleen.phillimore at oracle.com  Thu Dec 20 07:47:13 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 20 Dec 2012 10:47:13 -0500
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <50D0F0DB.50900@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50D0A247.20502@oracle.com> <50D0F0DB.50900@oracle.com>
Message-ID: <50D33301.2030400@oracle.com>


Looks good, Joel.
Thanks,
Coleen

On 12/18/2012 05:40 PM, David Holmes wrote:
> Thumbs up.
>
> David
>
> On 19/12/2012 3:05 AM, Joel Borggr?n-Franck wrote:
>> New webrev up:
>>
>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/
>>
>> - I had to rename the field name for the type annotation byte[] in
>> Field, Constructor and Method.
>>
>> Also fixed:
>>
>> - I fixed the mapfile that got reindented.
>> - Added back a comment that I accidentally removed.
>>
>> cheers
>> /Joel
>>
>> On 12/17/2012 05:47 PM, Joel Borggr?n-Franck wrote:
>>> Hi,
>>>
>>> Here is a webrev for adding VM support for type annotation reflection:
>>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>>>
>>> Type annotations are coming with JDK 8, the proposed language changes
>>> can be found from here:
>>> http://openjdk.java.net/projects/type-annotations/
>>>
>>> Since runtime visible type annotations probably won't be that common I
>>> have tried to minimise overhead when there are no type annotations.
>>> This is done by adding a pointer to a type annotation Annotations
>>> instance from the regular annotations Annotations instance, see
>>> annotations.hpp. This means that if there are no runtime visible
>>> annotations there is no additional overhead with this patch since no
>>> Annotations instance will be allocated at all. If there is runtime
>>> visible annotations but no runtime visible type annotations there is
>>> an additional overhead of 1 pointer with this patch. If you use type
>>> annotations there will also be storage overhead, but that is to be
>>> expected.
>>>
>>> This patch also fixes that Annotations were never deallocated when
>>> InstanceKlass::deallocate_contents() were called.
>>>
>>> There is currently no redefineClass support for type annotations. This
>>> will be added later. In order avoid ship possibly broken bytes to
>>> java-land, type annotations are nulled out and deallocated after a
>>> redefineClass.
>>>
>>> This patch also exports a new method from jvm.h,
>>> JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are
>>> included for review.
>>>
>>> Testing done:
>>> - vm.quick.testlis both on b67 and on a jdk that is patched with the
>>> new fields to Field, Method and Constructor
>>> - jprt full forrest build
>>> - jdk_lang in both b67 and the patched jdk
>>> - manual tests that we get the correct bytes out from the VM. These
>>> tests can be added once some more changes have propagated from the jdk
>>> repo
>>>
>>> FYI, The initial set of jdk changes are being reviewed on
>>> core-libs-dev:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html 
>>>
>>>
>>>
>>> cheers
>>> /Joel
>>>


From eric.mccorkle at oracle.com  Thu Dec 20 08:01:58 2012
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 20 Dec 2012 11:01:58 -0500
Subject: Review request:Updated JDK-8004728 Add hotspot support for
	parameter reflection
In-Reply-To: <50D2C1E3.6000607@oracle.com>
References: <50D2197E.6090201@oracle.com> <50D2C1E3.6000607@oracle.com>
Message-ID: <50D33676.1010106@oracle.com>

On 12/20/12 02:44, David Holmes wrote:
>> The open webrev is here:
>> http://oklahoma.us.oracle.com/~cphillim/webrev/eric.webrev2/
> 
> That's not an open webrev :)
> 
> Please relocate to cr.openjdk.java.net
> 

Argh!  Here it is:

http://cr.openjdk.java.net/~coleenp/JDK-8004728/



From eric.mccorkle at oracle.com  Thu Dec 20 08:06:54 2012
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 20 Dec 2012 11:06:54 -0500
Subject: Review request:Updated JDK-8004728 Add hotspot support for
	parameter reflection
In-Reply-To: <50D2D658.9060206@oracle.com>
References: <50D2197E.6090201@oracle.com> <50D2D658.9060206@oracle.com>
Message-ID: <50D3379E.10601@oracle.com>

On 12/20/12 04:11, Joel Borggr?n-Franck wrote:

> Hi Eric,
> 
> I looked over the code since I have been doing changes in the same area
> for type annotations. A few comments:
> 
> In vmSymbols.hpp:
> 
> 239   template(executable_name,  "executable")
> 
> and
> 
> 477   template(executable_signature, "Ljava/lang/reflect/executable;")
> 
> do you need to add these? if so shouldn't these be 'Executable' with a
> capital E? I noticed you add Parameter to systemDictionary.hpp but not
> Executable is this intentional?

Sorry, you're looking at a slightly out of date version.  Look here:

http://cr.openjdk.java.net/~coleenp/JDK-8004728/

> 
> jvm.cpp:
> 
> 1580   // method is a handle to a java.lang.reflect.Method object
> 1581   Method* const m = jvm_get_method_common(method, CHECK_NULL)
> 
> Nit, I don't think this comment is correct in a non-permgen world.

That comment should go anyway.  That was to help me figure out the
meanings of the various different handles that exist.

From jon.masamitsu at oracle.com  Thu Dec 20 09:13:57 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 20 Dec 2012 09:13:57 -0800
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <50D34755.2010903@oracle.com>

Vote: yes

On 12/19/12 20:20, Bengt Rutisson wrote:
>
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
>
> Stefan is on his third year as a Committer on the HSX project. He is a 
> key contributor in the Hotspot's GC group, working on all GCs.  He has 
> contributed 32 significant changesets as a Committer and is thus 
> well-qualified to be a Reviewer on the HSX project.
>
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week 
> voting period).
>
> Only current HSX project Reviewers [2] are eligible to vote on this 
> nomination.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> Regards,
> Bengt Rutisson
>
> [0] http://openjdk.java.net/census/#hsx
> [1] http://openjdk.java.net/bylaws#reviewer
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://openjdk.java.net/bylaws#three-vote-consensus
>

From volker.simonis at gmail.com  Thu Dec 20 10:15:25 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 20 Dec 2012 19:15:25 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <50D26B81.8080903@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
Message-ID: <CA+3eh110wMRhPh=c9MLfhV9YGyAJnFTnUBi4JSHPvfyXf=Bcww@mail.gmail.com>

Hi David,

we've already had several of these discussions and you always mention
that either "you don't have these weak memory model problems although
you have a PPC port" or "you've already fixed all the weak memory
model related problems because you have a PPC port". Now as Goetz
mentioned,  we don't know very much about your PPC port except that it
is 32-bit only and that it is used in embedded scenarios. Is this
true? We don't have any expertise in the embedded world and we don't
know what concrete implementations of the Power architecture are
commonly used in that area but we would be happy to hear more about
it.

Our PPC port is 64-bit only and we support Power 5,6 and 7 running
Linux and AIX in server scenarios. Our VM usually runs on big servers
with at least 4 but often more (up to 32) cores and big heaps (>1GB up
to 32GB). Moreover we also support IA64 which is another weak memory
architecture running Linux, Windows and HPUX. Since our VM runs in
productive environments since years we've detected quite some memory
ordering related problems and we've always tried to fix them as
conservatively as possible with regard to shared changes. Because our
proprietary VM also supports the platforms supported by Oracle (i.e.
AMD64 and SPARC) and because many of our customers are productively
using them, we especially paid close attention that our changes for
weak memory architectures won't affect the performance on the existing
Oracle platforms at all and as far as our measurements show this isn't
the case.

You mentioned that our proposed changes don't conform to the style you
currently use in hotspot's lock-free code. That may be true, but that
doesn't necessarily means that that current lock-free code in hotspot
is always correct. The simple example posted by Goetz in
taskqueue-failures.txt shows quite the opposite.

We really think that our changes are mature (our product uses them
since years), proven (on many big customer installations), easy to
understand and non-intrusive in the sense that they don't affect your
supported platforms in a measurable way. And they are absolutely
necessary if you want to seriously port the HotSpot to a weak-memory
architecture like Power or Itanium.

Therefor we would be deeply grateful if you could consider these
changes for inclusion into OpenJDK. Should you encounter any problems
on your platforms with these changes we would me more that happy to
assist you.


Thanks a lot for your patience and support,
Volker

On Thu, Dec 20, 2012 at 2:36 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
>>
>> Hi David,
>>
>> first, thanks for the fast replies. Sorry it took me a day now!
>
>
> No problem. I can't guarantee response times either :)
>
>
>>> I didn't say that. I said these two need to be ordered and asked which
>>> other paired accesses to these variables need to be ordered.
>>
>> Together with a colleague I looked at the code. To us it seems
>> very hard to identify places where access ordering is not needed.
>> Especially we think there will be places in the users of the
>> task queue that would need barriers to ensure ordering.
>> But we think, the algorithm should be self-contained, doing all the
>> required ordering itself.
>
>
> I agree the algorithm should be self-contained. My point is that in other
> places where we implement lock-free algorithm was put in the barriers/fences
> in the algorithmic code in the places needed we don't automatically wrap all
> of the variables accesses with code that introduces pre/post barriers (of
> whatever form).
>
>
>> Further, a barrier will spoil performance on x86 etc, because there it
>> issues a lock instruction, which is not needed.
>
>
> You issue the appropriate barrier/fence for the situation and they should be
> implemented in whatever form needed for the given platform (modulo
> OrderAccess is far from perfect and has some outstanding issues).
>
>
>>> I said that what you were doing was effectively treating the C++
>>> variables
>>> as if they were Java volatile variables. That's not the way we handle
>>> these issues in the VM we tend to place fences/barriers at the places in
>>> lock-free algorithms that need them, rather than wrap the variables in
>>> accessors that impose fences/barriers that are not always needed.
>>
>>
>> As we understand, the C compilers on x86, sparc etc, enforce far more
>> than required to implement C++ volatile, basically treating the fields
>> like Java volatiles.  Therefore your code is fine on your platforms.
>
>
> I think you are confusing things. The existing C/C++ compilers do very
> little in regard to "volatile". It is only the latest multi-threading
> variant of the C++ standard that even addresses this! Our C/C++ compilers
> never issue any kind of memory barriers in response to a load/store of a
> volatile variable.
>
>
>> The C++ compilers on PPC optimize far more, maxing out
>> what the standard allows and the processer supports, leading to
>> immediate errors, but also to very subtle ones.
>>
>> Our change makes explicit what the C compilers (except for PPC) do
>> anyways, and what is required by the algorithm. (Maybe one could now
>> even omit the volatile keywords - but we dare not try.) Thus, we get
>> it right without any overhead on your platforms.
>
>
> This is getting things confused. The lock-free algorithms should be written
> for the most lenient of memory-models and make no assumptions about
> ordering. They should use the appropriate OrderAccess method where needed
> for algorithmic correctness.
>
> You proposal wraps the C variable in accessors that use OrderAccess
> operations on every access - in a similar way to how we have to handle Java
> volatile accesses. And as I have said that is not the style we use in
> hotspot's lock-free code. This has nothing to do with our compiler versus
> your compiler (though if you have one that issues memory-barriers directly
> then you'll get too much overhead.)
>
>
>>> Though we have not run into this particular issue. Did
>>> it arise in the context of a particular GC?
>>
>> Issues are only on PPC, at least in parallelScavenge. I reproduced
>> some of the immediate errors, but I don't think this really helps with
>> the discussion.  I will try G1 soon.  Tell me if you want to know
>> more, then I'll try to come up with a wrap-up of our past fixes.
>
>
> We have a PPC product and as I said we have not encountered this problem,
> but we also run with limited GCs so may not have been exercising this code.
>
> Thanks,
> David
>
>
>> Best regards,
>>    Goetz.
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 18. Dezember 2012 12:19
>> To: Lindenmaier, Goetz
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>
>> Hi Goetz,
>>
>> On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>>>
>>> Hi David,
>>>
>>> why do you think only these two accesses have to be ordered?
>>
>>
>> I didn't say that. I said these two need to be ordered and asked which
>> other paired accesses to these variables need to be ordered.
>>
>>> As I understand, any two accesses in one thread to these fields have to
>>> be
>>> orderered and must be written to memory to become visible in the proper
>>> order
>>> to other threads.
>>
>>
>> That depends on how they are used. It is the overall lock-free algorithm
>> that is important here. There may be places where the order of access
>> does not matter (and there may not be).
>>
>>> The PPC compiler really takes all advantages given by the
>>> C-Standard to optimize this, and the processor reorders heavily.
>>
>>
>> Yes I understand. Though we have not run into this particular issue. Did
>> it arise in the context of a particular GC?
>>
>>> The specification of volatile in
>>>          Age get() const volatile { return _data; }
>>> says that it must be read from memory, not that it can not be reordered.
>>
>>
>> I didn't say anything about C/C++ volatile (which doesn't even say it
>> must be read from memory - except perhaps in latest MT C++ standard?). I
>> said that what you were doing was effectively treating the C++ variables
>> as if they were Java volatile variables. That's not the way we handle
>> these issues in the VM we tend to place fences/barriers at the places in
>> lock-free algorithms that need them, rather than wrap the variables in
>> accessors that impose fences/barriers that are not always needed.
>>
>> Cheers,
>> David
>>
>>> Also, doing
>>>         OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
>>> is better wrt. to optimizations by C-compilers, as there first
>>> is the whole address computation, and then the cast to volatile.
>>> If we use
>>>         _age.top()
>>> with
>>>         idx_t top() const volatile { return
>>> OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
>>> compilers don't optimize that well.  (We saw this on hpia64.)
>>> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
>>> the OrderAccess, which is useless overhead.
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Dienstag, 18. Dezember 2012 01:24
>>> To: Lindenmaier, Goetz
>>> Cc: hotspot-dev at openjdk.java.net
>>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>>
>>> Hi Goetz,
>>>
>>> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>>>>
>>>> Hi,
>>>>
>>>> Once more, with webrev:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>>>
>>>
>>> I can see that this function needs a storestore barrier:
>>>
>>>     237   void set_empty() {
>>>     238     _bottom = 0;
>>>     239     _age.set(0);
>>>     240   }
>>>
>>> to preserve ordering. Are there other functions to which we can
>>> constrain the loadload and storestore barriers rather than using the
>>> setters/getters the way you have defined? This is always about a pair
>>> (sometimes groups) of accesses so I'd rather deal with the pairs than
>>> treat each field as if it were a Java volatile.
>>>
>>> Thanks,
>>> David Holmes
>>>
>>>
>>>> Sorry for that.
>>>>
>>>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>>>
>>>> On Platfoms with weak memory ordering the taskqueue is not accessed
>>>> properly, as the accesses to the fields _bottom and _age are not ordered
>>>> correctly. Volatile is not sufficient to enforce this, because it
>>>> depends on
>>>> what the compiler assumes to be necessary for volatile variables.
>>>>
>>>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and
>>>> use methods from
>>>> OrderAccess to access the fields in _age as well as _bottom.   Further
>>>> the code must always
>>>> use the getter/setter methods to access _bottom, _age or the subfields
>>>> of _age.
>>>> On the other hand we can relax constraints for accesses to locals oldAge
>>>> and newAge.
>>>>
>>>> The OrderAccess routines do simple load/stores on x86_64.
>>>>
>>>> I want to discuss this change here and would like very much to see it
>>>> taking
>>>> it's way into OpenJDK to support ports on platforms with weak memory
>>>> ordering, and, in particular, our PPC port.
>>>>
>>>> Best regards,
>>>>      Goetz.
>>>>
>>>>
>

From christian.thalinger at oracle.com  Thu Dec 20 10:49:35 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 20 Dec 2012 10:49:35 -0800
Subject: RFR (S): 8005345: JSR 292: JDK performance tweaks
Message-ID: <CF992EC2-68CA-47A7-92E2-A9B529F48D4A@oracle.com>

http://cr.openjdk.java.net/~twisti/8005345

8005345: JSR 292: JDK performance tweaks
Reviewed-by:

Add a couple of DontInline annotations, move ForceInline annotations
so we don't inline the wrong methods, make AsVarargsCollector fields
final, inline Class.cast into ValueConversions.castReference because
we can't annotation Class.cast with ForceInline, yet.

src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
src/share/classes/java/lang/invoke/LambdaForm.java
src/share/classes/java/lang/invoke/MethodHandleImpl.java
src/share/classes/sun/invoke/util/ValueConversions.java


From vladimir.kozlov at oracle.com  Thu Dec 20 10:54:56 2012
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 20 Dec 2012 10:54:56 -0800
Subject: RFR (S): 8005345: JSR 292: JDK performance tweaks
In-Reply-To: <CF992EC2-68CA-47A7-92E2-A9B529F48D4A@oracle.com>
References: <CF992EC2-68CA-47A7-92E2-A9B529F48D4A@oracle.com>
Message-ID: <50D35F00.3030603@oracle.com>

Good.

Thanks,
Vladimir

On 12/20/12 10:49 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8005345
>
> 8005345: JSR 292: JDK performance tweaks
> Reviewed-by:
>
> Add a couple of DontInline annotations, move ForceInline annotations
> so we don't inline the wrong methods, make AsVarargsCollector fields
> final, inline Class.cast into ValueConversions.castReference because
> we can't annotation Class.cast with ForceInline, yet.
>
> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> src/share/classes/java/lang/invoke/LambdaForm.java
> src/share/classes/java/lang/invoke/MethodHandleImpl.java
> src/share/classes/sun/invoke/util/ValueConversions.java
>

From zhengyu.gu at oracle.com  Thu Dec 20 11:12:55 2012
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 20 Dec 2012 14:12:55 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D0CB15.8060708@oracle.com>
References: <50CF7C73.7010608@oracle.com>	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>	<50D08386.6060200@oracle.com>	<CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>	<CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>	<50D08E20.3000703@oracle.com>
	<50D0CB15.8060708@oracle.com>
Message-ID: <50D36337.50304@oracle.com>

Round 3:  also decrement instance counter when unloads class loader data.

http://cr.openjdk.java.net/~zgu/8005048/webrev.02/

Thanks,

-Zhengyu

On 12/18/2012 2:59 PM, Zhengyu Gu wrote:
> Hi,
>
> I updated the webrev to reflect the suggestions.
>
> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.01/
>
> Thanks,
>
> -Zhengyu
>
>
> On 12/18/2012 10:39 AM, Zhengyu Gu wrote:
>> Not likely, but I will convert it to loop, just to eliminate the 
>> concerns ...
>>
>> Thanks,
>>
>> -Zhengyu
>>
>> On 12/18/2012 10:34 AM, Vitaly Davidovich wrote:
>>>
>>> By the way, no chance of blowing the stack here if small stack size 
>>> is used, right?
>>>
>>> Sent from my phone
>>>
>>> On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com 
>>> <mailto:vitalyd at gmail.com>> wrote:
>>>
>>>     Ah yes, I see the destructor in MemRecorder now - thanks.
>>>
>>>     Sent from my phone
>>>
>>>     On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>
>>>         Hi Vitaly,
>>>
>>>         Thanks for reviewing.
>>>
>>>         On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>>>
>>>>         Hi Zhengyu,
>>>>
>>>>         In GenerationData::reset() you delete _recorder_list.  Since
>>>>         this list is built from callers (I.e. caller adds recorders)
>>>>         is it good to delete the head here? I guess this class takes
>>>>         ownership of added recorders?
>>>>
>>>         Yes, releasing recorder via
>>>         MemTracker::release_thread_recorder() is cleaner solution, I
>>>         will make change.
>>>
>>>
>>>>         If so, who deletes the rest of the recorders in the list? I'd
>>>>         expect to see a loop here deleting all recorders in the list.
>>>>
>>>         Recorder deletion in coded in recursive manner, in
>>>         MemRecorer::~MemRecorder()
>>>
>>>         if (_next != NULL)  delete _next;
>>>
>>>         Thanks,
>>>
>>>         -Zhengyu
>>>
>>>
>>>>         Thanks
>>>>
>>>>         Sent from my phone
>>>>
>>>>         On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>>
>>>>             Current NMT implementation reports number of loaded
>>>>             classes at query time, but number of defined classes is
>>>>             what is expected.
>>>>
>>>>             This changset reflects two major changes:
>>>>
>>>>             1. It counts number of defined classes vs. number of
>>>>             loaded classes
>>>>             2. It counts number of defined classes for each
>>>>             generation, vs. counts at query time. In this way, the
>>>>             number of defined classes that NMT reports, should match
>>>>             the corresponding class metadata data. As the result, the
>>>>             data should be more accurate.
>>>>
>>>>
>>>>             Webrev:
>>>>             http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>>>>
>>>>
>>>>             Thanks,
>>>>
>>>>             -Zhengyu
>>>>

From christian.thalinger at oracle.com  Thu Dec 20 11:19:57 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 20 Dec 2012 11:19:57 -0800
Subject: RFR (S): 8005345: JSR 292: JDK performance tweaks
In-Reply-To: <50D35F00.3030603@oracle.com>
References: <CF992EC2-68CA-47A7-92E2-A9B529F48D4A@oracle.com>
	<50D35F00.3030603@oracle.com>
Message-ID: <488D11C5-4FA5-4C3A-A4D6-A30EEF8F40B3@oracle.com>

Thank you, Vladimir.  -- Chris

On Dec 20, 2012, at 10:54 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Good.
> 
> Thanks,
> Vladimir
> 
> On 12/20/12 10:49 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8005345
>> 
>> 8005345: JSR 292: JDK performance tweaks
>> Reviewed-by:
>> 
>> Add a couple of DontInline annotations, move ForceInline annotations
>> so we don't inline the wrong methods, make AsVarargsCollector fields
>> final, inline Class.cast into ValueConversions.castReference because
>> we can't annotation Class.cast with ForceInline, yet.
>> 
>> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> src/share/classes/java/lang/invoke/LambdaForm.java
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java
>> src/share/classes/sun/invoke/util/ValueConversions.java
>> 


From christian.thalinger at oracle.com  Thu Dec 20 11:17:21 2012
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Thu, 20 Dec 2012 19:17:21 +0000
Subject: hg: hsx/hotspot-main/jdk: 8005345: JSR 292: JDK performance tweaks
Message-ID: <20121220191824.B79BA472F8@hg.openjdk.java.net>

Changeset: 12fa4d7ecaf5
Author:    twisti
Date:      2012-12-20 11:16 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12fa4d7ecaf5

8005345: JSR 292: JDK performance tweaks
Reviewed-by: kvn, jrose

! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/share/classes/java/lang/invoke/LambdaForm.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/sun/invoke/util/ValueConversions.java


From karen.kinnear at oracle.com  Thu Dec 20 11:35:02 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 20 Dec 2012 14:35:02 -0500
Subject: Code review request: JDK-8005048,
	NMT: #loaded classes needs to just show the # defined classes
In-Reply-To: <50D36337.50304@oracle.com>
References: <50CF7C73.7010608@oracle.com>	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>	<50D08386.6060200@oracle.com>	<CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>	<CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>	<50D08E20.3000703@oracle.com>
	<50D0CB15.8060708@oracle.com> <50D36337.50304@oracle.com>
Message-ID: <8D3BAB0A-0FBF-4882-9592-30642820D95F@oracle.com>

Zhengyu.

Looks good and thank you.

instanceKlass.cpp line 370
deplicated -> duplicated

thanks,
Karen

On Dec 20, 2012, at 2:12 PM, Zhengyu Gu wrote:

> Round 3:  also decrement instance counter when unloads class loader data.
> 
> http://cr.openjdk.java.net/~zgu/8005048/webrev.02/
> 
> Thanks,
> 
> -Zhengyu
> 
> On 12/18/2012 2:59 PM, Zhengyu Gu wrote:
>> Hi,
>> 
>> I updated the webrev to reflect the suggestions.
>> 
>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.01/
>> 
>> Thanks,
>> 
>> -Zhengyu
>> 
>> 
>> On 12/18/2012 10:39 AM, Zhengyu Gu wrote:
>>> Not likely, but I will convert it to loop, just to eliminate the concerns ...
>>> 
>>> Thanks,
>>> 
>>> -Zhengyu
>>> 
>>> On 12/18/2012 10:34 AM, Vitaly Davidovich wrote:
>>>> 
>>>> By the way, no chance of blowing the stack here if small stack size is used, right?
>>>> 
>>>> Sent from my phone
>>>> 
>>>> On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>>>> 
>>>>    Ah yes, I see the destructor in MemRecorder now - thanks.
>>>> 
>>>>    Sent from my phone
>>>> 
>>>>    On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>> 
>>>>        Hi Vitaly,
>>>> 
>>>>        Thanks for reviewing.
>>>> 
>>>>        On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>>>> 
>>>>>        Hi Zhengyu,
>>>>> 
>>>>>        In GenerationData::reset() you delete _recorder_list.  Since
>>>>>        this list is built from callers (I.e. caller adds recorders)
>>>>>        is it good to delete the head here? I guess this class takes
>>>>>        ownership of added recorders?
>>>>> 
>>>>        Yes, releasing recorder via
>>>>        MemTracker::release_thread_recorder() is cleaner solution, I
>>>>        will make change.
>>>> 
>>>> 
>>>>>        If so, who deletes the rest of the recorders in the list? I'd
>>>>>        expect to see a loop here deleting all recorders in the list.
>>>>> 
>>>>        Recorder deletion in coded in recursive manner, in
>>>>        MemRecorer::~MemRecorder()
>>>> 
>>>>        if (_next != NULL)  delete _next;
>>>> 
>>>>        Thanks,
>>>> 
>>>>        -Zhengyu
>>>> 
>>>> 
>>>>>        Thanks
>>>>> 
>>>>>        Sent from my phone
>>>>> 
>>>>>        On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>>> 
>>>>>            Current NMT implementation reports number of loaded
>>>>>            classes at query time, but number of defined classes is
>>>>>            what is expected.
>>>>> 
>>>>>            This changset reflects two major changes:
>>>>> 
>>>>>            1. It counts number of defined classes vs. number of
>>>>>            loaded classes
>>>>>            2. It counts number of defined classes for each
>>>>>            generation, vs. counts at query time. In this way, the
>>>>>            number of defined classes that NMT reports, should match
>>>>>            the corresponding class metadata data. As the result, the
>>>>>            data should be more accurate.
>>>>> 
>>>>> 
>>>>>            Webrev:
>>>>>            http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>>>>> 
>>>>> 
>>>>>            Thanks,
>>>>> 
>>>>>            -Zhengyu
>>>>> 


From goetz.lindenmaier at sap.com  Thu Dec 20 12:23:50 2012
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 20 Dec 2012 21:23:50 +0100
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <50D26B81.8080903@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>

Hi David,

I understand that you want selected corrections, not the
solution we chose that does it everywhere. 

But do you agree that our solution does not introduce any
overhead on x86 and sparc?



I'll try to explain why I think this is the case using the 
example you brought up:

void set_empty() {  
  _bottom = 0;
  _age.set(0);
}

will result in something like

 x86_64                      our ppc                our ia64
 ------                      -------                --------
 movl 0, _bottom             swz                    st4.rel
 movq 0, _age                sd                     st8.rel    

which is correct on x86 and ia64, but wrong on power.

void set_empty() {  
  _bottom = 0;
  OrderAccess::storestore();
  _age.set(0);
}

will result in something like

 x86_64                      our ppc                our ia64
 ------                      -------                --------
 movl 0, _bottom             swz                    st4.rel
 movl 0, local_dummy         lwsync                 mf
 movq 0, _age                sd                     st8.rel

which is correct, but inefficient on x86_64 (a bit) and ia64.

while

void set_empty() {  
  _bottom =  0;
  OrderAccess::release_store_ptr((volatile intptr_t*) &_age, 0);
}

will result in 

 movl 0, _bottom             swz                    st4.rel
 movq 0, _age                lwsync; sd             st8.rel

which is correct and efficient.



By the way, if you have a PPC port, do you have a machine to build 
and run the openJDK PPC port?

> (modulo OrderAccess is far from perfect and has some outstanding issues).
What are the problems of the OrderAccess implementation? 

Best regards,
  Goetz.  






-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Thursday, December 20, 2012 2:36 AM
To: Lindenmaier, Goetz
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): Memory ordering in taskqueue.hpp

On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
> first, thanks for the fast replies. Sorry it took me a day now!

No problem. I can't guarantee response times either :)

>> I didn't say that. I said these two need to be ordered and asked which
>> other paired accesses to these variables need to be ordered.
> Together with a colleague I looked at the code. To us it seems
> very hard to identify places where access ordering is not needed.
> Especially we think there will be places in the users of the
> task queue that would need barriers to ensure ordering.
> But we think, the algorithm should be self-contained, doing all the
> required ordering itself.

I agree the algorithm should be self-contained. My point is that in 
other places where we implement lock-free algorithm was put in the 
barriers/fences in the algorithmic code in the places needed we don't 
automatically wrap all of the variables accesses with code that 
introduces pre/post barriers (of whatever form).

> Further, a barrier will spoil performance on x86 etc, because there it
> issues a lock instruction, which is not needed.

You issue the appropriate barrier/fence for the situation and they 
should be implemented in whatever form needed for the given platform 
(modulo OrderAccess is far from perfect and has some outstanding issues).

>> I said that what you were doing was effectively treating the C++ variables
>> as if they were Java volatile variables. That's not the way we handle
>> these issues in the VM we tend to place fences/barriers at the places in
>> lock-free algorithms that need them, rather than wrap the variables in
>> accessors that impose fences/barriers that are not always needed.
>
> As we understand, the C compilers on x86, sparc etc, enforce far more
> than required to implement C++ volatile, basically treating the fields
> like Java volatiles.  Therefore your code is fine on your platforms.

I think you are confusing things. The existing C/C++ compilers do very 
little in regard to "volatile". It is only the latest multi-threading 
variant of the C++ standard that even addresses this! Our C/C++ 
compilers never issue any kind of memory barriers in response to a 
load/store of a volatile variable.

> The C++ compilers on PPC optimize far more, maxing out
> what the standard allows and the processer supports, leading to
> immediate errors, but also to very subtle ones.
>
> Our change makes explicit what the C compilers (except for PPC) do
> anyways, and what is required by the algorithm. (Maybe one could now
> even omit the volatile keywords - but we dare not try.) Thus, we get
> it right without any overhead on your platforms.

This is getting things confused. The lock-free algorithms should be 
written for the most lenient of memory-models and make no assumptions 
about ordering. They should use the appropriate OrderAccess method where 
needed for algorithmic correctness.

You proposal wraps the C variable in accessors that use OrderAccess 
operations on every access - in a similar way to how we have to handle 
Java volatile accesses. And as I have said that is not the style we use 
in hotspot's lock-free code. This has nothing to do with our compiler 
versus your compiler (though if you have one that issues memory-barriers 
directly then you'll get too much overhead.)

>> Though we have not run into this particular issue. Did
>> it arise in the context of a particular GC?
> Issues are only on PPC, at least in parallelScavenge. I reproduced
> some of the immediate errors, but I don't think this really helps with
> the discussion.  I will try G1 soon.  Tell me if you want to know
> more, then I'll try to come up with a wrap-up of our past fixes.

We have a PPC product and as I said we have not encountered this 
problem, but we also run with limited GCs so may not have been 
exercising this code.

Thanks,
David

> Best regards,
>    Goetz.
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Dienstag, 18. Dezember 2012 12:19
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> Hi Goetz,
>
> On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> why do you think only these two accesses have to be ordered?
>
> I didn't say that. I said these two need to be ordered and asked which
> other paired accesses to these variables need to be ordered.
>
>> As I understand, any two accesses in one thread to these fields have to be
>> orderered and must be written to memory to become visible in the proper order
>> to other threads.
>
> That depends on how they are used. It is the overall lock-free algorithm
> that is important here. There may be places where the order of access
> does not matter (and there may not be).
>
>> The PPC compiler really takes all advantages given by the
>> C-Standard to optimize this, and the processor reorders heavily.
>
> Yes I understand. Though we have not run into this particular issue. Did
> it arise in the context of a particular GC?
>
>> The specification of volatile in
>>          Age get() const volatile { return _data; }
>> says that it must be read from memory, not that it can not be reordered.
>
> I didn't say anything about C/C++ volatile (which doesn't even say it
> must be read from memory - except perhaps in latest MT C++ standard?). I
> said that what you were doing was effectively treating the C++ variables
> as if they were Java volatile variables. That's not the way we handle
> these issues in the VM we tend to place fences/barriers at the places in
> lock-free algorithms that need them, rather than wrap the variables in
> accessors that impose fences/barriers that are not always needed.
>
> Cheers,
> David
>
>> Also, doing
>>         OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
>> is better wrt. to optimizations by C-compilers, as there first
>> is the whole address computation, and then the cast to volatile.
>> If we use
>>         _age.top()
>> with
>>         idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
>> compilers don't optimize that well.  (We saw this on hpia64.)
>> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
>> the OrderAccess, which is useless overhead.
>>
>> Best regards,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 18. Dezember 2012 01:24
>> To: Lindenmaier, Goetz
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>
>> Hi Goetz,
>>
>> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Once more, with webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>>
>> I can see that this function needs a storestore barrier:
>>
>>     237   void set_empty() {
>>     238     _bottom = 0;
>>     239     _age.set(0);
>>     240   }
>>
>> to preserve ordering. Are there other functions to which we can
>> constrain the loadload and storestore barriers rather than using the
>> setters/getters the way you have defined? This is always about a pair
>> (sometimes groups) of accesses so I'd rather deal with the pairs than
>> treat each field as if it were a Java volatile.
>>
>> Thanks,
>> David Holmes
>>
>>
>>> Sorry for that.
>>>
>>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>>
>>> On Platfoms with weak memory ordering the taskqueue is not accessed
>>> properly, as the accesses to the fields _bottom and _age are not ordered
>>> correctly. Volatile is not sufficient to enforce this, because it depends on
>>> what the compiler assumes to be necessary for volatile variables.
>>>
>>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
>>> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
>>> use the getter/setter methods to access _bottom, _age or the subfields of _age.
>>> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>>>
>>> The OrderAccess routines do simple load/stores on x86_64.
>>>
>>> I want to discuss this change here and would like very much to see it taking
>>> it's way into OpenJDK to support ports on platforms with weak memory
>>> ordering, and, in particular, our PPC port.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>

From vitalyd at gmail.com  Thu Dec 20 12:43:56 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 20 Dec 2012 15:43:56 -0500
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>
Message-ID: <CAHjP37GerjPt3meYoj-tuk3ex37XNJbv1CniSEkW1JXfGy0BzQ@mail.gmail.com>

As an aside, how come storestore is not defined as "asm volatile ("" : : :
"memory");" on Linux x86/64?

Thanks

Sent from my phone
On Dec 20, 2012 3:24 PM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>
wrote:

> Hi David,
>
> I understand that you want selected corrections, not the
> solution we chose that does it everywhere.
>
> But do you agree that our solution does not introduce any
> overhead on x86 and sparc?
>
>
>
> I'll try to explain why I think this is the case using the
> example you brought up:
>
> void set_empty() {
>   _bottom = 0;
>   _age.set(0);
> }
>
> will result in something like
>
>  x86_64                      our ppc                our ia64
>  ------                      -------                --------
>  movl 0, _bottom             swz                    st4.rel
>  movq 0, _age                sd                     st8.rel
>
> which is correct on x86 and ia64, but wrong on power.
>
> void set_empty() {
>   _bottom = 0;
>   OrderAccess::storestore();
>   _age.set(0);
> }
>
> will result in something like
>
>  x86_64                      our ppc                our ia64
>  ------                      -------                --------
>  movl 0, _bottom             swz                    st4.rel
>  movl 0, local_dummy         lwsync                 mf
>  movq 0, _age                sd                     st8.rel
>
> which is correct, but inefficient on x86_64 (a bit) and ia64.
>
> while
>
> void set_empty() {
>   _bottom =  0;
>   OrderAccess::release_store_ptr((volatile intptr_t*) &_age, 0);
> }
>
> will result in
>
>  movl 0, _bottom             swz                    st4.rel
>  movq 0, _age                lwsync; sd             st8.rel
>
> which is correct and efficient.
>
>
>
> By the way, if you have a PPC port, do you have a machine to build
> and run the openJDK PPC port?
>
> > (modulo OrderAccess is far from perfect and has some outstanding issues).
> What are the problems of the OrderAccess implementation?
>
> Best regards,
>   Goetz.
>
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Thursday, December 20, 2012 2:36 AM
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> > first, thanks for the fast replies. Sorry it took me a day now!
>
> No problem. I can't guarantee response times either :)
>
> >> I didn't say that. I said these two need to be ordered and asked which
> >> other paired accesses to these variables need to be ordered.
> > Together with a colleague I looked at the code. To us it seems
> > very hard to identify places where access ordering is not needed.
> > Especially we think there will be places in the users of the
> > task queue that would need barriers to ensure ordering.
> > But we think, the algorithm should be self-contained, doing all the
> > required ordering itself.
>
> I agree the algorithm should be self-contained. My point is that in
> other places where we implement lock-free algorithm was put in the
> barriers/fences in the algorithmic code in the places needed we don't
> automatically wrap all of the variables accesses with code that
> introduces pre/post barriers (of whatever form).
>
> > Further, a barrier will spoil performance on x86 etc, because there it
> > issues a lock instruction, which is not needed.
>
> You issue the appropriate barrier/fence for the situation and they
> should be implemented in whatever form needed for the given platform
> (modulo OrderAccess is far from perfect and has some outstanding issues).
>
> >> I said that what you were doing was effectively treating the C++
> variables
> >> as if they were Java volatile variables. That's not the way we handle
> >> these issues in the VM we tend to place fences/barriers at the places in
> >> lock-free algorithms that need them, rather than wrap the variables in
> >> accessors that impose fences/barriers that are not always needed.
> >
> > As we understand, the C compilers on x86, sparc etc, enforce far more
> > than required to implement C++ volatile, basically treating the fields
> > like Java volatiles.  Therefore your code is fine on your platforms.
>
> I think you are confusing things. The existing C/C++ compilers do very
> little in regard to "volatile". It is only the latest multi-threading
> variant of the C++ standard that even addresses this! Our C/C++
> compilers never issue any kind of memory barriers in response to a
> load/store of a volatile variable.
>
> > The C++ compilers on PPC optimize far more, maxing out
> > what the standard allows and the processer supports, leading to
> > immediate errors, but also to very subtle ones.
> >
> > Our change makes explicit what the C compilers (except for PPC) do
> > anyways, and what is required by the algorithm. (Maybe one could now
> > even omit the volatile keywords - but we dare not try.) Thus, we get
> > it right without any overhead on your platforms.
>
> This is getting things confused. The lock-free algorithms should be
> written for the most lenient of memory-models and make no assumptions
> about ordering. They should use the appropriate OrderAccess method where
> needed for algorithmic correctness.
>
> You proposal wraps the C variable in accessors that use OrderAccess
> operations on every access - in a similar way to how we have to handle
> Java volatile accesses. And as I have said that is not the style we use
> in hotspot's lock-free code. This has nothing to do with our compiler
> versus your compiler (though if you have one that issues memory-barriers
> directly then you'll get too much overhead.)
>
> >> Though we have not run into this particular issue. Did
> >> it arise in the context of a particular GC?
> > Issues are only on PPC, at least in parallelScavenge. I reproduced
> > some of the immediate errors, but I don't think this really helps with
> > the discussion.  I will try G1 soon.  Tell me if you want to know
> > more, then I'll try to come up with a wrap-up of our past fixes.
>
> We have a PPC product and as I said we have not encountered this
> problem, but we also run with limited GCs so may not have been
> exercising this code.
>
> Thanks,
> David
>
> > Best regards,
> >    Goetz.
> >
> >
> > -----Original Message-----
> > From: David Holmes [mailto:david.holmes at oracle.com]
> > Sent: Dienstag, 18. Dezember 2012 12:19
> > To: Lindenmaier, Goetz
> > Cc: hotspot-dev at openjdk.java.net
> > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
> >
> > Hi Goetz,
> >
> > On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
> >> Hi David,
> >>
> >> why do you think only these two accesses have to be ordered?
> >
> > I didn't say that. I said these two need to be ordered and asked which
> > other paired accesses to these variables need to be ordered.
> >
> >> As I understand, any two accesses in one thread to these fields have to
> be
> >> orderered and must be written to memory to become visible in the proper
> order
> >> to other threads.
> >
> > That depends on how they are used. It is the overall lock-free algorithm
> > that is important here. There may be places where the order of access
> > does not matter (and there may not be).
> >
> >> The PPC compiler really takes all advantages given by the
> >> C-Standard to optimize this, and the processor reorders heavily.
> >
> > Yes I understand. Though we have not run into this particular issue. Did
> > it arise in the context of a particular GC?
> >
> >> The specification of volatile in
> >>          Age get() const volatile { return _data; }
> >> says that it must be read from memory, not that it can not be reordered.
> >
> > I didn't say anything about C/C++ volatile (which doesn't even say it
> > must be read from memory - except perhaps in latest MT C++ standard?). I
> > said that what you were doing was effectively treating the C++ variables
> > as if they were Java volatile variables. That's not the way we handle
> > these issues in the VM we tend to place fences/barriers at the places in
> > lock-free algorithms that need them, rather than wrap the variables in
> > accessors that impose fences/barriers that are not always needed.
> >
> > Cheers,
> > David
> >
> >> Also, doing
> >>         OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
> >> is better wrt. to optimizations by C-compilers, as there first
> >> is the whole address computation, and then the cast to volatile.
> >> If we use
> >>         _age.top()
> >> with
> >>         idx_t top() const volatile { return
> OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
> >> compilers don't optimize that well.  (We saw this on hpia64.)
> >> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
> >> the OrderAccess, which is useless overhead.
> >>
> >> Best regards,
> >>     Goetz.
> >>
> >>
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Dienstag, 18. Dezember 2012 01:24
> >> To: Lindenmaier, Goetz
> >> Cc: hotspot-dev at openjdk.java.net
> >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
> >>
> >> Hi Goetz,
> >>
> >> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> Once more, with webrev:
> >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
> >>
> >> I can see that this function needs a storestore barrier:
> >>
> >>     237   void set_empty() {
> >>     238     _bottom = 0;
> >>     239     _age.set(0);
> >>     240   }
> >>
> >> to preserve ordering. Are there other functions to which we can
> >> constrain the loadload and storestore barriers rather than using the
> >> setters/getters the way you have defined? This is always about a pair
> >> (sometimes groups) of accesses so I'd rather deal with the pairs than
> >> treat each field as if it were a Java volatile.
> >>
> >> Thanks,
> >> David Holmes
> >>
> >>
> >>> Sorry for that.
> >>>
> >>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
> >>>
> >>> On Platfoms with weak memory ordering the taskqueue is not accessed
> >>> properly, as the accesses to the fields _bottom and _age are not
> ordered
> >>> correctly. Volatile is not sufficient to enforce this, because it
> depends on
> >>> what the compiler assumes to be necessary for volatile variables.
> >>>
> >>> The fix is to pull getter/setter routines from Age to TaskQueueSuper
> and use methods from
> >>> OrderAccess to access the fields in _age as well as _bottom.   Further
> the code must always
> >>> use the getter/setter methods to access _bottom, _age or the subfields
> of _age.
> >>> On the other hand we can relax constraints for accesses to locals
> oldAge and newAge.
> >>>
> >>> The OrderAccess routines do simple load/stores on x86_64.
> >>>
> >>> I want to discuss this change here and would like very much to see it
> taking
> >>> it's way into OpenJDK to support ports on platforms with weak memory
> >>> ordering, and, in particular, our PPC port.
> >>>
> >>> Best regards,
> >>>      Goetz.
> >>>
> >>>
>

From john.r.rose at oracle.com  Thu Dec 20 13:10:17 2012
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 20 Dec 2012 13:10:17 -0800
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <50D0A247.20502@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50D0A247.20502@oracle.com>
Message-ID: <E94E29C4-857A-4A88-B61A-AA6F0DE08275@oracle.com>

This is good work.  You can count me as a reviewer.

One comment:  There are a couple of places where a field index is used as an annotation array index (one old one new).  I think it would be best to put an explicit range check like this:

-  if (md == NULL)
+  if (md == NULL || index() >= md->length())
     return NULL;
   return md->at(index());

There are two reasons:  First, although it is likely this is a needless check, the code which ensures length equality for field arrays and annotation arrays is buried in another file (classFileParser) and hard to check.  Second, recent changes to classFileParser actually decouple the field array length from the value declared in the class file, by injecting extra fields into certain system classes.  Although it is (again) unlikely that this will cause a problem, putting a local range check in the code above guarantees an adequate level of safety.

The "at" method includes an assertion check, which is also good, but assertions are (a) not enabled in product mode and (b) can crash the VM if they fail.

? John

On Dec 18, 2012, at 9:05 AM, Joel Borggr?n-Franck wrote:

> New webrev up:
> 
> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/
> 
> - I had to rename the field name for the type annotation byte[] in Field, Constructor and Method.
> 
> Also fixed:
> 
> - I fixed the mapfile that got reindented.
> - Added back a comment that I accidentally removed.


From alejandro.murillo at oracle.com  Thu Dec 20 13:37:40 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 20 Dec 2012 14:37:40 -0700
Subject: HotSpot Changes in 7u
In-Reply-To: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
Message-ID: <50D38524.9030601@oracle.com>


The hotspot in 7u (or 7u12) is hs24.
Since these changes are already in a jdk8 repo, if they apply cleanly to 
hs24 (exported patch from hs25 applies cleanly into hs24)
we just need to push them to hs24 via jprt. If they don't apply cleanly, 
then a request for review should be sent
to hotspot-dev at openjdk.java.net  for backporting to hs24 and once 
approved they can be pushed to hs24 via jprt.

Do not push them directly to 7u/7u/hotspot as they need to go through
pre-integration testing before they make it to the 7u master.

They will eventually be integrated into the 7u/7u/hotspot master as part 
of a hs24 bulk
integration; We do a pre-integration testing of hs24 snapshots before 
pushing them
to the 7u master (and request the proper approval before pushing to the 
master)

We require using jprt to make sure the changes won't break the builds 
and pass a
minimal baseline of tests.

Please work with whoever delivered these changes into hs25 to get them 
into hs24,
or if they are too busy right now let me know and I can work with you to 
get them in


Thanks
Alejandro
On 12/19/2012 10:11 AM, Andrew Hughes wrote:
> Hi,
>
> What is the process for getting into HotSpot changes into 7u?
> Can individual changesets be suggested and committed or do we have
> to wait for a bulk update?  And who decides what goes in these bulk
> updates?
>
> We'd like to see the following changesets in 7u:
>
> 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/75982791ddb6
>
> 8000622: Forgot to hg add and check in test for JDK-7170638
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/26351ce8c4b0
>
> 8000780: make Zero build and run with JDK8
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a3e2f723f2a5
>
> Thanks,

-- 
Alejandro E Murillo, Java Performance
Phone:  (303) 955-2584.
Timezone: US/Mountain (UTC-0700)


From coleen.phillimore at oracle.com  Thu Dec 20 13:38:45 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 20 Dec 2012 16:38:45 -0500
Subject: Code review request: JDK-8005048,NMT: #loaded classes needs to
	just show the # defined classes
In-Reply-To: <50D36337.50304@oracle.com>
References: <50CF7C73.7010608@oracle.com>	<CAHjP37G3VaHgvC_CVzNqvz8URWBLW53Lh4Nsx23tNiLrRNRPiQ@mail.gmail.com>	<50D08386.6060200@oracle.com>	<CAHjP37FpoL2Mrw8GhoJ4AhtL2=mbL8FDhD9vSXbLfOcNAmnZMA@mail.gmail.com>	<CAHjP37FxDQ2AH020Duxyc0DUqdJj0PBzFnP02Dy6x2y4=rjvZQ@mail.gmail.com>	<50D08E20.3000703@oracle.com>
	<50D0CB15.8060708@oracle.com> <50D36337.50304@oracle.com>
Message-ID: <50D38565.6010104@oracle.com>


This looks good.
Thanks,
Coleen

On 12/20/2012 02:12 PM, Zhengyu Gu wrote:
> Round 3:  also decrement instance counter when unloads class loader data.
>
> http://cr.openjdk.java.net/~zgu/8005048/webrev.02/
>
> Thanks,
>
> -Zhengyu
>
> On 12/18/2012 2:59 PM, Zhengyu Gu wrote:
>> Hi,
>>
>> I updated the webrev to reflect the suggestions.
>>
>> Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.01/
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 12/18/2012 10:39 AM, Zhengyu Gu wrote:
>>> Not likely, but I will convert it to loop, just to eliminate the 
>>> concerns ...
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>> On 12/18/2012 10:34 AM, Vitaly Davidovich wrote:
>>>>
>>>> By the way, no chance of blowing the stack here if small stack size 
>>>> is used, right?
>>>>
>>>> Sent from my phone
>>>>
>>>> On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com 
>>>> <mailto:vitalyd at gmail.com>> wrote:
>>>>
>>>>     Ah yes, I see the destructor in MemRecorder now - thanks.
>>>>
>>>>     Sent from my phone
>>>>
>>>>     On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>>
>>>>         Hi Vitaly,
>>>>
>>>>         Thanks for reviewing.
>>>>
>>>>         On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>>>>
>>>>>         Hi Zhengyu,
>>>>>
>>>>>         In GenerationData::reset() you delete _recorder_list.  Since
>>>>>         this list is built from callers (I.e. caller adds recorders)
>>>>>         is it good to delete the head here? I guess this class takes
>>>>>         ownership of added recorders?
>>>>>
>>>>         Yes, releasing recorder via
>>>>         MemTracker::release_thread_recorder() is cleaner solution, I
>>>>         will make change.
>>>>
>>>>
>>>>>         If so, who deletes the rest of the recorders in the list? I'd
>>>>>         expect to see a loop here deleting all recorders in the list.
>>>>>
>>>>         Recorder deletion in coded in recursive manner, in
>>>>         MemRecorer::~MemRecorder()
>>>>
>>>>         if (_next != NULL)  delete _next;
>>>>
>>>>         Thanks,
>>>>
>>>>         -Zhengyu
>>>>
>>>>
>>>>>         Thanks
>>>>>
>>>>>         Sent from my phone
>>>>>
>>>>>         On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>>>
>>>>>             Current NMT implementation reports number of loaded
>>>>>             classes at query time, but number of defined classes is
>>>>>             what is expected.
>>>>>
>>>>>             This changset reflects two major changes:
>>>>>
>>>>>             1. It counts number of defined classes vs. number of
>>>>>             loaded classes
>>>>>             2. It counts number of defined classes for each
>>>>>             generation, vs. counts at query time. In this way, the
>>>>>             number of defined classes that NMT reports, should match
>>>>>             the corresponding class metadata data. As the result, the
>>>>>             data should be more accurate.
>>>>>
>>>>>
>>>>>             Webrev:
>>>>> http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>>>>>
>>>>>
>>>>>             Thanks,
>>>>>
>>>>>             -Zhengyu
>>>>>


From tao.mao at oracle.com  Thu Dec 20 14:19:24 2012
From: tao.mao at oracle.com (Tao Mao)
Date: Thu, 20 Dec 2012 14:19:24 -0800
Subject: Fwd: Re: Request for review: 8004132 SerialGC ValidateMarkSweep code
	broken
In-Reply-To: <50CF8857.9090106@oracle.com>
References: <50CF8857.9090106@oracle.com>
Message-ID: <50D38EEC.6040806@oracle.com>

Hi hotspot-dev,
Is there anyone interested in reviewing the change?

Thanks.
Tao

-------- Original Message --------
Subject: 	Re: Request for review: 8004132 SerialGC ValidateMarkSweep 
code broken
Date: 	Mon, 17 Dec 2012 13:02:15 -0800
From: 	Tao Mao <tao.mao at oracle.com>
Organization: 	Oracle Corporation
To: 	John Cuthbertson <john.cuthbertson at oracle.com>
CC: 	hotspot-gc-dev openjdk.java.net <hotspot-gc-dev at openjdk.java.net>



Thank you, John. A new webrev is uploaded as you advised.

http://cr.openjdk.java.net/~tamao/8004132/webrev.01/

I would like to have one more review if possible.

Thanks.
Tao

On 12/13/2012 4:05 PM, John Cuthbertson wrote:
>  Hi Tao,
>
>  This looks good to me. One comment - the functionality of
>  RecordMarkSweepCompaction depends upon ValidateMarkSweep you might
>  want to remove this flag as well.
>
>  JohnC
>
>  On 12/04/12 15:47, Tao Mao wrote:
>>  8004132 : SerialGC: ValidateMarkSweep broken when running GCOld
>>  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004132
>>
>>  http://cr.openjdk.java.net/~tamao/8004132/webrev.00/
>>
>>  Passed JPRT; I checked ValidateMarkSweep can't be triggered now with
>>  the fix.
>>
>>  Background:
>>
>>  While verifying the functionality of the ValidateMarkSweep code with
>>  the Serial collector (prior to adding code to enable this feature in
>>  G1) Tao and myself saw various crashes and failures when running GC Old.
>>
>>  Script to run GCOld:
>>  #JHOME=/export/jdk8/solaris-x64
>>  #JHOME=/java/re/jdk/6/promoted/latest/binaries/solaris-i586/fastdebug
>>  JHOME=/export/bugs/8001047/jdk7/solaris-x64
>>
>>  $JHOME/bin/java -server -Xms1g -Xmx1g \
>>          -XX:+UseSerialGC \
>>          -XX:+ValidateMarkSweep \
>>          -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
>>  -XX:+ShowMessageBoxOnError \
>>                  GCOld 9000 20 5 30 500000
>>
>>  Note the ValidateMarkSweep functionality is only available in
>>  non-product builds.
>>
>>  This seems to have been broken for a long while - we even saw the
>>  crash with jdk6. Thus we suggest to remove the ValidateMarkSweep code.
>>
>


From ChrisPhi at LGonQn.Org  Thu Dec 20 15:09:37 2012
From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O)
Date: Thu, 20 Dec 2012 18:09:37 -0500
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
Message-ID: <50D39AB1.90802@LGonQn.Org>

Hi

Attached is a backport (essentially resurrection of the Permgen code)
of 8000780

Please review.

Cheers!
Chris
 PS
Webrev is here:
http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b25++/




From jon.masamitsu at oracle.com  Thu Dec 20 15:30:51 2012
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 20 Dec 2012 15:30:51 -0800
Subject: Fwd: Re: Request for review: 8004132 SerialGC ValidateMarkSweep
	code broken
In-Reply-To: <50D38EEC.6040806@oracle.com>
References: <50CF8857.9090106@oracle.com> <50D38EEC.6040806@oracle.com>
Message-ID: <50D39FAB.3020502@oracle.com>

Tao,

Changes look good.

Jon

On 12/20/12 14:19, Tao Mao wrote:
> Hi hotspot-dev,
> Is there anyone interested in reviewing the change?
>
> Thanks.
> Tao
>
> -------- Original Message --------
> Subject:     Re: Request for review: 8004132 SerialGC 
> ValidateMarkSweep code broken
> Date:     Mon, 17 Dec 2012 13:02:15 -0800
> From:     Tao Mao <tao.mao at oracle.com>
> Organization:     Oracle Corporation
> To:     John Cuthbertson <john.cuthbertson at oracle.com>
> CC:     hotspot-gc-dev openjdk.java.net <hotspot-gc-dev at openjdk.java.net>
>
>
>
> Thank you, John. A new webrev is uploaded as you advised.
>
> http://cr.openjdk.java.net/~tamao/8004132/webrev.01/
>
> I would like to have one more review if possible.
>
> Thanks.
> Tao
>
> On 12/13/2012 4:05 PM, John Cuthbertson wrote:
>>  Hi Tao,
>>
>>  This looks good to me. One comment - the functionality of
>>  RecordMarkSweepCompaction depends upon ValidateMarkSweep you might
>>  want to remove this flag as well.
>>
>>  JohnC
>>
>>  On 12/04/12 15:47, Tao Mao wrote:
>>>  8004132 : SerialGC: ValidateMarkSweep broken when running GCOld
>>>  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004132
>>>
>>>  http://cr.openjdk.java.net/~tamao/8004132/webrev.00/
>>>
>>>  Passed JPRT; I checked ValidateMarkSweep can't be triggered now with
>>>  the fix.
>>>
>>>  Background:
>>>
>>>  While verifying the functionality of the ValidateMarkSweep code with
>>>  the Serial collector (prior to adding code to enable this feature in
>>>  G1) Tao and myself saw various crashes and failures when running GC 
>>> Old.
>>>
>>>  Script to run GCOld:
>>>  #JHOME=/export/jdk8/solaris-x64
>>>  #JHOME=/java/re/jdk/6/promoted/latest/binaries/solaris-i586/fastdebug
>>>  JHOME=/export/bugs/8001047/jdk7/solaris-x64
>>>
>>>  $JHOME/bin/java -server -Xms1g -Xmx1g \
>>>          -XX:+UseSerialGC \
>>>          -XX:+ValidateMarkSweep \
>>>          -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
>>>  -XX:+ShowMessageBoxOnError \
>>>                  GCOld 9000 20 5 30 500000
>>>
>>>  Note the ValidateMarkSweep functionality is only available in
>>>  non-product builds.
>>>
>>>  This seems to have been broken for a long while - we even saw the
>>>  crash with jdk6. Thus we suggest to remove the ValidateMarkSweep code.
>>>
>>
>

From coleen.phillimore at oracle.com  Thu Dec 20 15:51:04 2012
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 20 Dec 2012 18:51:04 -0500
Subject: HotSpot Changes in 7u
In-Reply-To: <50D2C0E7.6080903@oracle.com>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
	<50D2C0E7.6080903@oracle.com>
Message-ID: <50D3A468.3040303@oracle.com>


I am checking these changes into hsx24 now.

On 12/20/2012 02:40 AM, David Holmes wrote:
>> We'd like to see the following changesets in 7u:
>>
>> 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/75982791ddb6
>
> This seems reasonable to me. Though I will note that a few developers 
> on the JDK disliked the appearance of the ""**NOTICE** Dtrace support 
> disabled: ..." message in their build output.
>

This is the first I've heard of this.

Coleen
>> 8000622: Forgot to hg add and check in test for JDK-7170638
>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/26351ce8c4b0
>
> Again seems reasonable to me. 


From vladimir.kozlov at oracle.com  Thu Dec 20 16:19:48 2012
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Fri, 21 Dec 2012 00:19:48 +0000
Subject: hg: hsx/hotspot-main/jdk: 8004330: Add missing Unsafe entry points
	for addAndGet() family
Message-ID: <20121221002017.0607F4730D@hg.openjdk.java.net>

Changeset: 8cf5b18488d1
Author:    dl
Date:      2012-12-20 12:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1

8004330: Add missing Unsafe entry points for addAndGet() family
Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898)
Reviewed-by: alanb, kvn

! src/share/classes/sun/misc/Unsafe.java


From david.holmes at oracle.com  Thu Dec 20 17:59:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Dec 2012 11:59:10 +1000
Subject: HotSpot Changes in 7u
In-Reply-To: <50D3A468.3040303@oracle.com>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
	<50D2C0E7.6080903@oracle.com> <50D3A468.3040303@oracle.com>
Message-ID: <50D3C26E.3040900@oracle.com>

On 21/12/2012 9:51 AM, Coleen Phillimore wrote:
>
> I am checking these changes into hsx24 now.

Thanks Coleen.

> On 12/20/2012 02:40 AM, David Holmes wrote:
>>> We'd like to see the following changesets in 7u:
>>>
>>> 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/75982791ddb6
>>
>> This seems reasonable to me. Though I will note that a few developers
>> on the JDK disliked the appearance of the ""**NOTICE** Dtrace support
>> disabled: ..." message in their build output.
>>
>
> This is the first I've heard of this.

JDK-8004973

As most of our dev/build machines don't have the SDT support hotspot 
gives this "Notice" during the build. It's only informational but some 
find it objectionable.

David
-----

>
> Coleen
>>> 8000622: Forgot to hg add and check in test for JDK-7170638
>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/26351ce8c4b0
>>
>> Again seems reasonable to me.
>

From david.holmes at oracle.com  Thu Dec 20 18:02:11 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Dec 2012 12:02:11 +1000
Subject: HotSpot Changes in 7u
In-Reply-To: <1356005055.25310.27.camel@pegasus>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
	<50D2C0E7.6080903@oracle.com> <1356005055.25310.27.camel@pegasus>
Message-ID: <50D3C323.7090008@oracle.com>

On 20/12/2012 10:04 PM, Mario Torre wrote:
> Il giorno gio, 20/12/2012 alle 17.40 +1000, David Holmes ha scritto:
>
>> I'd suggest approaching the original engineers who sponsored these
>> fixes. But please bear in mind that we are hitting an extremely busy
>> period with JDK 8.
>
> We could offer quality manpower if we had access to those repos like the
> rest of the jdk.

Hotspot changes must go in through JPRT but everything up to the actual 
submission can be done externally.

And to answer Andrew's question: no there is no progress with regard to 
"opening up" JPRT.

Cheers,
David

> Cheers,
> Mario
>
>

From david.holmes at oracle.com  Thu Dec 20 18:34:17 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Dec 2012 12:34:17 +1000
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>
Message-ID: <50D3CAA9.2080104@oracle.com>

Hi Goetz,

My apologies as I don't have a lot of time to go into this at the moment 
(and will shortly be starting Xmas leave).

My preference is to see the necessary OrderAccess operations in the 
places they are needed. That is for two reasons:

a) clarity in the algorithm
b) performance (through not having redundant barriers [even if they 
become no-ops on a given platform]).

When the barriers are hidden in individual accessors no-one can tell 
where they are actually needed, and if things don't work the only 
available response is to "crank up" the kind of barrier used. I'd prefer 
to see the ordering dependencies clearly defined in the code. eg at least:

 > void set_empty() {
 >    _bottom =  0;
 >    OrderAccess::release_store_ptr((volatile intptr_t*)&_age, 0);
 > }

(with suitable comments)

I'm not saying the hotspot code necessarily already does this. It is a 
sad fact that TSO assumptions have leached through into a lot of the 
hotspot code and caused bugs on non-TSO platforms. This certainly needs 
to be fixed. But again my preference is to see ordering dependencies 
explicitly called out and addressed.

That all said I am not the ultimate arbiter here. This is GC code and it 
belongs to the GC folk (who are being conspicuously silent ;-) ). If 
they are prepared to take it as-is then I'm not standing in the way.

With regards to problems with OrderAccess please see:

http://bugs.sun.com/view_bug.do?bug_id=7143664

7143664 : Clean up OrderAccess implementations and usage

Thanks,
David
-----

On 21/12/2012 6:23 AM, Lindenmaier, Goetz wrote:
> Hi David,
>
> I understand that you want selected corrections, not the
> solution we chose that does it everywhere.
>
> But do you agree that our solution does not introduce any
> overhead on x86 and sparc?
>
>
>
> I'll try to explain why I think this is the case using the
> example you brought up:
>
> void set_empty() {
>    _bottom = 0;
>    _age.set(0);
> }
>
> will result in something like
>
>   x86_64                      our ppc                our ia64
>   ------                      -------                --------
>   movl 0, _bottom             swz                    st4.rel
>   movq 0, _age                sd                     st8.rel
>
> which is correct on x86 and ia64, but wrong on power.
>
> void set_empty() {
>    _bottom = 0;
>    OrderAccess::storestore();
>    _age.set(0);
> }
>
> will result in something like
>
>   x86_64                      our ppc                our ia64
>   ------                      -------                --------
>   movl 0, _bottom             swz                    st4.rel
>   movl 0, local_dummy         lwsync                 mf
>   movq 0, _age                sd                     st8.rel
>
> which is correct, but inefficient on x86_64 (a bit) and ia64.
>
> while
>
> void set_empty() {
>    _bottom =  0;
>    OrderAccess::release_store_ptr((volatile intptr_t*)&_age, 0);
> }
>
> will result in
>
>   movl 0, _bottom             swz                    st4.rel
>   movq 0, _age                lwsync; sd             st8.rel
>
> which is correct and efficient.
>
>
>
> By the way, if you have a PPC port, do you have a machine to build
> and run the openJDK PPC port?
>
>> (modulo OrderAccess is far from perfect and has some outstanding issues).
> What are the problems of the OrderAccess implementation?
>
> Best regards,
>    Goetz.
>
>
>
>
>
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Thursday, December 20, 2012 2:36 AM
> To: Lindenmaier, Goetz
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
> On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> first, thanks for the fast replies. Sorry it took me a day now!
>
> No problem. I can't guarantee response times either :)
>
>>> I didn't say that. I said these two need to be ordered and asked which
>>> other paired accesses to these variables need to be ordered.
>> Together with a colleague I looked at the code. To us it seems
>> very hard to identify places where access ordering is not needed.
>> Especially we think there will be places in the users of the
>> task queue that would need barriers to ensure ordering.
>> But we think, the algorithm should be self-contained, doing all the
>> required ordering itself.
>
> I agree the algorithm should be self-contained. My point is that in
> other places where we implement lock-free algorithm was put in the
> barriers/fences in the algorithmic code in the places needed we don't
> automatically wrap all of the variables accesses with code that
> introduces pre/post barriers (of whatever form).
>
>> Further, a barrier will spoil performance on x86 etc, because there it
>> issues a lock instruction, which is not needed.
>
> You issue the appropriate barrier/fence for the situation and they
> should be implemented in whatever form needed for the given platform
> (modulo OrderAccess is far from perfect and has some outstanding issues).
>
>>> I said that what you were doing was effectively treating the C++ variables
>>> as if they were Java volatile variables. That's not the way we handle
>>> these issues in the VM we tend to place fences/barriers at the places in
>>> lock-free algorithms that need them, rather than wrap the variables in
>>> accessors that impose fences/barriers that are not always needed.
>>
>> As we understand, the C compilers on x86, sparc etc, enforce far more
>> than required to implement C++ volatile, basically treating the fields
>> like Java volatiles.  Therefore your code is fine on your platforms.
>
> I think you are confusing things. The existing C/C++ compilers do very
> little in regard to "volatile". It is only the latest multi-threading
> variant of the C++ standard that even addresses this! Our C/C++
> compilers never issue any kind of memory barriers in response to a
> load/store of a volatile variable.
>
>> The C++ compilers on PPC optimize far more, maxing out
>> what the standard allows and the processer supports, leading to
>> immediate errors, but also to very subtle ones.
>>
>> Our change makes explicit what the C compilers (except for PPC) do
>> anyways, and what is required by the algorithm. (Maybe one could now
>> even omit the volatile keywords - but we dare not try.) Thus, we get
>> it right without any overhead on your platforms.
>
> This is getting things confused. The lock-free algorithms should be
> written for the most lenient of memory-models and make no assumptions
> about ordering. They should use the appropriate OrderAccess method where
> needed for algorithmic correctness.
>
> You proposal wraps the C variable in accessors that use OrderAccess
> operations on every access - in a similar way to how we have to handle
> Java volatile accesses. And as I have said that is not the style we use
> in hotspot's lock-free code. This has nothing to do with our compiler
> versus your compiler (though if you have one that issues memory-barriers
> directly then you'll get too much overhead.)
>
>>> Though we have not run into this particular issue. Did
>>> it arise in the context of a particular GC?
>> Issues are only on PPC, at least in parallelScavenge. I reproduced
>> some of the immediate errors, but I don't think this really helps with
>> the discussion.  I will try G1 soon.  Tell me if you want to know
>> more, then I'll try to come up with a wrap-up of our past fixes.
>
> We have a PPC product and as I said we have not encountered this
> problem, but we also run with limited GCs so may not have been
> exercising this code.
>
> Thanks,
> David
>
>> Best regards,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Dienstag, 18. Dezember 2012 12:19
>> To: Lindenmaier, Goetz
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>
>> Hi Goetz,
>>
>> On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> why do you think only these two accesses have to be ordered?
>>
>> I didn't say that. I said these two need to be ordered and asked which
>> other paired accesses to these variables need to be ordered.
>>
>>> As I understand, any two accesses in one thread to these fields have to be
>>> orderered and must be written to memory to become visible in the proper order
>>> to other threads.
>>
>> That depends on how they are used. It is the overall lock-free algorithm
>> that is important here. There may be places where the order of access
>> does not matter (and there may not be).
>>
>>> The PPC compiler really takes all advantages given by the
>>> C-Standard to optimize this, and the processor reorders heavily.
>>
>> Yes I understand. Though we have not run into this particular issue. Did
>> it arise in the context of a particular GC?
>>
>>> The specification of volatile in
>>>           Age get() const volatile { return _data; }
>>> says that it must be read from memory, not that it can not be reordered.
>>
>> I didn't say anything about C/C++ volatile (which doesn't even say it
>> must be read from memory - except perhaps in latest MT C++ standard?). I
>> said that what you were doing was effectively treating the C++ variables
>> as if they were Java volatile variables. That's not the way we handle
>> these issues in the VM we tend to place fences/barriers at the places in
>> lock-free algorithms that need them, rather than wrap the variables in
>> accessors that impose fences/barriers that are not always needed.
>>
>> Cheers,
>> David
>>
>>> Also, doing
>>>          OrderAccess::load_acquire((volatile idx_t*)&(_age._fields._top))
>>> is better wrt. to optimizations by C-compilers, as there first
>>> is the whole address computation, and then the cast to volatile.
>>> If we use
>>>          _age.top()
>>> with
>>>          idx_t top() const volatile { return OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
>>> compilers don't optimize that well.  (We saw this on hpia64.)
>>> Further, the access to, e.g., old_age.top() in pop_local_slow() would do
>>> the OrderAccess, which is useless overhead.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>> -----Original Message-----
>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>> Sent: Dienstag, 18. Dezember 2012 01:24
>>> To: Lindenmaier, Goetz
>>> Cc: hotspot-dev at openjdk.java.net
>>> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>>
>>> Hi Goetz,
>>>
>>> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> Once more, with webrev:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>>>
>>> I can see that this function needs a storestore barrier:
>>>
>>>      237   void set_empty() {
>>>      238     _bottom = 0;
>>>      239     _age.set(0);
>>>      240   }
>>>
>>> to preserve ordering. Are there other functions to which we can
>>> constrain the loadload and storestore barriers rather than using the
>>> setters/getters the way you have defined? This is always about a pair
>>> (sometimes groups) of accesses so I'd rather deal with the pairs than
>>> treat each field as if it were a Java volatile.
>>>
>>> Thanks,
>>> David Holmes
>>>
>>>
>>>> Sorry for that.
>>>>
>>>> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>>>>
>>>> On Platfoms with weak memory ordering the taskqueue is not accessed
>>>> properly, as the accesses to the fields _bottom and _age are not ordered
>>>> correctly. Volatile is not sufficient to enforce this, because it depends on
>>>> what the compiler assumes to be necessary for volatile variables.
>>>>
>>>> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
>>>> OrderAccess to access the fields in _age as well as _bottom.   Further the code must always
>>>> use the getter/setter methods to access _bottom, _age or the subfields of _age.
>>>> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>>>>
>>>> The OrderAccess routines do simple load/stores on x86_64.
>>>>
>>>> I want to discuss this change here and would like very much to see it taking
>>>> it's way into OpenJDK to support ports on platforms with weak memory
>>>> ordering, and, in particular, our PPC port.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>

From david.holmes at oracle.com  Thu Dec 20 18:46:15 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Dec 2012 12:46:15 +1000
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <CAHjP37GerjPt3meYoj-tuk3ex37XNJbv1CniSEkW1JXfGy0BzQ@mail.gmail.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>
	<CAHjP37GerjPt3meYoj-tuk3ex37XNJbv1CniSEkW1JXfGy0BzQ@mail.gmail.com>
Message-ID: <50D3CD77.4090808@oracle.com>

On 21/12/2012 6:43 AM, Vitaly Davidovich wrote:
> As an aside, how come storestore is not defined as "asm volatile ("" : :
> : "memory");" on Linux x86/64?

We have an open RFE to improve things

http://bugs.sun.com/view_bug.do?bug_id=6975121

6975121 : OrderAccess should use compiler intrinsics where possible

Our problem has always been getting the right support from the official 
compiler.

David
-----


> Thanks
>
> Sent from my phone
>
> On Dec 20, 2012 3:24 PM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com>> wrote:
>
>     Hi David,
>
>     I understand that you want selected corrections, not the
>     solution we chose that does it everywhere.
>
>     But do you agree that our solution does not introduce any
>     overhead on x86 and sparc?
>
>
>
>     I'll try to explain why I think this is the case using the
>     example you brought up:
>
>     void set_empty() {
>        _bottom = 0;
>        _age.set(0);
>     }
>
>     will result in something like
>
>       x86_64                      our ppc                our ia64
>       ------                      -------                --------
>       movl 0, _bottom             swz                    st4.rel
>       movq 0, _age                sd                     st8.rel
>
>     which is correct on x86 and ia64, but wrong on power.
>
>     void set_empty() {
>        _bottom = 0;
>        OrderAccess::storestore();
>        _age.set(0);
>     }
>
>     will result in something like
>
>       x86_64                      our ppc                our ia64
>       ------                      -------                --------
>       movl 0, _bottom             swz                    st4.rel
>       movl 0, local_dummy         lwsync                 mf
>       movq 0, _age                sd                     st8.rel
>
>     which is correct, but inefficient on x86_64 (a bit) and ia64.
>
>     while
>
>     void set_empty() {
>        _bottom =  0;
>        OrderAccess::release_store_ptr((volatile intptr_t*) &_age, 0);
>     }
>
>     will result in
>
>       movl 0, _bottom             swz                    st4.rel
>       movq 0, _age                lwsync; sd             st8.rel
>
>     which is correct and efficient.
>
>
>
>     By the way, if you have a PPC port, do you have a machine to build
>     and run the openJDK PPC port?
>
>      > (modulo OrderAccess is far from perfect and has some outstanding
>     issues).
>     What are the problems of the OrderAccess implementation?
>
>     Best regards,
>        Goetz.
>
>
>
>
>
>
>     -----Original Message-----
>     From: David Holmes [mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>]
>     Sent: Thursday, December 20, 2012 2:36 AM
>     To: Lindenmaier, Goetz
>     Cc: hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>
>     Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>
>     On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
>      > Hi David,
>      >
>      > first, thanks for the fast replies. Sorry it took me a day now!
>
>     No problem. I can't guarantee response times either :)
>
>      >> I didn't say that. I said these two need to be ordered and asked
>     which
>      >> other paired accesses to these variables need to be ordered.
>      > Together with a colleague I looked at the code. To us it seems
>      > very hard to identify places where access ordering is not needed.
>      > Especially we think there will be places in the users of the
>      > task queue that would need barriers to ensure ordering.
>      > But we think, the algorithm should be self-contained, doing all the
>      > required ordering itself.
>
>     I agree the algorithm should be self-contained. My point is that in
>     other places where we implement lock-free algorithm was put in the
>     barriers/fences in the algorithmic code in the places needed we don't
>     automatically wrap all of the variables accesses with code that
>     introduces pre/post barriers (of whatever form).
>
>      > Further, a barrier will spoil performance on x86 etc, because
>     there it
>      > issues a lock instruction, which is not needed.
>
>     You issue the appropriate barrier/fence for the situation and they
>     should be implemented in whatever form needed for the given platform
>     (modulo OrderAccess is far from perfect and has some outstanding
>     issues).
>
>      >> I said that what you were doing was effectively treating the C++
>     variables
>      >> as if they were Java volatile variables. That's not the way we
>     handle
>      >> these issues in the VM we tend to place fences/barriers at the
>     places in
>      >> lock-free algorithms that need them, rather than wrap the
>     variables in
>      >> accessors that impose fences/barriers that are not always needed.
>      >
>      > As we understand, the C compilers on x86, sparc etc, enforce far more
>      > than required to implement C++ volatile, basically treating the
>     fields
>      > like Java volatiles.  Therefore your code is fine on your platforms.
>
>     I think you are confusing things. The existing C/C++ compilers do very
>     little in regard to "volatile". It is only the latest multi-threading
>     variant of the C++ standard that even addresses this! Our C/C++
>     compilers never issue any kind of memory barriers in response to a
>     load/store of a volatile variable.
>
>      > The C++ compilers on PPC optimize far more, maxing out
>      > what the standard allows and the processer supports, leading to
>      > immediate errors, but also to very subtle ones.
>      >
>      > Our change makes explicit what the C compilers (except for PPC) do
>      > anyways, and what is required by the algorithm. (Maybe one could now
>      > even omit the volatile keywords - but we dare not try.) Thus, we get
>      > it right without any overhead on your platforms.
>
>     This is getting things confused. The lock-free algorithms should be
>     written for the most lenient of memory-models and make no assumptions
>     about ordering. They should use the appropriate OrderAccess method where
>     needed for algorithmic correctness.
>
>     You proposal wraps the C variable in accessors that use OrderAccess
>     operations on every access - in a similar way to how we have to handle
>     Java volatile accesses. And as I have said that is not the style we use
>     in hotspot's lock-free code. This has nothing to do with our compiler
>     versus your compiler (though if you have one that issues memory-barriers
>     directly then you'll get too much overhead.)
>
>      >> Though we have not run into this particular issue. Did
>      >> it arise in the context of a particular GC?
>      > Issues are only on PPC, at least in parallelScavenge. I reproduced
>      > some of the immediate errors, but I don't think this really helps
>     with
>      > the discussion.  I will try G1 soon.  Tell me if you want to know
>      > more, then I'll try to come up with a wrap-up of our past fixes.
>
>     We have a PPC product and as I said we have not encountered this
>     problem, but we also run with limited GCs so may not have been
>     exercising this code.
>
>     Thanks,
>     David
>
>      > Best regards,
>      >    Goetz.
>      >
>      >
>      > -----Original Message-----
>      > From: David Holmes [mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>]
>      > Sent: Dienstag, 18. Dezember 2012 12:19
>      > To: Lindenmaier, Goetz
>      > Cc: hotspot-dev at openjdk.java.net
>     <mailto:hotspot-dev at openjdk.java.net>
>      > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>      >
>      > Hi Goetz,
>      >
>      > On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>      >> Hi David,
>      >>
>      >> why do you think only these two accesses have to be ordered?
>      >
>      > I didn't say that. I said these two need to be ordered and asked
>     which
>      > other paired accesses to these variables need to be ordered.
>      >
>      >> As I understand, any two accesses in one thread to these fields
>     have to be
>      >> orderered and must be written to memory to become visible in the
>     proper order
>      >> to other threads.
>      >
>      > That depends on how they are used. It is the overall lock-free
>     algorithm
>      > that is important here. There may be places where the order of access
>      > does not matter (and there may not be).
>      >
>      >> The PPC compiler really takes all advantages given by the
>      >> C-Standard to optimize this, and the processor reorders heavily.
>      >
>      > Yes I understand. Though we have not run into this particular
>     issue. Did
>      > it arise in the context of a particular GC?
>      >
>      >> The specification of volatile in
>      >>          Age get() const volatile { return _data; }
>      >> says that it must be read from memory, not that it can not be
>     reordered.
>      >
>      > I didn't say anything about C/C++ volatile (which doesn't even say it
>      > must be read from memory - except perhaps in latest MT C++
>     standard?). I
>      > said that what you were doing was effectively treating the C++
>     variables
>      > as if they were Java volatile variables. That's not the way we handle
>      > these issues in the VM we tend to place fences/barriers at the
>     places in
>      > lock-free algorithms that need them, rather than wrap the
>     variables in
>      > accessors that impose fences/barriers that are not always needed.
>      >
>      > Cheers,
>      > David
>      >
>      >> Also, doing
>      >>         OrderAccess::load_acquire((volatile
>     idx_t*)&(_age._fields._top))
>      >> is better wrt. to optimizations by C-compilers, as there first
>      >> is the whole address computation, and then the cast to volatile.
>      >> If we use
>      >>         _age.top()
>      >> with
>      >>         idx_t top() const volatile { return
>     OrderAccess::load_acquire((volatile idx_t*)&(_fields._top); }
>      >> compilers don't optimize that well.  (We saw this on hpia64.)
>      >> Further, the access to, e.g., old_age.top() in pop_local_slow()
>     would do
>      >> the OrderAccess, which is useless overhead.
>      >>
>      >> Best regards,
>      >>     Goetz.
>      >>
>      >>
>      >> -----Original Message-----
>      >> From: David Holmes [mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>]
>      >> Sent: Dienstag, 18. Dezember 2012 01:24
>      >> To: Lindenmaier, Goetz
>      >> Cc: hotspot-dev at openjdk.java.net
>     <mailto:hotspot-dev at openjdk.java.net>
>      >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>      >>
>      >> Hi Goetz,
>      >>
>      >> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>      >>> Hi,
>      >>>
>      >>> Once more, with webrev:
>      >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
>      >>
>      >> I can see that this function needs a storestore barrier:
>      >>
>      >>     237   void set_empty() {
>      >>     238     _bottom = 0;
>      >>     239     _age.set(0);
>      >>     240   }
>      >>
>      >> to preserve ordering. Are there other functions to which we can
>      >> constrain the loadload and storestore barriers rather than using the
>      >> setters/getters the way you have defined? This is always about a
>     pair
>      >> (sometimes groups) of accesses so I'd rather deal with the pairs
>     than
>      >> treat each field as if it were a Java volatile.
>      >>
>      >> Thanks,
>      >> David Holmes
>      >>
>      >>
>      >>> Sorry for that.
>      >>>
>      >>> I would like to contribute fixes wrt. memory ordering in
>     taskqueue.hpp.
>      >>>
>      >>> On Platfoms with weak memory ordering the taskqueue is not accessed
>      >>> properly, as the accesses to the fields _bottom and _age are
>     not ordered
>      >>> correctly. Volatile is not sufficient to enforce this, because
>     it depends on
>      >>> what the compiler assumes to be necessary for volatile variables.
>      >>>
>      >>> The fix is to pull getter/setter routines from Age to
>     TaskQueueSuper and use methods from
>      >>> OrderAccess to access the fields in _age as well as _bottom.
>     Further the code must always
>      >>> use the getter/setter methods to access _bottom, _age or the
>     subfields of _age.
>      >>> On the other hand we can relax constraints for accesses to
>     locals oldAge and newAge.
>      >>>
>      >>> The OrderAccess routines do simple load/stores on x86_64.
>      >>>
>      >>> I want to discuss this change here and would like very much to
>     see it taking
>      >>> it's way into OpenJDK to support ports on platforms with weak
>     memory
>      >>> ordering, and, in particular, our PPC port.
>      >>>
>      >>> Best regards,
>      >>>      Goetz.
>      >>>
>      >>>
>

From david.holmes at oracle.com  Thu Dec 20 18:51:08 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Dec 2012 12:51:08 +1000
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <50D3CE9C.1090408@oracle.com>

Vote: yes

David

On 20/12/2012 2:20 PM, Bengt Rutisson wrote:
>
> I hereby nominate Stfan Karlsson to be an OpenJDK HSX [0] Reviewer [1].
>
> Stefan is on his third year as a Committer on the HSX project. He is a
> key contributor in the Hotspot's GC group, working on all GCs. He has
> contributed 32 significant changesets as a Committer and is thus
> well-qualified to be a Reviewer on the HSX project.
>
> Votes are due by Thursday, January 3, 2012 at 00:00:00 UTC (two week
> voting period).
>
> Only current HSX project Reviewers [2] are eligible to vote on this
> nomination.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> Regards,
> Bengt Rutisson
>
> [0] http://openjdk.java.net/census/#hsx
> [1] http://openjdk.java.net/bylaws#reviewer
> [2] http://openjdk.java.net/projects/#reviewer-vote
> [3] http://openjdk.java.net/bylaws#three-vote-consensus
>

From coleen.phillimore at oracle.com  Thu Dec 20 19:33:35 2012
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 21 Dec 2012 03:33:35 +0000
Subject: hg: hsx/hsx24/hotspot: 2 new changesets
Message-ID: <20121221033342.043E54731C@hg.openjdk.java.net>

Changeset: c707a5af0d71
Author:    coleenp
Date:      2012-10-08 09:18 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c707a5af0d71

7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
Summary: Don't use HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N directly.
Reviewed-by: coleenp, kamg, dholmes, sspitsyn
Contributed-by: Mark Wielaard <mjw at redhat.com>

! make/bsd/makefiles/buildtree.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/dtrace.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/buildtree.make
! src/share/vm/prims/jni.cpp
! src/share/vm/utilities/dtrace.hpp

Changeset: 9d98c1eb82b0
Author:    coleenp
Date:      2012-10-09 02:42 -0400
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9d98c1eb82b0

8000622: Forgot to hg add and check in test for JDK-7170638
Summary: add the test
Reviewed-by: coleenp, kamg
Contributed-by: Mark Wielaard <mjw at redhat.com>

+ test/serviceability/7170638/SDTProbesGNULinuxTest.sh


From david.holmes at oracle.com  Thu Dec 20 21:27:06 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 21 Dec 2012 15:27:06 +1000
Subject: Final Profiles update to jdk8-b69
In-Reply-To: <50C9BAAE.5030309@oracle.com>
References: <50BC0678.1040300@oracle.com> <50BEDADE.40301@oracle.com>
	<50C9BAAE.5030309@oracle.com>
Message-ID: <50D3F32A.7010306@oracle.com>

FYI the Profiles forest has been updated to the jdk8-b69 level (the tags 
are missing but it is b69).

This is the last sync-up of the Profiles forest with jdk8/jdk8.

We are preparing to integrate the Profiles changes with mainline using 
the jdk8/build forest. Request for reviews will be issued shortly.

David

From volker.simonis at gmail.com  Fri Dec 21 00:26:08 2012
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 21 Dec 2012 09:26:08 +0100
Subject: HotSpot Changes in 7u
In-Reply-To: <50D3C323.7090008@oracle.com>
References: <2038228472.17886673.1355937062930.JavaMail.root@redhat.com>
	<50D2C0E7.6080903@oracle.com> <1356005055.25310.27.camel@pegasus>
	<50D3C323.7090008@oracle.com>
Message-ID: <CA+3eh12OBx-p7M63yE9cEFx8Wjo8k-waFDojutX3r-=ABPp+9w@mail.gmail.com>

On Fri, Dec 21, 2012 at 3:02 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 20/12/2012 10:04 PM, Mario Torre wrote:
>>
>> Il giorno gio, 20/12/2012 alle 17.40 +1000, David Holmes ha scritto:
>>
>>> I'd suggest approaching the original engineers who sponsored these
>>> fixes. But please bear in mind that we are hitting an extremely busy
>>> period with JDK 8.
>>
>>
>> We could offer quality manpower if we had access to those repos like the
>> rest of the jdk.
>
>
> Hotspot changes must go in through JPRT but everything up to the actual
> submission can be done externally.
>
> And to answer Andrew's question: no there is no progress with regard to
> "opening up" JPRT.

Sometimes the simple truth hurts so much that you'd better don't hear about it:)

> Cheers,
> David
>
>> Cheers,
>> Mario
>>
>>
>

From aleksey.shipilev at oracle.com  Fri Dec 21 02:20:39 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 21 Dec 2012 14:20:39 +0400
Subject: RFR (M) #4 CR 8003985: Support @Contended annotation
Message-ID: <50D437F7.207@oracle.com>

Hi,

This is the final call for reviews for @Contended:
  http://cr.openjdk.java.net/~shade/8003985/webrev.00/

Testing:
 - Test8003985 passes on Linux x86_64
 - JPRT full cycle passed
 - VM adhoc tests are underway, but should be the same as previous
passed run, since there are no semantical changes

JEP-142 is in Funded state:
 http://openjdk.java.net/jeps/142

Thanks,
Aleksey.

From Alan.Bateman at oracle.com  Fri Dec 21 02:40:20 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Dec 2012 10:40:20 +0000
Subject: RFR (M) #4 CR 8003985: Support @Contended annotation
In-Reply-To: <50D437F7.207@oracle.com>
References: <50D437F7.207@oracle.com>
Message-ID: <50D43C94.4050809@oracle.com>

On 21/12/2012 10:20, Aleksey Shipilev wrote:
> Hi,
>
> This is the final call for reviews for @Contended:
>    http://cr.openjdk.java.net/~shade/8003985/webrev.00/
>
> Testing:
>   - Test8003985 passes on Linux x86_64
>   - JPRT full cycle passed
>   - VM adhoc tests are underway, but should be the same as previous
> passed run, since there are no semantical changes
>
> JEP-142 is in Funded state:
>   http://openjdk.java.net/jeps/142
>
> Thanks,
> Aleksey.
Has sun.misc.Contended been decided? I really think this needs to be 
moved to somewhere that can be supported, like jdk.vm.Contented. I did 
bring this up on c-i and Doug replied, I just haven't had the time to 
follow up on it.

-Alan

From aleksey.shipilev at oracle.com  Fri Dec 21 02:55:46 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 21 Dec 2012 14:55:46 +0400
Subject: RFR (M) #4 CR 8003985: Support @Contended annotation
In-Reply-To: <50D43C94.4050809@oracle.com>
References: <50D437F7.207@oracle.com> <50D43C94.4050809@oracle.com>
Message-ID: <058DBC4C-0AEB-42A9-9D1A-95EF7F6DE4F5@oracle.com>



On 21.12.2012, at 14:40, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 21/12/2012 10:20, Aleksey Shipilev wrote:
>> Hi,
>> 
>> This is the final call for reviews for @Contended:
>>   http://cr.openjdk.java.net/~shade/8003985/webrev.00/
>> 
>> Testing:
>>  - Test8003985 passes on Linux x86_64
>>  - JPRT full cycle passed
>>  - VM adhoc tests are underway, but should be the same as previous
>> passed run, since there are no semantical changes
>> 
>> JEP-142 is in Funded state:
>>  http://openjdk.java.net/jeps/142
>> 
>> Thanks,
>> Aleksey.
> Has sun.misc.Contended been decided? I really think this needs to be moved to somewhere that can be supported, like jdk.vm.Contented. I did bring this up on c-i and Doug replied, I just haven't had the time to follow up on it.

There seems to be the consensus to keep it in sun.misc, with the tentative idea to graduate it to public API once/if we would overhaul the implications of doing that. But for pending JDK8 concurrency work it's well enough suited in sun.misc.

-Aleksey.

P.S. I'm actually wondering if we need the CCC for sun.misc additions? There is the request from me, but that might be as well accepted without further due diligence? The code review is still appreciated (though unnecessary given lots of prior reviews).

From kirk at kodewerk.com  Fri Dec 21 02:58:58 2012
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 21 Dec 2012 11:58:58 +0100
Subject: RFR (M) #4 CR 8003985: Support @Contended annotation
In-Reply-To: <50D43C94.4050809@oracle.com>
References: <50D437F7.207@oracle.com> <50D43C94.4050809@oracle.com>
Message-ID: <90E610B0-FEB7-46A2-96CA-E30C7FB6A23D@kodewerk.com>

Hi ```````````````````````````````````````````````````````````````````````````````````````````````````````Alan,

I believe to answer your question one would have to answer a broader question; is it in the long term direction to expose these low level operations to the general developer population or, will these "optimizations" be some how rolled into HotSpot where developers have traditionally expected them to be implemented. If there is a change in philosophy where by the JDK will expose these low level operations then I'd agree with you. However, should we not be asking the bigger question first?

Regards,
Kirk

On 2012-12-21, at 11:40 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 21/12/2012 10:20, Aleksey Shipilev wrote:
>> Hi,
>> 
>> This is the final call for reviews for @Contended:
>>   http://cr.openjdk.java.net/~shade/8003985/webrev.00/
>> 
>> Testing:
>>  - Test8003985 passes on Linux x86_64
>>  - JPRT full cycle passed
>>  - VM adhoc tests are underway, but should be the same as previous
>> passed run, since there are no semantical changes
>> 
>> JEP-142 is in Funded state:
>>  http://openjdk.java.net/jeps/142
>> 
>> Thanks,
>> Aleksey.
> Has sun.misc.Contended been decided? I really think this needs to be moved to somewhere that can be supported, like jdk.vm.Contented. I did bring this up on c-i and Doug replied, I just haven't had the time to follow up on it.
> 
> -Alan


From roland.westrelin at oracle.com  Fri Dec 21 03:30:17 2012
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Fri, 21 Dec 2012 11:30:17 +0000
Subject: hg: hsx/hotspot-main/hotspot: 17 new changesets
Message-ID: <20121221113102.8AAAA47330@hg.openjdk.java.net>

Changeset: 0c535211ef13
Author:    bharadwaj
Date:      2012-12-07 18:13 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0c535211ef13

8004668: Build failure for Zero target
Summary: fixed build failure for Zero target
Reviewed-by: twisti, kvn

! src/cpu/zero/vm/assembler_zero.cpp

Changeset: a70c88896791
Author:    kvn
Date:      2012-12-13 17:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a70c88896791

8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000
Summary: use unsigned comparison when checking for stack overflow
Reviewed-by: kvn, twisti
Contributed-by: paul.nauman at oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp

Changeset: 1b1e16471e46
Author:    stefank
Date:      2012-12-12 22:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b1e16471e46

8005002: Crash because of a raw oop in ClassLoaderData::add_dependency
Summary: Move the handelization of 'last' to a point before the GC might enter.
Reviewed-by: dholmes, sspitsyn, coleenp

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

Changeset: 5c0931d15474
Author:    twisti
Date:      2012-12-14 12:06 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5c0931d15474

8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java
Reviewed-by: jrose, kvn

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

Changeset: 3c433d080bae
Author:    twisti
Date:      2012-12-14 12:11 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c433d080bae

Merge


Changeset: 18d56ca3e901
Author:    twisti
Date:      2012-12-17 11:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/18d56ca3e901

8004548: remove unused AbstractAssembler::print(Label&)
Reviewed-by: kvn, twisti
Contributed-by: Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com>

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/assembler_zero.hpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp

Changeset: ad5dd04754ee
Author:    roland
Date:      2012-12-18 14:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ad5dd04754ee

8005031: Some cleanup in c2 to prepare for incremental inlining support
Summary: collection of small changes to prepare for incremental inlining.
Reviewed-by: twisti, kvn

! src/share/vm/ci/ciField.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/stringopts.cpp

Changeset: eb409f2f146e
Author:    vlivanov
Date:      2012-12-18 06:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eb409f2f146e

8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop
Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile.
Reviewed-by: kvn, jrose

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

Changeset: 620e502e3f47
Author:    vlivanov
Date:      2012-12-18 08:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/620e502e3f47

Merge

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

Changeset: c4bd2eccea46
Author:    twisti
Date:      2012-12-18 10:47 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c4bd2eccea46

8004536: replace AbstractAssembler emit_word with emit_int16
Reviewed-by: jrose, kvn, twisti
Contributed-by: Morris Meyer <morris.meyer at oracle.com>

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/asm/assembler.hpp

Changeset: 1e41b0bc58a0
Author:    kvn
Date:      2012-12-18 17:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1e41b0bc58a0

8004318: JEP-171: Support Unsafe fences intrinsics
Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class.
Reviewed-by: twisti, kvn
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/unsafe.cpp

Changeset: 65c8342f726a
Author:    twisti
Date:      2012-12-19 14:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/65c8342f726a

8005033: clear high word for integer pop count on SPARC
Reviewed-by: kvn, twisti
Contributed-by: Richard Reingruber <richard.reingruber at sap.com>

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/8005033/Test8005033.java

Changeset: 2c7f594145dc
Author:    kvn
Date:      2012-12-19 15:40 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c7f594145dc

8004835: Improve AES intrinsics on x86
Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs.
Reviewed-by: roland, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! test/compiler/7184394/TestAESBase.java
! test/compiler/7184394/TestAESMain.java

Changeset: 2d6c433b1f38
Author:    kvn
Date:      2012-12-19 19:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2d6c433b1f38

8004741: Missing compiled exception handle table entry for multidimensional array allocation
Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception.
Reviewed-by: twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
+ test/compiler/8004741/Test8004741.java

Changeset: a46457045d66
Author:    kvn
Date:      2012-12-20 14:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a46457045d66

8004330: Add missing Unsafe entry points for addAndGet() family
Summary: Fix java names for getAndSet intrinsics
Reviewed-by: kvn
Contributed-by: aleksey.shipilev at oracle.com

! src/share/vm/classfile/vmSymbols.hpp

Changeset: d02120b7a34f
Author:    twisti
Date:      2012-12-20 18:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d02120b7a34f

8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32
Reviewed-by: jrose, kvn, twisti
Contributed-by: Morris Meyer <morris.meyer at oracle.com>

! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp

Changeset: c52660592f37
Author:    roland
Date:      2012-12-21 01:39 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c52660592f37

Merge

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/opto/library_call.cpp


From vitalyd at gmail.com  Fri Dec 21 06:55:50 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 21 Dec 2012 09:55:50 -0500
Subject: RFR(M): Memory ordering in taskqueue.hpp
In-Reply-To: <50D3CD77.4090808@oracle.com>
References: <140FA3E3585AD840A3316D2853F974DC1BF749F3BB@DEWDFECCR03.wdf.sap.corp>
	<140FA3E3585AD840A3316D2853F974DC1BF759CF4A@DEWDFECCR03.wdf.sap.corp>
	<50CFB788.7080106@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF759D8CD@DEWDFECCR03.wdf.sap.corp>
	<50D05112.70506@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF76501D9@DEWDFECCR03.wdf.sap.corp>
	<50D26B81.8080903@oracle.com>
	<140FA3E3585AD840A3316D2853F974DC1BF699BBA0@DEWDFECCR03.wdf.sap.corp>
	<CAHjP37GerjPt3meYoj-tuk3ex37XNJbv1CniSEkW1JXfGy0BzQ@mail.gmail.com>
	<50D3CD77.4090808@oracle.com>
Message-ID: <CAHjP37ER2RU_KEc02EywG7mxQUGv+61nLBHT1+GvY6Bi+Go0Ug@mail.gmail.com>

I see, thanks.  While there are other fish to fry with OrderAccess, I think
using that inline asm for storestore should work just fine on the GCC
versions that you use (there's already other inline asm there for other
methods), at least until someone attempts to convert these to compiler
intrinsics.

Thanks

Sent from my phone
On Dec 20, 2012 9:46 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 21/12/2012 6:43 AM, Vitaly Davidovich wrote:
>
>> As an aside, how come storestore is not defined as "asm volatile ("" : :
>> : "memory");" on Linux x86/64?
>>
>
> We have an open RFE to improve things
>
> http://bugs.sun.com/view_bug.**do?bug_id=6975121<http://bugs.sun.com/view_bug.do?bug_id=6975121>
>
> 6975121 : OrderAccess should use compiler intrinsics where possible
>
> Our problem has always been getting the right support from the official
> compiler.
>
> David
> -----
>
>
>  Thanks
>>
>> Sent from my phone
>>
>> On Dec 20, 2012 3:24 PM, "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com
>> <mailto:goetz.lindenmaier at sap.**com <goetz.lindenmaier at sap.com>>> wrote:
>>
>>     Hi David,
>>
>>     I understand that you want selected corrections, not the
>>     solution we chose that does it everywhere.
>>
>>     But do you agree that our solution does not introduce any
>>     overhead on x86 and sparc?
>>
>>
>>
>>     I'll try to explain why I think this is the case using the
>>     example you brought up:
>>
>>     void set_empty() {
>>        _bottom = 0;
>>        _age.set(0);
>>     }
>>
>>     will result in something like
>>
>>       x86_64                      our ppc                our ia64
>>       ------                      -------                --------
>>       movl 0, _bottom             swz                    st4.rel
>>       movq 0, _age                sd                     st8.rel
>>
>>     which is correct on x86 and ia64, but wrong on power.
>>
>>     void set_empty() {
>>        _bottom = 0;
>>        OrderAccess::storestore();
>>        _age.set(0);
>>     }
>>
>>     will result in something like
>>
>>       x86_64                      our ppc                our ia64
>>       ------                      -------                --------
>>       movl 0, _bottom             swz                    st4.rel
>>       movl 0, local_dummy         lwsync                 mf
>>       movq 0, _age                sd                     st8.rel
>>
>>     which is correct, but inefficient on x86_64 (a bit) and ia64.
>>
>>     while
>>
>>     void set_empty() {
>>        _bottom =  0;
>>        OrderAccess::release_store_**ptr((volatile intptr_t*) &_age, 0);
>>     }
>>
>>     will result in
>>
>>       movl 0, _bottom             swz                    st4.rel
>>       movq 0, _age                lwsync; sd             st8.rel
>>
>>     which is correct and efficient.
>>
>>
>>
>>     By the way, if you have a PPC port, do you have a machine to build
>>     and run the openJDK PPC port?
>>
>>      > (modulo OrderAccess is far from perfect and has some outstanding
>>     issues).
>>     What are the problems of the OrderAccess implementation?
>>
>>     Best regards,
>>        Goetz.
>>
>>
>>
>>
>>
>>
>>     -----Original Message-----
>>     From: David Holmes [mailto:david.holmes at oracle.**com<david.holmes at oracle.com>
>>     <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>]
>>     Sent: Thursday, December 20, 2012 2:36 AM
>>     To: Lindenmaier, Goetz
>>     Cc: hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.**
>> java.net <hotspot-dev at openjdk.java.net>>
>>     Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>
>>     On 20/12/2012 2:48 AM, Lindenmaier, Goetz wrote:
>>      > Hi David,
>>      >
>>      > first, thanks for the fast replies. Sorry it took me a day now!
>>
>>     No problem. I can't guarantee response times either :)
>>
>>      >> I didn't say that. I said these two need to be ordered and asked
>>     which
>>      >> other paired accesses to these variables need to be ordered.
>>      > Together with a colleague I looked at the code. To us it seems
>>      > very hard to identify places where access ordering is not needed.
>>      > Especially we think there will be places in the users of the
>>      > task queue that would need barriers to ensure ordering.
>>      > But we think, the algorithm should be self-contained, doing all the
>>      > required ordering itself.
>>
>>     I agree the algorithm should be self-contained. My point is that in
>>     other places where we implement lock-free algorithm was put in the
>>     barriers/fences in the algorithmic code in the places needed we don't
>>     automatically wrap all of the variables accesses with code that
>>     introduces pre/post barriers (of whatever form).
>>
>>      > Further, a barrier will spoil performance on x86 etc, because
>>     there it
>>      > issues a lock instruction, which is not needed.
>>
>>     You issue the appropriate barrier/fence for the situation and they
>>     should be implemented in whatever form needed for the given platform
>>     (modulo OrderAccess is far from perfect and has some outstanding
>>     issues).
>>
>>      >> I said that what you were doing was effectively treating the C++
>>     variables
>>      >> as if they were Java volatile variables. That's not the way we
>>     handle
>>      >> these issues in the VM we tend to place fences/barriers at the
>>     places in
>>      >> lock-free algorithms that need them, rather than wrap the
>>     variables in
>>      >> accessors that impose fences/barriers that are not always needed.
>>      >
>>      > As we understand, the C compilers on x86, sparc etc, enforce far
>> more
>>      > than required to implement C++ volatile, basically treating the
>>     fields
>>      > like Java volatiles.  Therefore your code is fine on your
>> platforms.
>>
>>     I think you are confusing things. The existing C/C++ compilers do very
>>     little in regard to "volatile". It is only the latest multi-threading
>>     variant of the C++ standard that even addresses this! Our C/C++
>>     compilers never issue any kind of memory barriers in response to a
>>     load/store of a volatile variable.
>>
>>      > The C++ compilers on PPC optimize far more, maxing out
>>      > what the standard allows and the processer supports, leading to
>>      > immediate errors, but also to very subtle ones.
>>      >
>>      > Our change makes explicit what the C compilers (except for PPC) do
>>      > anyways, and what is required by the algorithm. (Maybe one could
>> now
>>      > even omit the volatile keywords - but we dare not try.) Thus, we
>> get
>>      > it right without any overhead on your platforms.
>>
>>     This is getting things confused. The lock-free algorithms should be
>>     written for the most lenient of memory-models and make no assumptions
>>     about ordering. They should use the appropriate OrderAccess method
>> where
>>     needed for algorithmic correctness.
>>
>>     You proposal wraps the C variable in accessors that use OrderAccess
>>     operations on every access - in a similar way to how we have to handle
>>     Java volatile accesses. And as I have said that is not the style we
>> use
>>     in hotspot's lock-free code. This has nothing to do with our compiler
>>     versus your compiler (though if you have one that issues
>> memory-barriers
>>     directly then you'll get too much overhead.)
>>
>>      >> Though we have not run into this particular issue. Did
>>      >> it arise in the context of a particular GC?
>>      > Issues are only on PPC, at least in parallelScavenge. I reproduced
>>      > some of the immediate errors, but I don't think this really helps
>>     with
>>      > the discussion.  I will try G1 soon.  Tell me if you want to know
>>      > more, then I'll try to come up with a wrap-up of our past fixes.
>>
>>     We have a PPC product and as I said we have not encountered this
>>     problem, but we also run with limited GCs so may not have been
>>     exercising this code.
>>
>>     Thanks,
>>     David
>>
>>      > Best regards,
>>      >    Goetz.
>>      >
>>      >
>>      > -----Original Message-----
>>      > From: David Holmes [mailto:david.holmes at oracle.**com<david.holmes at oracle.com>
>>     <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>]
>>      > Sent: Dienstag, 18. Dezember 2012 12:19
>>      > To: Lindenmaier, Goetz
>>      > Cc: hotspot-dev at openjdk.java.net
>>     <mailto:hotspot-dev at openjdk.**java.net <hotspot-dev at openjdk.java.net>
>> >
>>      > Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>      >
>>      > Hi Goetz,
>>      >
>>      > On 18/12/2012 8:47 PM, Lindenmaier, Goetz wrote:
>>      >> Hi David,
>>      >>
>>      >> why do you think only these two accesses have to be ordered?
>>      >
>>      > I didn't say that. I said these two need to be ordered and asked
>>     which
>>      > other paired accesses to these variables need to be ordered.
>>      >
>>      >> As I understand, any two accesses in one thread to these fields
>>     have to be
>>      >> orderered and must be written to memory to become visible in the
>>     proper order
>>      >> to other threads.
>>      >
>>      > That depends on how they are used. It is the overall lock-free
>>     algorithm
>>      > that is important here. There may be places where the order of
>> access
>>      > does not matter (and there may not be).
>>      >
>>      >> The PPC compiler really takes all advantages given by the
>>      >> C-Standard to optimize this, and the processor reorders heavily.
>>      >
>>      > Yes I understand. Though we have not run into this particular
>>     issue. Did
>>      > it arise in the context of a particular GC?
>>      >
>>      >> The specification of volatile in
>>      >>          Age get() const volatile { return _data; }
>>      >> says that it must be read from memory, not that it can not be
>>     reordered.
>>      >
>>      > I didn't say anything about C/C++ volatile (which doesn't even say
>> it
>>      > must be read from memory - except perhaps in latest MT C++
>>     standard?). I
>>      > said that what you were doing was effectively treating the C++
>>     variables
>>      > as if they were Java volatile variables. That's not the way we
>> handle
>>      > these issues in the VM we tend to place fences/barriers at the
>>     places in
>>      > lock-free algorithms that need them, rather than wrap the
>>     variables in
>>      > accessors that impose fences/barriers that are not always needed.
>>      >
>>      > Cheers,
>>      > David
>>      >
>>      >> Also, doing
>>      >>         OrderAccess::load_acquire((**volatile
>>     idx_t*)&(_age._fields._top))
>>      >> is better wrt. to optimizations by C-compilers, as there first
>>      >> is the whole address computation, and then the cast to volatile.
>>      >> If we use
>>      >>         _age.top()
>>      >> with
>>      >>         idx_t top() const volatile { return
>>     OrderAccess::load_acquire((**volatile idx_t*)&(_fields._top); }
>>      >> compilers don't optimize that well.  (We saw this on hpia64.)
>>      >> Further, the access to, e.g., old_age.top() in pop_local_slow()
>>     would do
>>      >> the OrderAccess, which is useless overhead.
>>      >>
>>      >> Best regards,
>>      >>     Goetz.
>>      >>
>>      >>
>>      >> -----Original Message-----
>>      >> From: David Holmes [mailto:david.holmes at oracle.**com<david.holmes at oracle.com>
>>     <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>]
>>      >> Sent: Dienstag, 18. Dezember 2012 01:24
>>      >> To: Lindenmaier, Goetz
>>      >> Cc: hotspot-dev at openjdk.java.net
>>     <mailto:hotspot-dev at openjdk.**java.net <hotspot-dev at openjdk.java.net>
>> >
>>      >> Subject: Re: RFR(M): Memory ordering in taskqueue.hpp
>>      >>
>>      >> Hi Goetz,
>>      >>
>>      >> On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
>>      >>> Hi,
>>      >>>
>>      >>> Once more, with webrev:
>>      >>> http://cr.openjdk.java.net/~**goetz/webrevs/webrev-**taskqueue/<http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/>
>>      >>
>>      >> I can see that this function needs a storestore barrier:
>>      >>
>>      >>     237   void set_empty() {
>>      >>     238     _bottom = 0;
>>      >>     239     _age.set(0);
>>      >>     240   }
>>      >>
>>      >> to preserve ordering. Are there other functions to which we can
>>      >> constrain the loadload and storestore barriers rather than using
>> the
>>      >> setters/getters the way you have defined? This is always about a
>>     pair
>>      >> (sometimes groups) of accesses so I'd rather deal with the pairs
>>     than
>>      >> treat each field as if it were a Java volatile.
>>      >>
>>      >> Thanks,
>>      >> David Holmes
>>      >>
>>      >>
>>      >>> Sorry for that.
>>      >>>
>>      >>> I would like to contribute fixes wrt. memory ordering in
>>     taskqueue.hpp.
>>      >>>
>>      >>> On Platfoms with weak memory ordering the taskqueue is not
>> accessed
>>      >>> properly, as the accesses to the fields _bottom and _age are
>>     not ordered
>>      >>> correctly. Volatile is not sufficient to enforce this, because
>>     it depends on
>>      >>> what the compiler assumes to be necessary for volatile variables.
>>      >>>
>>      >>> The fix is to pull getter/setter routines from Age to
>>     TaskQueueSuper and use methods from
>>      >>> OrderAccess to access the fields in _age as well as _bottom.
>>     Further the code must always
>>      >>> use the getter/setter methods to access _bottom, _age or the
>>     subfields of _age.
>>      >>> On the other hand we can relax constraints for accesses to
>>     locals oldAge and newAge.
>>      >>>
>>      >>> The OrderAccess routines do simple load/stores on x86_64.
>>      >>>
>>      >>> I want to discuss this change here and would like very much to
>>     see it taking
>>      >>> it's way into OpenJDK to support ports on platforms with weak
>>     memory
>>      >>> ordering, and, in particular, our PPC port.
>>      >>>
>>      >>> Best regards,
>>      >>>      Goetz.
>>      >>>
>>      >>>
>>
>>

From mark.reinhold at oracle.com  Fri Dec 21 09:10:56 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 21 Dec 2012 09:10:56 -0800
Subject: RFR (M) #4 CR 8003985: Support @Contended annotation
In-Reply-To: alan.bateman@oracle.com; Fri, 21 Dec 2012 10:40:20 GMT;
	<50D43C94.4050809@oracle.com>
Message-ID: <20121221171056.C4DC51759@eggemoggin.niobe.net>

2012/12/21 2:40 -0800, alan.bateman at oracle.com:
> On 21/12/2012 10:20, Aleksey Shipilev wrote:
>> This is the final call for reviews for @Contended:
>> http://cr.openjdk.java.net/~shade/8003985/webrev.00/

The copyright line in Contended.java says 2005.

>> ...
> 
> Has sun.misc.Contended been decided? I really think this needs to be moved to
> somewhere that can be supported, like jdk.vm.Contented. I did bring this up on
> c-i and Doug replied, I just haven't had the time to follow up on it.

I don't think we should make any kind of support commitment to this
annotation at this time.  In this release it's intended only for use by
the java.util.concurrent implementation.  (Yes, I recognize that others
will use it explicitly, but they'll be playing with fire.)

If this annotation belongs anywhere else than sun.misc then that's in
a package whose name contains the string "internal", which is the only
means we have now of identifying an API as being strictly for internal
use.  Given that @Contains is closely related to sun.misc.Unsafe, though,
and given that the sun.misc package will most likely disappear in JDK 9,
I can live with it being in sun.misc for JDK 8.

- Mark

From jesper.wilhelmsson at oracle.com  Fri Dec 21 09:23:50 2012
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 21 Dec 2012 17:23:50 +0000
Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets
Message-ID: <20121221172406.9B79B47339@hg.openjdk.java.net>

Changeset: 0b3d19153cc6
Author:    johnc
Date:      2012-12-12 12:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0b3d19153cc6

8001028: Improve GC option handling
Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class.
Reviewed-by: jwilhelm, dholmes, coleenp

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

Changeset: 730cc4ddd550
Author:    brutisso
Date:      2012-12-17 08:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/730cc4ddd550

7173959: Jvm crashed during coherence exabus (tmb) testing
Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com
Reviewed-by: dholmes, coleenp, zgu

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp

Changeset: 32164d89fe9c
Author:    brutisso
Date:      2012-12-17 15:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/32164d89fe9c

8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects
Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private
Reviewed-by: dholmes, coleenp
Contributed-by: erik.helin at oracle.com

! src/share/vm/memory/allocation.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/services/memBaseline.hpp
! src/share/vm/utilities/workgroup.hpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: c71879335291
Author:    stefank
Date:      2012-12-18 10:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c71879335291

8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers
Summary: Reverted the changes to these functions from JDK-8000662
Reviewed-by: brutisso, jmasa

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

Changeset: 345bd97a77be
Author:    brutisso
Date:      2012-12-20 05:31 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/345bd97a77be

8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag
Reviewed-by: stefank, brutisso, kvn, ctornqvi
Contributed-by: erik.helin at oracle.com

+ test/sanity/ExecuteInternalVMTests.java

Changeset: 69627aa9ab10
Author:    jwilhelm
Date:      2012-12-21 16:33 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69627aa9ab10

Merge

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


From alejandro.murillo at oracle.com  Fri Dec 21 12:27:20 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 21 Dec 2012 20:27:20 +0000
Subject: hg: hsx/hsx25/hotspot: 34 new changesets
Message-ID: <20121221202827.57EDC4734F@hg.openjdk.java.net>

Changeset: 8b4810c80f5d
Author:    katleman
Date:      2012-12-20 09:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b4810c80f5d

Added tag jdk8-b69 for changeset cb8a4e04bc8c

! .hgtags

Changeset: 1f323009c3ea
Author:    amurillo
Date:      2012-12-14 14:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f323009c3ea

8005036: new hotspot build - hs25-b14
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 892acf0431ef
Author:    dcubed
Date:      2012-12-14 10:06 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/892acf0431ef

7153050: remove crufty '_g' support from HotSpot repo makefiles
Summary: Phase 1 is removing '_g' support from the Makefiles.
Reviewed-by: dcubed, sspitsyn, coleenp, tbell
Contributed-by: ron.durbin at oracle.com

! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/debug.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/fastdebug.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jsig.make
! make/bsd/makefiles/jvmg.make
! make/bsd/makefiles/optimized.make
! make/bsd/makefiles/product.make
! make/bsd/makefiles/saproc.make
! make/bsd/makefiles/vm.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/debug.make
! make/linux/makefiles/fastdebug.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/jsig.make
! make/linux/makefiles/jvmg.make
! make/linux/makefiles/optimized.make
! make/linux/makefiles/product.make
! make/linux/makefiles/saproc.make
! make/linux/makefiles/vm.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/debug.make
! make/solaris/makefiles/dtrace.make
! make/solaris/makefiles/fastdebug.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/jsig.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/product.make
! make/solaris/makefiles/saproc.make
! make/solaris/makefiles/vm.make
! make/windows/build.make
! make/windows/projectfiles/compiler2/ADLCompiler.dsp
! make/windows/projectfiles/tiered/ADLCompiler.dsp

Changeset: 30866cd626b0
Author:    coleenp
Date:      2012-12-12 11:39 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/30866cd626b0

8004883: NPG: clean up anonymous class fix
Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not.
Reviewed-by: stefank, jrose

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.hpp

Changeset: 18712b1caf7a
Author:    rkennke
Date:      2012-12-12 21:40 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/18712b1caf7a

8004898: library_call.cpp build error after 7172640 with GCC 4.7.2
Summary: fix opto/library_call.cpp compilation errors
Reviewed-by: twisti, coleenp

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

Changeset: 8580f22db905
Author:    coleenp
Date:      2012-12-14 16:43 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8580f22db905

Merge


Changeset: 3f84e17b6bca
Author:    zgu
Date:      2012-12-17 13:14 -0500
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3f84e17b6bca

8004802: jcmd VM.native_memory baseline=false crashes VM
Summary: NMT has to check option's value also to determine which command to execute
Reviewed-by: acorn, coleenp, hseigel

! src/share/vm/services/nmtDCmd.cpp

Changeset: 805aa223d540
Author:    zgu
Date:      2012-12-17 10:40 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/805aa223d540

Merge


Changeset: 594b9b2119ed
Author:    minqi
Date:      2012-12-19 16:10 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/594b9b2119ed

Merge


Changeset: 0c535211ef13
Author:    bharadwaj
Date:      2012-12-07 18:13 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0c535211ef13

8004668: Build failure for Zero target
Summary: fixed build failure for Zero target
Reviewed-by: twisti, kvn

! src/cpu/zero/vm/assembler_zero.cpp

Changeset: a70c88896791
Author:    kvn
Date:      2012-12-13 17:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a70c88896791

8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000
Summary: use unsigned comparison when checking for stack overflow
Reviewed-by: kvn, twisti
Contributed-by: paul.nauman at oracle.com

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp

Changeset: 1b1e16471e46
Author:    stefank
Date:      2012-12-12 22:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b1e16471e46

8005002: Crash because of a raw oop in ClassLoaderData::add_dependency
Summary: Move the handelization of 'last' to a point before the GC might enter.
Reviewed-by: dholmes, sspitsyn, coleenp

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

Changeset: 5c0931d15474
Author:    twisti
Date:      2012-12-14 12:06 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5c0931d15474

8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java
Reviewed-by: jrose, kvn

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

Changeset: 3c433d080bae
Author:    twisti
Date:      2012-12-14 12:11 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c433d080bae

Merge


Changeset: 18d56ca3e901
Author:    twisti
Date:      2012-12-17 11:00 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/18d56ca3e901

8004548: remove unused AbstractAssembler::print(Label&)
Reviewed-by: kvn, twisti
Contributed-by: Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com>

! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/assembler_zero.hpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp

Changeset: ad5dd04754ee
Author:    roland
Date:      2012-12-18 14:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ad5dd04754ee

8005031: Some cleanup in c2 to prepare for incremental inlining support
Summary: collection of small changes to prepare for incremental inlining.
Reviewed-by: twisti, kvn

! src/share/vm/ci/ciField.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/stringopts.cpp

Changeset: eb409f2f146e
Author:    vlivanov
Date:      2012-12-18 06:52 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/eb409f2f146e

8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop
Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile.
Reviewed-by: kvn, jrose

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

Changeset: 620e502e3f47
Author:    vlivanov
Date:      2012-12-18 08:19 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/620e502e3f47

Merge

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

Changeset: c4bd2eccea46
Author:    twisti
Date:      2012-12-18 10:47 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c4bd2eccea46

8004536: replace AbstractAssembler emit_word with emit_int16
Reviewed-by: jrose, kvn, twisti
Contributed-by: Morris Meyer <morris.meyer at oracle.com>

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/asm/assembler.hpp

Changeset: 1e41b0bc58a0
Author:    kvn
Date:      2012-12-18 17:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1e41b0bc58a0

8004318: JEP-171: Support Unsafe fences intrinsics
Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class.
Reviewed-by: twisti, kvn
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/unsafe.cpp

Changeset: 65c8342f726a
Author:    twisti
Date:      2012-12-19 14:44 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/65c8342f726a

8005033: clear high word for integer pop count on SPARC
Reviewed-by: kvn, twisti
Contributed-by: Richard Reingruber <richard.reingruber at sap.com>

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/8005033/Test8005033.java

Changeset: 2c7f594145dc
Author:    kvn
Date:      2012-12-19 15:40 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c7f594145dc

8004835: Improve AES intrinsics on x86
Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs.
Reviewed-by: roland, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! test/compiler/7184394/TestAESBase.java
! test/compiler/7184394/TestAESMain.java

Changeset: 2d6c433b1f38
Author:    kvn
Date:      2012-12-19 19:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2d6c433b1f38

8004741: Missing compiled exception handle table entry for multidimensional array allocation
Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception.
Reviewed-by: twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
+ test/compiler/8004741/Test8004741.java

Changeset: a46457045d66
Author:    kvn
Date:      2012-12-20 14:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a46457045d66

8004330: Add missing Unsafe entry points for addAndGet() family
Summary: Fix java names for getAndSet intrinsics
Reviewed-by: kvn
Contributed-by: aleksey.shipilev at oracle.com

! src/share/vm/classfile/vmSymbols.hpp

Changeset: d02120b7a34f
Author:    twisti
Date:      2012-12-20 18:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d02120b7a34f

8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32
Reviewed-by: jrose, kvn, twisti
Contributed-by: Morris Meyer <morris.meyer at oracle.com>

! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/zero/vm/assembler_zero.cpp
! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp

Changeset: c52660592f37
Author:    roland
Date:      2012-12-21 01:39 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c52660592f37

Merge

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/opto/library_call.cpp

Changeset: 0b3d19153cc6
Author:    johnc
Date:      2012-12-12 12:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0b3d19153cc6

8001028: Improve GC option handling
Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class.
Reviewed-by: jwilhelm, dholmes, coleenp

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

Changeset: 730cc4ddd550
Author:    brutisso
Date:      2012-12-17 08:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/730cc4ddd550

7173959: Jvm crashed during coherence exabus (tmb) testing
Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com
Reviewed-by: dholmes, coleenp, zgu

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp

Changeset: 32164d89fe9c
Author:    brutisso
Date:      2012-12-17 15:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/32164d89fe9c

8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects
Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private
Reviewed-by: dholmes, coleenp
Contributed-by: erik.helin at oracle.com

! src/share/vm/memory/allocation.hpp
! src/share/vm/opto/node.cpp
! src/share/vm/services/memBaseline.hpp
! src/share/vm/utilities/workgroup.hpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: c71879335291
Author:    stefank
Date:      2012-12-18 10:40 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c71879335291

8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers
Summary: Reverted the changes to these functions from JDK-8000662
Reviewed-by: brutisso, jmasa

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

Changeset: 345bd97a77be
Author:    brutisso
Date:      2012-12-20 05:31 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/345bd97a77be

8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag
Reviewed-by: stefank, brutisso, kvn, ctornqvi
Contributed-by: erik.helin at oracle.com

+ test/sanity/ExecuteInternalVMTests.java

Changeset: 69627aa9ab10
Author:    jwilhelm
Date:      2012-12-21 16:33 +0100
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69627aa9ab10

Merge

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

Changeset: 990bbd393c23
Author:    amurillo
Date:      2012-12-21 10:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/990bbd393c23

Merge


Changeset: 6a1fc440b396
Author:    amurillo
Date:      2012-12-21 10:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6a1fc440b396

Added tag hs25-b14 for changeset 990bbd393c23

! .hgtags


From alejandro.murillo at oracle.com  Fri Dec 21 14:05:18 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 21 Dec 2012 22:05:18 +0000
Subject: hg: hsx/hsx24/hotspot: 3 new changesets
Message-ID: <20121221220528.8860D47355@hg.openjdk.java.net>

Changeset: ac7586ad8eae
Author:    katleman
Date:      2012-12-19 15:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ac7586ad8eae

Added tag jdk7u12-b06 for changeset 2e497fde1807

! .hgtags

Changeset: c5ee80cc0623
Author:    amurillo
Date:      2012-12-21 11:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c5ee80cc0623

Merge


Changeset: 4f7ad6299356
Author:    amurillo
Date:      2012-12-21 11:48 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4f7ad6299356

Added tag hs24-b28 for changeset c5ee80cc0623

! .hgtags


From alejandro.murillo at oracle.com  Fri Dec 21 15:28:40 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 21 Dec 2012 23:28:40 +0000
Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets
Message-ID: <20121221232850.5DDB94735E@hg.openjdk.java.net>

Changeset: 8b4810c80f5d
Author:    katleman
Date:      2012-12-20 09:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b4810c80f5d

Added tag jdk8-b69 for changeset cb8a4e04bc8c

! .hgtags

Changeset: 990bbd393c23
Author:    amurillo
Date:      2012-12-21 10:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/990bbd393c23

Merge


Changeset: 6a1fc440b396
Author:    amurillo
Date:      2012-12-21 10:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6a1fc440b396

Added tag hs25-b14 for changeset 990bbd393c23

! .hgtags

Changeset: cd962e15c08e
Author:    amurillo
Date:      2012-12-21 10:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd962e15c08e

8005382: new hotspot build - hs25-b15
Reviewed-by: jcoomes

! make/hotspot_version


From ChrisPhi at LGonQn.Org  Fri Dec 21 15:34:18 2012
From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O)
Date: Fri, 21 Dec 2012 18:34:18 -0500
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated]
Message-ID: <50D4F1FA.7090008@LGonQn.Org>

Hi

{Not sure if this needs a new bug or not, it definitely needs a sponsor
- Twisti ? }

Attached is a backport (essentially resurrection of the Permgen code)
of 8000780 now updated with Roman Kennke's comments. Checked and built
against hsx24b28. (Current jdk7u-dev hs)

Please review.

Cheers!
Chris
 PS
Webrev is here:
http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/





From alejandro.murillo at oracle.com  Fri Dec 21 16:40:27 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 21 Dec 2012 17:40:27 -0700
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
	[updated]
In-Reply-To: <50D4F1FA.7090008@LGonQn.Org>
References: <50D4F1FA.7090008@LGonQn.Org>
Message-ID: <50D5017B.20305@oracle.com>


On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:
> Hi
>
> {Not sure if this needs a new bug or not, it definitely needs a sponsor
> - Twisti ? }
>
> Attached is a backport (essentially resurrection of the Permgen code)
> of 8000780 now updated with Roman Kennke's comments. Checked and built
> against hsx24b28. (Current jdk7u-dev hs)
>
> Please review.
>
> Cheers!
> Chris
>   PS
> Webrev is here:
> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/

Hi
jdk7u-dev/hotspot corresponds to hs24-b27.
I just got the hs24 snapshot for b28 and bumped the number to b29,
Can you rework the patch/webrev against this repo:

  http://hg.openjdk.java.net/hsx/hsx24/hotspot

once it's reviewed I can push it

Thanks

-- 
Alejandro


From alejandro.murillo at oracle.com  Fri Dec 21 16:58:35 2012
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Sat, 22 Dec 2012 00:58:35 +0000
Subject: hg: hsx/hsx24/hotspot: 8005383: new hotspot build - hs24-b29
Message-ID: <20121222005840.5126147360@hg.openjdk.java.net>

Changeset: df85f4f70d8f
Author:    amurillo
Date:      2012-12-21 11:56 -0800
URL:       http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/df85f4f70d8f

8005383: new hotspot build - hs24-b29
Reviewed-by: jcoomes

! make/hotspot_version


From ChrisPhi at LGonQn.Org  Fri Dec 21 20:53:49 2012
From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O)
Date: Fri, 21 Dec 2012 23:53:49 -0500
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
	[updated]
In-Reply-To: <50D5017B.20305@oracle.com>
References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com>
Message-ID: <50D53CDD.9090109@LGonQn.Org>

Hi Alejandro,

The only change since I tested this afternoon is the change
for the hotspot_version. I will re-run tests if you wish but it seems
unnecessary.

Cheers!
Chris

On 21/12/12 07:40 PM, Alejandro E Murillo wrote:
>
> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:
>> Hi
>>
>> {Not sure if this needs a new bug or not, it definitely needs a sponsor
>> - Twisti ? }
>>
>> Attached is a backport (essentially resurrection of the Permgen code)
>> of 8000780 now updated with Roman Kennke's comments. Checked and built
>> against hsx24b28. (Current jdk7u-dev hs)
>>
>> Please review.
>>
>> Cheers!
>> Chris
>>   PS
>> Webrev is here:
>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/
>
> Hi
> jdk7u-dev/hotspot corresponds to hs24-b27.
> I just got the hs24 snapshot for b28 and bumped the number to b29,
> Can you rework the patch/webrev against this repo:
>
>  http://hg.openjdk.java.net/hsx/hsx24/hotspot
>
> once it's reviewed I can push it
>
> Thanks
>


From John.Coomes at oracle.com  Sat Dec 22 01:31:02 2012
From: John.Coomes at oracle.com (John Coomes)
Date: Sat, 22 Dec 2012 01:31:02 -0800
Subject: CFV: New HSX Reviewer: Stefan Karlsson
In-Reply-To: <50D29225.7000009@oracle.com>
References: <50D29225.7000009@oracle.com>
Message-ID: <20693.32214.405121.610434@oracle.com>

Vote: yes

-John

From ChrisPhi at LGonQn.Org  Sat Dec 22 09:52:20 2012
From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O)
Date: Sat, 22 Dec 2012 12:52:20 -0500
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
	[updated]
In-Reply-To: <50D5017B.20305@oracle.com>
References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com>
Message-ID: <50D5F354.8040900@LGonQn.Org>

On 21/12/12 07:40 PM, Alejandro E Murillo wrote:
>
> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:
>> Hi
>>
>> {Not sure if this needs a new bug or not, it definitely needs a sponsor
>> - Twisti ? }
>>
>> Attached is a backport (essentially resurrection of the Permgen code)
>> of 8000780 now updated with Roman Kennke's comments. Checked and built
>> against hsx24b28. (Current jdk7u-dev hs)
>>
>> Please review.
>>
>> Cheers!
>> Chris
>>   PS
>> Webrev is here:
>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/
>
> Hi
> jdk7u-dev/hotspot corresponds to hs24-b27.
> I just got the hs24 snapshot for b28 and bumped the number to b29,
> Can you rework the patch/webrev against this repo:
>
>  http://hg.openjdk.java.net/hsx/hsx24/hotspot
>
> once it's reviewed I can push it
>
> Thanks
>
Hi

The previous patch/webrev were incorrectly generated, so I have done as you
requested and regenerated / tested against both hsx24b29 and  jdk7u-dev
(hs24b27).

Webrev:
http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/


Chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jdk7u-dev-zero-hs24b29.export
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20121222/3a568503/jdk7u-dev-zero-hs24b29-0001.export 

From alejandro.murillo at oracle.com  Sat Dec 22 10:03:22 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Sat, 22 Dec 2012 11:03:22 -0700
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
	[updated]
In-Reply-To: <50D53CDD.9090109@LGonQn.Org>
References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com>
	<50D53CDD.9090109@LGonQn.Org>
Message-ID: <50D5F5EA.2020902@oracle.com>


Hi Chris,
In that case is not necessary.
  I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot
but looks like it is against hsx/hsx24/hotspot.
BTW, I went to check the webrev link and is unreachable, can you check that?
Thanks
Alejandro

On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote:
> Hi Alejandro,
>
> The only change since I tested this afternoon is the change
> for the hotspot_version. I will re-run tests if you wish but it seems
> unnecessary.
>
> Cheers!
> Chris
>
> On 21/12/12 07:40 PM, Alejandro E Murillo wrote:
>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:
>>> Hi
>>>
>>> {Not sure if this needs a new bug or not, it definitely needs a sponsor
>>> - Twisti ? }
>>>
>>> Attached is a backport (essentially resurrection of the Permgen code)
>>> of 8000780 now updated with Roman Kennke's comments. Checked and built
>>> against hsx24b28. (Current jdk7u-dev hs)
>>>
>>> Please review.
>>>
>>> Cheers!
>>> Chris
>>>    PS
>>> Webrev is here:
>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/
>> Hi
>> jdk7u-dev/hotspot corresponds to hs24-b27.
>> I just got the hs24 snapshot for b28 and bumped the number to b29,
>> Can you rework the patch/webrev against this repo:
>>
>>   http://hg.openjdk.java.net/hsx/hsx24/hotspot
>>
>> once it's reviewed I can push it
>>
>> Thanks
>>


From ChrisPhi at LGonQn.Org  Sat Dec 22 10:15:27 2012
From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O)
Date: Sat, 22 Dec 2012 13:15:27 -0500
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
	[updated]
In-Reply-To: <50D5F5EA.2020902@oracle.com>
References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com>
	<50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com>
Message-ID: <50D5F8BF.1030000@LGonQn.Org>

Hi Alejandro,
Oops emails crossed in the net ...
See my latest email , I had to regenerate the webrev and patch -
This webrev s/b ok:

Webrev:
http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/


Chris

On 22/12/12 01:03 PM, Alejandro E Murillo wrote:
>
> Hi Chris,
> In that case is not necessary.
>  I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot
> but looks like it is against hsx/hsx24/hotspot.
> BTW, I went to check the webrev link and is unreachable, can you check
> that?
> Thanks
> Alejandro
>
> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote:
>> Hi Alejandro,
>>
>> The only change since I tested this afternoon is the change
>> for the hotspot_version. I will re-run tests if you wish but it seems
>> unnecessary.
>>
>> Cheers!
>> Chris
>>
>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote:
>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:
>>>> Hi
>>>>
>>>> {Not sure if this needs a new bug or not, it definitely needs a
>>>> sponsor
>>>> - Twisti ? }
>>>>
>>>> Attached is a backport (essentially resurrection of the Permgen code)
>>>> of 8000780 now updated with Roman Kennke's comments. Checked and built
>>>> against hsx24b28. (Current jdk7u-dev hs)
>>>>
>>>> Please review.
>>>>
>>>> Cheers!
>>>> Chris
>>>>    PS
>>>> Webrev is here:
>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/
>>>>
>>> Hi
>>> jdk7u-dev/hotspot corresponds to hs24-b27.
>>> I just got the hs24 snapshot for b28 and bumped the number to b29,
>>> Can you rework the patch/webrev against this repo:
>>>
>>>   http://hg.openjdk.java.net/hsx/hsx24/hotspot
>>>
>>> once it's reviewed I can push it
>>>
>>> Thanks
>>>
>
>
>


From alejandro.murillo at oracle.com  Sat Dec 22 10:27:57 2012
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Sat, 22 Dec 2012 11:27:57 -0700
Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev
	[updated]
In-Reply-To: <50D5F8BF.1030000@LGonQn.Org>
References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com>
	<50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com>
	<50D5F8BF.1030000@LGonQn.Org>
Message-ID: <50D5FBAD.8070001@oracle.com>


oh yeah, hadn't seen your email.
Can reach the link now, thanks.
Once this is reviewed  either Chris (Thalinger) or myself  will get it 
into hs24
Note that there won't be any snapshot for hs24 in the next few weeks due to
the holidays, so it won't be in the 7u master for a while

Thanks
Alejandro

On 12/22/2012 11:15 AM, Chris Phillips @ T O wrote:
> Hi Alejandro,
> Oops emails crossed in the net ...
> See my latest email , I had to regenerate the webrev and patch -
> This webrev s/b ok:
>
> Webrev:
> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/
>
>
> Chris
>
> On 22/12/12 01:03 PM, Alejandro E Murillo wrote:
>> Hi Chris,
>> In that case is not necessary.
>>   I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot
>> but looks like it is against hsx/hsx24/hotspot.
>> BTW, I went to check the webrev link and is unreachable, can you check
>> that?
>> Thanks
>> Alejandro
>>
>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote:
>>> Hi Alejandro,
>>>
>>> The only change since I tested this afternoon is the change
>>> for the hotspot_version. I will re-run tests if you wish but it seems
>>> unnecessary.
>>>
>>> Cheers!
>>> Chris
>>>
>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote:
>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:
>>>>> Hi
>>>>>
>>>>> {Not sure if this needs a new bug or not, it definitely needs a
>>>>> sponsor
>>>>> - Twisti ? }
>>>>>
>>>>> Attached is a backport (essentially resurrection of the Permgen code)
>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and built
>>>>> against hsx24b28. (Current jdk7u-dev hs)
>>>>>
>>>>> Please review.
>>>>>
>>>>> Cheers!
>>>>> Chris
>>>>>     PS
>>>>> Webrev is here:
>>>>> http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/
>>>>>
>>>> Hi
>>>> jdk7u-dev/hotspot corresponds to hs24-b27.
>>>> I just got the hs24 snapshot for b28 and bumped the number to b29,
>>>> Can you rework the patch/webrev against this repo:
>>>>
>>>>    http://hg.openjdk.java.net/hsx/hsx24/hotspot
>>>>
>>>> once it's reviewed I can push it
>>>>
>>>> Thanks
>>>>
>>
>>


From erik.joelsson at oracle.com  Thu Dec 27 03:08:04 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 27 Dec 2012 12:08:04 +0100
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <50DC2A60.4060505@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com>
Message-ID: <50DC2C14.1090702@oracle.com>

Adding hotspot-dev to cc since it's failing in hotspot.

On 2012-12-27 12:00, mikhail cherkasov wrote:
> I attached builds log file.
>
> 27.12.2012 14:24, Erik Joelsson ?????:
>> Hello,
>>
>> Which set of repositories did you clone?
>>
>> /Erik
>>
>> On 2012-12-26 14:16, mikhail cherkasov wrote:
>>> Hi All,
>>>
>>> I have the following error during build:
>>>
>>> Linking vm...
>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:27:54: 
>>> error: JavaNativeFoundation/JavaNativeFoundation.h: No such file or 
>>> directory
>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m: 
>>> In function 
>>> 'Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_lookupByName0':
>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:106: 
>>> warning: initialization makes pointer from integer without a cast
>>> make[8]: *** [libsaproc.dylib] Error 1
>>> make[8]: *** Waiting for unfinished jobs....
>>> make[7]: *** [the_vm] Error 2
>>> make[6]: *** [product] Error 2
>>> make[5]: *** [generic_build2] Error 2
>>> make[4]: *** [product] Error 2
>>> make[3]: *** [all_product_universal] Error 2
>>> make[2]: *** [universal_product] Error 2
>>> make[1]: *** [hotspot-build] Error 2
>>> make: *** [build_product_image] Error 2
>>> can't find java into JDK 
>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/build/macosx-x86_64/j2sdk-image, 
>>> build failed
>>>
>>> Could you please advise how to fix this error?
>>>
>>> Thanks,
>>> Mikhail.
>

From mikhail.cherkasov at oracle.com  Thu Dec 27 04:02:56 2012
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 27 Dec 2012 16:02:56 +0400
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <50DC2C14.1090702@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com> <50DC2C14.1090702@oracle.com>
Message-ID: <50DC38F0.1070308@oracle.com>

Sending mail again, because I wasn't subscriber and email was holden for 
moderation.
I attached builds log file.

27.12.2012 15:08, Erik Joelsson ?????:
> Adding hotspot-dev to cc since it's failing in hotspot.
>
> On 2012-12-27 12:00, mikhail cherkasov wrote:
>> I attached builds log file.
>>
>> 27.12.2012 14:24, Erik Joelsson ?????:
>>> Hello,
>>>
>>> Which set of repositories did you clone?
>>>
>>> /Erik
>>>
>>> On 2012-12-26 14:16, mikhail cherkasov wrote:
>>>> Hi All,
>>>>
>>>> I have the following error during build:
>>>>
>>>> Linking vm...
>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:27:54: 
>>>> error: JavaNativeFoundation/JavaNativeFoundation.h: No such file or 
>>>> directory
>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m: 
>>>> In function 
>>>> 'Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_lookupByName0':
>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:106: 
>>>> warning: initialization makes pointer from integer without a cast
>>>> make[8]: *** [libsaproc.dylib] Error 1
>>>> make[8]: *** Waiting for unfinished jobs....
>>>> make[7]: *** [the_vm] Error 2
>>>> make[6]: *** [product] Error 2
>>>> make[5]: *** [generic_build2] Error 2
>>>> make[4]: *** [product] Error 2
>>>> make[3]: *** [all_product_universal] Error 2
>>>> make[2]: *** [universal_product] Error 2
>>>> make[1]: *** [hotspot-build] Error 2
>>>> make: *** [build_product_image] Error 2
>>>> can't find java into JDK 
>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/build/macosx-x86_64/j2sdk-image, 
>>>> build failed
>>>>
>>>> Could you please advise how to fix this error?
>>>>
>>>> Thanks,
>>>> Mikhail.
>>


From david.holmes at oracle.com  Thu Dec 27 04:27:11 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 27 Dec 2012 22:27:11 +1000
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <50DC38F0.1070308@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com> <50DC2C14.1090702@oracle.com>
	<50DC38F0.1070308@oracle.com>
Message-ID: <50DC3E9F.4060407@oracle.com>

The mailing lists strip most attachments. Your log file never made it.

Are you missing some OSX developer software?

David

On 27/12/2012 10:02 PM, mikhail cherkasov wrote:
> Sending mail again, because I wasn't subscriber and email was holden for
> moderation.
> I attached builds log file.
>
> 27.12.2012 15:08, Erik Joelsson ?????:
>> Adding hotspot-dev to cc since it's failing in hotspot.
>>
>> On 2012-12-27 12:00, mikhail cherkasov wrote:
>>> I attached builds log file.
>>>
>>> 27.12.2012 14:24, Erik Joelsson ?????:
>>>> Hello,
>>>>
>>>> Which set of repositories did you clone?
>>>>
>>>> /Erik
>>>>
>>>> On 2012-12-26 14:16, mikhail cherkasov wrote:
>>>>> Hi All,
>>>>>
>>>>> I have the following error during build:
>>>>>
>>>>> Linking vm...
>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:27:54:
>>>>> error: JavaNativeFoundation/JavaNativeFoundation.h: No such file or
>>>>> directory
>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:
>>>>> In function
>>>>> 'Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_lookupByName0':
>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:106:
>>>>> warning: initialization makes pointer from integer without a cast
>>>>> make[8]: *** [libsaproc.dylib] Error 1
>>>>> make[8]: *** Waiting for unfinished jobs....
>>>>> make[7]: *** [the_vm] Error 2
>>>>> make[6]: *** [product] Error 2
>>>>> make[5]: *** [generic_build2] Error 2
>>>>> make[4]: *** [product] Error 2
>>>>> make[3]: *** [all_product_universal] Error 2
>>>>> make[2]: *** [universal_product] Error 2
>>>>> make[1]: *** [hotspot-build] Error 2
>>>>> make: *** [build_product_image] Error 2
>>>>> can't find java into JDK
>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/build/macosx-x86_64/j2sdk-image,
>>>>> build failed
>>>>>
>>>>> Could you please advise how to fix this error?
>>>>>
>>>>> Thanks,
>>>>> Mikhail.
>>>
>

From mikhail.cherkasov at oracle.com  Thu Dec 27 04:41:07 2012
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 27 Dec 2012 16:41:07 +0400
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <50DC3E9F.4060407@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com> <50DC2C14.1090702@oracle.com>
	<50DC38F0.1070308@oracle.com> <50DC3E9F.4060407@oracle.com>
Message-ID: <50DC41E3.7060806@oracle.com>

I have installed all software from the following list:
http://wiki.se.oracle.com/display/JPG/Build+JDK+on+Mac+OS+X#BuildJDKonMacOSX-System
I not sure about X11 -does it require separate installation?

link to log: http://dl.dropbox.com/u/23235695/build_all.log

27.12.2012 16:27, David Holmes ?????:
> The mailing lists strip most attachments. Your log file never made it.
>
> Are you missing some OSX developer software?
>
> David
>
> On 27/12/2012 10:02 PM, mikhail cherkasov wrote:
>> Sending mail again, because I wasn't subscriber and email was holden for
>> moderation.
>> I attached builds log file.
>>
>> 27.12.2012 15:08, Erik Joelsson ?????:
>>> Adding hotspot-dev to cc since it's failing in hotspot.
>>>
>>> On 2012-12-27 12:00, mikhail cherkasov wrote:
>>>> I attached builds log file.
>>>>
>>>> 27.12.2012 14:24, Erik Joelsson ?????:
>>>>> Hello,
>>>>>
>>>>> Which set of repositories did you clone?
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2012-12-26 14:16, mikhail cherkasov wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I have the following error during build:
>>>>>>
>>>>>> Linking vm...
>>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:27:54: 
>>>>>>
>>>>>> error: JavaNativeFoundation/JavaNativeFoundation.h: No such file or
>>>>>> directory
>>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m: 
>>>>>>
>>>>>> In function
>>>>>> 'Java_sun_jvm_hotspot_debugger_bsd_BsdDebuggerLocal_lookupByName0':
>>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:106: 
>>>>>>
>>>>>> warning: initialization makes pointer from integer without a cast
>>>>>> make[8]: *** [libsaproc.dylib] Error 1
>>>>>> make[8]: *** Waiting for unfinished jobs....
>>>>>> make[7]: *** [the_vm] Error 2
>>>>>> make[6]: *** [product] Error 2
>>>>>> make[5]: *** [generic_build2] Error 2
>>>>>> make[4]: *** [product] Error 2
>>>>>> make[3]: *** [all_product_universal] Error 2
>>>>>> make[2]: *** [universal_product] Error 2
>>>>>> make[1]: *** [hotspot-build] Error 2
>>>>>> make: *** [build_product_image] Error 2
>>>>>> can't find java into JDK
>>>>>> /Users/mcherkasov/jdk/7ws/sources/openjdk7/build/macosx-x86_64/j2sdk-image, 
>>>>>>
>>>>>> build failed
>>>>>>
>>>>>> Could you please advise how to fix this error?
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail.
>>>>
>>


From joel.franck at oracle.com  Thu Dec 27 04:45:28 2012
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 27 Dec 2012 13:45:28 +0100
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <50D33301.2030400@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50D0A247.20502@oracle.com> <50D0F0DB.50900@oracle.com>
	<50D33301.2030400@oracle.com>
Message-ID: <E6D67382-230C-4D0C-8734-0719FFD8400F@oracle.com>

Thanks for the review Coleen!

cheers
/Joel

On Dec 20, 2012, at 4:47 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
> Looks good, Joel.
> Thanks,
> Coleen
> 
> On 12/18/2012 05:40 PM, David Holmes wrote:
>> Thumbs up.
>> 
>> David
>> 
>> On 19/12/2012 3:05 AM, Joel Borggr?n-Franck wrote:
>>> New webrev up:
>>> 
>>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/
>>> 
>>> - I had to rename the field name for the type annotation byte[] in
>>> Field, Constructor and Method.
>>> 
>>> Also fixed:
>>> 
>>> - I fixed the mapfile that got reindented.
>>> - Added back a comment that I accidentally removed.
>>> 
>>> cheers
>>> /Joel
>>> 
>>> On 12/17/2012 05:47 PM, Joel Borggr?n-Franck wrote:
>>>> Hi,
>>>> 
>>>> Here is a webrev for adding VM support for type annotation reflection:
>>>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v4/
>>>> 
>>>> Type annotations are coming with JDK 8, the proposed language changes
>>>> can be found from here:
>>>> http://openjdk.java.net/projects/type-annotations/
>>>> 
>>>> Since runtime visible type annotations probably won't be that common I
>>>> have tried to minimise overhead when there are no type annotations.
>>>> This is done by adding a pointer to a type annotation Annotations
>>>> instance from the regular annotations Annotations instance, see
>>>> annotations.hpp. This means that if there are no runtime visible
>>>> annotations there is no additional overhead with this patch since no
>>>> Annotations instance will be allocated at all. If there is runtime
>>>> visible annotations but no runtime visible type annotations there is
>>>> an additional overhead of 1 pointer with this patch. If you use type
>>>> annotations there will also be storage overhead, but that is to be
>>>> expected.
>>>> 
>>>> This patch also fixes that Annotations were never deallocated when
>>>> InstanceKlass::deallocate_contents() were called.
>>>> 
>>>> There is currently no redefineClass support for type annotations. This
>>>> will be added later. In order avoid ship possibly broken bytes to
>>>> java-land, type annotations are nulled out and deallocated after a
>>>> redefineClass.
>>>> 
>>>> This patch also exports a new method from jvm.h,
>>>> JVM_GetClassTypeAnnotations, so map files are updated. Build-dev are
>>>> included for review.
>>>> 
>>>> Testing done:
>>>> - vm.quick.testlis both on b67 and on a jdk that is patched with the
>>>> new fields to Field, Method and Constructor
>>>> - jprt full forrest build
>>>> - jdk_lang in both b67 and the patched jdk
>>>> - manual tests that we get the correct bytes out from the VM. These
>>>> tests can be added once some more changes have propagated from the jdk
>>>> repo
>>>> 
>>>> FYI, The initial set of jdk changes are being reviewed on
>>>> core-libs-dev:
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/013016.html 
>>>> 
>>>> 
>>>> cheers
>>>> /Joel
>>>> 
> 


From joel.franck at oracle.com  Thu Dec 27 04:57:39 2012
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 27 Dec 2012 13:57:39 +0100
Subject: RFR: 8004823: Add VM support for type annotation reflection
In-Reply-To: <E94E29C4-857A-4A88-B61A-AA6F0DE08275@oracle.com>
References: <D32D6525-F9BE-47F0-8138-D7B94E26477F@oracle.com>
	<50D0A247.20502@oracle.com>
	<E94E29C4-857A-4A88-B61A-AA6F0DE08275@oracle.com>
Message-ID: <8A89B42E-3357-4085-9EAC-62CDA90792EB@oracle.com>

Thanks for the review John!

I had this pushed before I saw this. I'll make sure to implement the checks when I start to implement retransform for  type annotations in the VM.

cheers
/Joel

On Dec 20, 2012, at 10:10 PM, John Rose <john.r.rose at oracle.com> wrote:

> This is good work.  You can count me as a reviewer.
> 
> One comment:  There are a couple of places where a field index is used as an annotation array index (one old one new).  I think it would be best to put an explicit range check like this:
> 
> -  if (md == NULL)
> +  if (md == NULL || index() >= md->length())
>     return NULL;
>   return md->at(index());
> 
> There are two reasons:  First, although it is likely this is a needless check, the code which ensures length equality for field arrays and annotation arrays is buried in another file (classFileParser) and hard to check.  Second, recent changes to classFileParser actually decouple the field array length from the value declared in the class file, by injecting extra fields into certain system classes.  Although it is (again) unlikely that this will cause a problem, putting a local range check in the code above guarantees an adequate level of safety.
> 
> The "at" method includes an assertion check, which is also good, but assertions are (a) not enabled in product mode and (b) can crash the VM if they fail.
> 
> ? John
> 
> On Dec 18, 2012, at 9:05 AM, Joel Borggr?n-Franck wrote:
> 
>> New webrev up:
>> 
>> http://cr.openjdk.java.net/~jfranck/8004823/webrev.v7/
>> 
>> - I had to rename the field name for the type annotation byte[] in Field, Constructor and Method.
>> 
>> Also fixed:
>> 
>> - I fixed the mapfile that got reindented.
>> - Added back a comment that I accidentally removed.
> 


From david.r.chase at oracle.com  Thu Dec 27 06:21:51 2012
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 27 Dec 2012 09:21:51 -0500
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <50DC41E3.7060806@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com> <50DC2C14.1090702@oracle.com>
	<50DC38F0.1070308@oracle.com> <50DC3E9F.4060407@oracle.com>
	<50DC41E3.7060806@oracle.com>
Message-ID: <DDAA35C4-3FD2-4EEE-827F-89B7F5C825CA@oracle.com>


On 2012-12-27, at 7:41 AM, mikhail cherkasov <mikhail.cherkasov at oracle.com> wrote:

> I have installed all software from the following list:
> http://wiki.se.oracle.com/display/JPG/Build+JDK+on+Mac+OS+X#BuildJDKonMacOSX-System
> I not sure about X11 -does it require separate installation?

Yes, X11 requires separate installation.
I think you need to get it from here,

http://xquartz.macosforge.org/landing/

though
the definitive answer on "where to get it"
and "where it gets installed" depends on
which version of MacOS you are running.
(I saw 10.7 in your logs.)




From mikhail.cherkasov at oracle.com  Thu Dec 27 08:41:09 2012
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 27 Dec 2012 20:41:09 +0400
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <DDAA35C4-3FD2-4EEE-827F-89B7F5C825CA@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com> <50DC2C14.1090702@oracle.com>
	<50DC38F0.1070308@oracle.com> <50DC3E9F.4060407@oracle.com>
	<50DC41E3.7060806@oracle.com>
	<DDAA35C4-3FD2-4EEE-827F-89B7F5C825CA@oracle.com>
Message-ID: <50DC7A25.7010908@oracle.com>

David,
I use OSX 10.7.5.
I installedX11 package. <http://xquartz.macosforge.org/landing/> But the 
build failed with the same error again:
http://dl.dropbox.com/u/23235695/build2.log - this log for jdk8
without closed part, but  I also tried to build jdk7 and received
  the same error too.

27.12.2012 18:21, David Chase ?????:
> On 2012-12-27, at 7:41 AM, mikhail cherkasov <mikhail.cherkasov at oracle.com> wrote:
>
>> I have installed all software from the following list:
>> http://wiki.se.oracle.com/display/JPG/Build+JDK+on+Mac+OS+X#BuildJDKonMacOSX-System
>> I not sure about X11 -does it require separate installation?
> Yes, X11 requires separate installation.
> I think you need to get it from here,
>
> http://xquartz.macosforge.org/landing/
>
> though
> the definitive answer on "where to get it"
> and "where it gets installed" depends on
> which version of MacOS you are running.
> (I saw 10.7 in your logs.)
>
>
>


From john.coomes at oracle.com  Thu Dec 27 20:31:52 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 28 Dec 2012 04:31:52 +0000
Subject: hg: hsx/hotspot-main: 10 new changesets
Message-ID: <20121228043153.86DE1473F4@hg.openjdk.java.net>

Changeset: fb1bf5e5bc9e
Author:    henryjen
Date:      2012-12-06 15:38 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/fb1bf5e5bc9e

8004685: add java.util.function to CORE_PKGS.gmk
Reviewed-by: mduigou

! common/makefiles/javadoc/CORE_PKGS.gmk

Changeset: e08b0096058f
Author:    lana
Date:      2012-12-14 11:22 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/e08b0096058f

Merge


Changeset: 8e36a0fabf58
Author:    ohrstrom
Date:      2012-12-18 09:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/8e36a0fabf58

8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes.
Reviewed-by: ohair, erikj

+ common/bin/hgforest.sh
! get_source.sh

Changeset: 51d3b65b8093
Author:    erikj
Date:      2012-12-18 17:54 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/51d3b65b8093

8001901: build-infra: Fix "misbehaving" which command on Solaris
Summary: Removed all uses of which in configure on solaris.
Reviewed-by: ohair

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

Changeset: 6ee8080a6efe
Author:    katleman
Date:      2012-12-19 13:36 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/6ee8080a6efe

Merge


Changeset: 32148e971ac8
Author:    katleman
Date:      2012-12-20 09:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/32148e971ac8

Added tag jdk8-b69 for changeset 6ee8080a6efe

! .hgtags

Changeset: 6b93e7a4401d
Author:    dholmes
Date:      2012-12-20 01:44 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/6b93e7a4401d

7190137: Add support for JVM_VARIANT minimal1
Summary: Allow configuration of minimal1 as a target VM along with client and server
Reviewed-by: ohair, erikj

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: cd06b2ea58dd
Author:    katleman
Date:      2012-12-20 16:22 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/cd06b2ea58dd

8004982: JDK8 source with GPL header errors
Reviewed-by: ohair

! common/makefiles/RMICompilation.gmk

Changeset: 105a25ffa4a4
Author:    katleman
Date:      2012-12-26 14:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/105a25ffa4a4

Merge


Changeset: 3fb32a5a2388
Author:    katleman
Date:      2012-12-27 12:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/3fb32a5a2388

Added tag jdk8-b70 for changeset 105a25ffa4a4

! .hgtags


From john.coomes at oracle.com  Thu Dec 27 20:31:57 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 28 Dec 2012 04:31:57 +0000
Subject: hg: hsx/hotspot-main/corba: 2 new changesets
Message-ID: <20121228043200.985BE473F5@hg.openjdk.java.net>

Changeset: 603cceb495c8
Author:    katleman
Date:      2012-12-20 09:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/603cceb495c8

Added tag jdk8-b69 for changeset 22ddcac208a8

! .hgtags

Changeset: 8171d23e914d
Author:    katleman
Date:      2012-12-27 12:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/8171d23e914d

Added tag jdk8-b70 for changeset 603cceb495c8

! .hgtags


From john.coomes at oracle.com  Thu Dec 27 20:32:06 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 28 Dec 2012 04:32:06 +0000
Subject: hg: hsx/hotspot-main/jaxp: 4 new changesets
Message-ID: <20121228043222.70CD6473F6@hg.openjdk.java.net>

Changeset: 27421008f050
Author:    katleman
Date:      2012-12-20 09:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/27421008f050

Added tag jdk8-b69 for changeset 789a855de959

! .hgtags

Changeset: a72c8391cdd6
Author:    katleman
Date:      2012-12-20 16:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a72c8391cdd6

8004982: JDK8 source with GPL header errors
Reviewed-by: ohair

! src/com/sun/org/apache/xalan/internal/XalanConstants.java
! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java

Changeset: 6ec9edffc286
Author:    katleman
Date:      2012-12-26 14:23 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/6ec9edffc286

Merge


Changeset: 63815efd132f
Author:    katleman
Date:      2012-12-27 12:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/63815efd132f

Added tag jdk8-b70 for changeset 6ec9edffc286

! .hgtags


From john.coomes at oracle.com  Thu Dec 27 20:32:26 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 28 Dec 2012 04:32:26 +0000
Subject: hg: hsx/hotspot-main/jaxws: 2 new changesets
Message-ID: <20121228043233.E2F1C473F7@hg.openjdk.java.net>

Changeset: 3b1c2733d47e
Author:    katleman
Date:      2012-12-20 09:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/3b1c2733d47e

Added tag jdk8-b69 for changeset 756323c99011

! .hgtags

Changeset: f577a39c9fb3
Author:    katleman
Date:      2012-12-27 12:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/f577a39c9fb3

Added tag jdk8-b70 for changeset 3b1c2733d47e

! .hgtags


From john.coomes at oracle.com  Thu Dec 27 20:34:00 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 28 Dec 2012 04:34:00 +0000
Subject: hg: hsx/hotspot-main/jdk: 49 new changesets
Message-ID: <20121228044351.566F5473F8@hg.openjdk.java.net>

Changeset: e8b54ae97344
Author:    jviswana
Date:      2012-12-12 13:28 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8b54ae97344

8004316: Printer - tempfile having incorrect extension
Reviewed-by: bae, jgodinez

! src/solaris/classes/sun/print/UnixPrintJob.java

Changeset: fd9e6b4c8488
Author:    lana
Date:      2012-12-14 11:21 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd9e6b4c8488

Merge


Changeset: c69424f78060
Author:    serb
Date:      2012-12-11 19:45 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c69424f78060

7154778: [macosx] NSView-based implementation of sun.awt.EmbeddedFrame
Summary: The new implementation of EmbeddedFrame to support SWT_AWT Bridge
Reviewed-by: anthony, serb, leonidr
Contributed-by: Petr Pchelko <petr.pchelko at oracle.com>

! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/PlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java
+ src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java
+ src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CWrapper.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/AWTSurfaceLayers.m
! src/macosx/native/sun/awt/AWTView.m
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CCursorManager.m
! src/macosx/native/sun/awt/CWrapper.m
! src/macosx/native/sun/awt/awt.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.m
! src/macosx/native/sun/osxapp/ThreadUtilities.h
! src/macosx/native/sun/osxapp/ThreadUtilities.m

Changeset: e016ad35a764
Author:    kshefov
Date:      2012-12-13 15:14 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e016ad35a764

7132385: [macosx] IconifyTest of RepaintManager could use some delay
Reviewed-by: serb, alexsch

+ test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java

Changeset: 71e03e17c183
Author:    kshefov
Date:      2012-12-14 13:32 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71e03e17c183

6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction
Reviewed-by: serb, alexsch

+ test/javax/swing/JInternalFrame/5066752/bug5066752.java

Changeset: 9fc7460ca3ac
Author:    lana
Date:      2012-12-14 11:22 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9fc7460ca3ac

Merge


Changeset: 7004848974a2
Author:    jgish
Date:      2012-12-04 20:21 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7004848974a2

8003596: TEST_BUG: java/util/logging/CheckLockLocationTest.java failing [win]
Reviewed-by: alanb

! test/ProblemList.txt
! test/java/util/logging/CheckLockLocationTest.java

Changeset: 44ae777564eb
Author:    mullan
Date:      2012-12-04 17:40 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44ae777564eb

8004188: Rename src/share/lib/security/java.security to java.security-linux
Reviewed-by: mullan, mchung
Contributed-by: jason.uh at oracle.com

! make/java/security/Makefile
- src/share/lib/security/java.security
+ src/share/lib/security/java.security-linux

Changeset: b54a5b7d2e65
Author:    alanb
Date:      2012-12-05 12:20 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b54a5b7d2e65

8004491: Build breakage on Linux due to 8004188
Reviewed-by: chegar, erikj

! makefiles/CopyFiles.gmk

Changeset: a971516029ab
Author:    jgish
Date:      2012-12-05 21:08 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a971516029ab

8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported
Reviewed-by: alanb, dmocek, smarks

! test/java/rmi/testlibrary/TestLibrary.java

Changeset: 41a1b110f34d
Author:    lancea
Date:      2012-12-06 15:51 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/41a1b110f34d

8004374: CachedRowSetSwriter.writeData reports wrong number of conflicts in SyncProviderException
Reviewed-by: naoto

! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java

Changeset: 896d4af2ebfd
Author:    rfield
Date:      2012-12-06 21:55 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/896d4af2ebfd

8003881: Prevent lambda implementing inner classes from allowing the creation of new instances
Summary: Lambda implementing inner classes now has private constructor (thanks Kumar)
Reviewed-by: ksrini

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
+ test/java/lang/invoke/lambda/LambdaAccessControlTest.java

Changeset: da387f0cecb7
Author:    ksrini
Date:      2012-12-09 07:43 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da387f0cecb7

8004042: Arrrghs.java test failed on windows with access error.
Reviewed-by: smarks, jjh, ksrini
Contributed-by: david.dehaven at oracle.com

! test/tools/launcher/Arrrghs.java
! test/tools/launcher/TestHelper.java

Changeset: 343615aa0539
Author:    dxu
Date:      2012-12-09 19:13 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/343615aa0539

7194370: (fs) WatchService fails if volume S/N is 0 [win]
Reviewed-by: alanb, forax

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

Changeset: fda257689786
Author:    okutsu
Date:      2012-12-10 10:52 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fda257689786

8000983: Support narrow display names for calendar fields
8003267: Support generic time zone names in TimeZoneNameProvider (SPI)
Reviewed-by: naoto

! make/tools/src/build/tools/cldrconverter/Bundle.java
! make/tools/src/build/tools/cldrconverter/BundleGenerator.java
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
! make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
! make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/spi/CalendarNameProvider.java
! src/share/classes/java/util/spi/TimeZoneNameProvider.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/be/FormatData_be.java
! src/share/classes/sun/text/resources/bg/FormatData_bg.java
! src/share/classes/sun/text/resources/ca/FormatData_ca.java
! src/share/classes/sun/text/resources/cs/FormatData_cs.java
! src/share/classes/sun/text/resources/da/FormatData_da.java
! src/share/classes/sun/text/resources/de/FormatData_de.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/es/FormatData_es.java
! src/share/classes/sun/text/resources/et/FormatData_et.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! src/share/classes/sun/text/resources/fr/FormatData_fr.java
! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/hu/FormatData_hu.java
! src/share/classes/sun/text/resources/is/FormatData_is.java
! src/share/classes/sun/text/resources/it/FormatData_it.java
! src/share/classes/sun/text/resources/iw/FormatData_iw.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/lt/FormatData_lt.java
! src/share/classes/sun/text/resources/lv/FormatData_lv.java
! src/share/classes/sun/text/resources/mk/FormatData_mk.java
! src/share/classes/sun/text/resources/ms/FormatData_ms.java
! src/share/classes/sun/text/resources/mt/FormatData_mt.java
! src/share/classes/sun/text/resources/nl/FormatData_nl.java
! src/share/classes/sun/text/resources/pl/FormatData_pl.java
! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! src/share/classes/sun/text/resources/ro/FormatData_ro.java
! src/share/classes/sun/text/resources/ru/FormatData_ru.java
! src/share/classes/sun/text/resources/sk/FormatData_sk.java
! src/share/classes/sun/text/resources/sl/FormatData_sl.java
! src/share/classes/sun/text/resources/sq/FormatData_sq.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/th/FormatData_th.java
! src/share/classes/sun/text/resources/tr/FormatData_tr.java
! src/share/classes/sun/text/resources/uk/FormatData_uk.java
! src/share/classes/sun/text/resources/vi/FormatData_vi.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java
+ test/java/util/Calendar/GenericTimeZoneNamesTest.java
+ test/java/util/Calendar/GenericTimeZoneNamesTest.sh
+ test/java/util/Calendar/NarrowNamesTest.java
+ test/java/util/Calendar/NarrowNamesTest.sh
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh
! test/java/util/PluggableLocale/barprovider.jar
+ test/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java
! test/java/util/PluggableLocale/providersrc/Makefile
! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: fda2b2b5b98b
Author:    michaelm
Date:      2012-12-10 14:56 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fda2b2b5b98b

8003948: NTLM/Negotiate authentication problem
Reviewed-by: chegar, weijun

! src/share/classes/sun/net/www/MessageHeader.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/MessageHeaderTest.java

Changeset: cac1bfaceaaa
Author:    mchung
Date:      2012-12-10 15:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cac1bfaceaaa

4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
Summary: Simple capitalization typo in LogManager() description
Reviewed-by: darcy, mchung

! src/share/classes/java/util/logging/LogManager.java

Changeset: 883feced1cdd
Author:    dingxmin
Date:      2012-12-11 10:42 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/883feced1cdd

6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Reviewed-by: chegar, dsamersoff

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

Changeset: d206e52bf8a6
Author:    weijun
Date:      2012-12-11 13:14 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d206e52bf8a6

8004488: wrong permissions checked in krb5
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
+ test/sun/security/krb5/auto/KeyPermissions.java
! test/sun/security/krb5/auto/KeyTabCompat.java

Changeset: c4bd81de2868
Author:    akhil
Date:      2012-12-11 15:33 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c4bd81de2868

8003246: Add InitialValue Supplier to ThreadLocal
Reviewed-by: mduigou, forax, dl, chegar, briangoetz

! src/share/classes/java/lang/ThreadLocal.java
+ test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java

Changeset: 6c795437f212
Author:    mduigou
Date:      2012-12-11 20:49 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c795437f212

8004905: Correct license of test to remove classpath exception
Reviewed-by: akhil

! test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java

Changeset: 12fba0974a9d
Author:    weijun
Date:      2012-12-12 18:39 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12fba0974a9d

8004904: Makefile for ntlm
Reviewed-by: erikj, chegar

! make/com/sun/security/Makefile
+ make/com/sun/security/ntlm/Makefile

Changeset: 806cf26e5063
Author:    chegar
Date:      2012-12-12 11:35 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/806cf26e5063

8004921: Trivial javadoc warnings in Base64
Reviewed-by: darcy

! src/share/classes/java/util/Base64.java

Changeset: 81640e75c7a7
Author:    alanb
Date:      2012-12-12 13:03 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/81640e75c7a7

8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener
Reviewed-by: ksrini, mchung, dholmes

! src/share/classes/com/sun/java/util/jar/pack/PropMap.java
! src/share/classes/java/util/logging/LogManager.java

Changeset: 346c0af4af41
Author:    mullan
Date:      2012-12-12 09:25 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/346c0af4af41

8004064: Downgrade normative references to ${java.home}/lib/security/java.security
Reviewed-by: alanb, vinnie, xuelei

! src/share/classes/com/sun/net/ssl/KeyManagerFactory.java
! src/share/classes/com/sun/net/ssl/TrustManagerFactory.java
! src/share/classes/com/sun/security/auth/PolicyFile.java
! src/share/classes/com/sun/security/auth/login/ConfigFile.java
! src/share/classes/java/net/doc-files/net-properties.html
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/Policy.java
! src/share/classes/java/security/Security.java
! src/share/classes/java/security/cert/CertPathBuilder.java
! src/share/classes/java/security/cert/CertPathValidator.java
! src/share/classes/java/security/cert/CertStore.java
! src/share/classes/javax/net/ssl/KeyManagerFactory.java
! src/share/classes/javax/net/ssl/TrustManagerFactory.java
! src/share/classes/javax/security/auth/Policy.java
! src/share/classes/javax/security/auth/callback/CallbackHandler.java
! src/share/classes/javax/security/auth/login/Configuration.java
! src/share/classes/javax/security/auth/login/LoginContext.java
! src/share/classes/javax/security/cert/X509Certificate.java

Changeset: c7f86908d5fd
Author:    mullan
Date:      2012-12-12 09:27 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c7f86908d5fd

Merge

- src/share/lib/security/java.security

Changeset: 68374c6e65c1
Author:    robm
Date:      2012-12-12 15:57 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/68374c6e65c1

8004337: java/sql tests aren't run in test/Makefile
Reviewed-by: lancea, alanb

! test/Makefile

Changeset: bd84d0927a2e
Author:    smarks
Date:      2012-12-12 09:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bd84d0927a2e

8004748: clean up @build tags in RMI tests
Reviewed-by: alanb, darcy, mchung

! test/java/rmi/MarshalledObject/compare/Compare.java
! test/java/rmi/MarshalledObject/compare/HashCode.java
! test/java/rmi/MarshalledObject/compare/NullReference.java
! test/java/rmi/Naming/DefaultRegistryPort.java
! test/java/rmi/Naming/LookupIPv6.java
! test/java/rmi/Naming/RmiIsNoScheme.java
! test/java/rmi/Naming/UnderscoreHost.java
! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java
! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java
! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java
! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java
! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java
! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java
! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java
! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java
! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java
! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh
! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java
! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java
! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java
! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java
! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java
! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java
! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java
! test/java/rmi/activation/Activatable/restartService/RestartService.java
! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java
! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java
! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java
! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java
! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java
! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java
! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java
! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java
! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java
! test/java/rmi/activation/CommandEnvironment/NullOptions.java
! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
! test/java/rmi/activation/checkusage/CheckUsage.java
! test/java/rmi/activation/log/LogTest.java
! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
! test/java/rmi/dgc/VMID/CheckVMID.java
! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java
! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java
! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java
! test/java/rmi/invalidName/InvalidName.java
! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java
! test/java/rmi/registry/checkusage/CheckUsage.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/interfaceHash/InterfaceHash.java
! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/registry/reexport/Reexport.java
! test/java/rmi/reliability/benchmark/runRmiBench.sh
! test/java/rmi/reliability/benchmark/runSerialBench.sh
! test/java/rmi/reliability/juicer/AppleUserImpl.java
! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java
! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java
! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java
! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java
! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java
! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
! test/java/rmi/server/RMIClassLoader/spi/Installed.java
! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java
! test/java/rmi/server/RMIClassLoader/spi/Property.java
! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java
! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java
! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java
! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java
! test/java/rmi/server/RemoteServer/AddrInUse.java
! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java
! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java
! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java
! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java
! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java
! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java
! test/java/rmi/server/Unmarshal/PrimitiveClasses.java
+ test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java
! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java
- test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java
! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java
! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java
! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java
! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java
! test/java/rmi/server/clientStackTrace/ClientStackTrace.java
! test/java/rmi/server/getRemoteClass/GetRemoteClass.java
! test/java/rmi/server/serverStackTrace/ServerStackTrace.java
! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java
! test/java/rmi/server/useCustomRef/UseCustomRef.java
! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java
! test/java/rmi/transport/checkFQDN/CheckFQDN.java
! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java
! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java
! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java
! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java
! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java
! test/java/rmi/transport/httpSocket/HttpSocketTest.java
! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java
! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java
! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
! test/javax/rmi/ssl/SocketFactoryTest.java
! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java
! test/sun/rmi/log/ReliableLog/SnapshotSize.java
! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java
! test/sun/rmi/rmic/newrmic/equivalence/run.sh
! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java
! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java
! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java
! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java
! test/sun/rmi/transport/proxy/EagerHttpFallback.java
! test/sun/rmi/transport/tcp/DeadCachedConnection.java
! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java
! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java

Changeset: 56fd5479a98f
Author:    jgish
Date:      2012-12-12 15:37 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/56fd5479a98f

8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win)
Summary: Failure to delete test log file should be a warning instead of test failure
Reviewed-by: mduigou, smarks

! test/java/util/logging/CheckLockLocationTest.java

Changeset: 5a2ab2c3f106
Author:    weijun
Date:      2012-12-13 08:11 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5a2ab2c3f106

8004235: Disable native JGSS provider on Mac
Reviewed-by: erikj, valeriep

! make/sun/security/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java

Changeset: 7a8978a5bb6e
Author:    lancea
Date:      2012-12-12 20:57 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7a8978a5bb6e

8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety
Reviewed-by: naoto

! src/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/share/classes/javax/sql/rowset/serial/SerialClob.java
! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java
! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java

Changeset: 775b0050144a
Author:    chegar
Date:      2012-12-13 09:55 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/775b0050144a

8004925: java/net/Socks/SocksV4Test.java failing on all platforms
Reviewed-by: alanb, dsamersoff

! test/java/net/Socks/SocksV4Test.java

Changeset: 682d2d3ccff5
Author:    chegar
Date:      2012-12-13 14:33 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/682d2d3ccff5

8004675: Inet6Address.getHostAddress should use string scope identifier where available
Summary: ...and some minor stylistic cleanup
Reviewed-by: khazra, dsamersoff, michaelm

! src/share/classes/java/net/Inet6Address.java
! src/share/native/java/net/Inet6Address.c
+ test/java/net/Inet6Address/StringScope.java

Changeset: c97618a3c8c2
Author:    juh
Date:      2012-12-13 09:35 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c97618a3c8c2

7193792: sun/security/pkcs11/ec/TestECDSA.java failing intermittently
Reviewed-by: vinnie, wetmore

! test/ProblemList.txt
! test/sun/security/pkcs11/ec/TestECDSA.java

Changeset: 7b697da6626a
Author:    mullan
Date:      2012-12-13 09:37 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7b697da6626a

Merge


Changeset: ae5d04dbacd6
Author:    chegar
Date:      2012-12-13 14:47 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ae5d04dbacd6

8003890: corelibs test scripts should pass TESTVMOPTS
Reviewed-by: chegar, alanb
Contributed-by: Mark Sheppard <mark.sheppard at oracle.com>

! test/com/oracle/net/sanity.sh
! test/com/sun/corba/cachedSocket/7056731.sh
! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh
! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh
! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh
! test/com/sun/tools/attach/ApplicationSetup.sh
! test/com/sun/tools/attach/BasicTests.sh
! test/com/sun/tools/attach/PermissionTests.sh
! test/com/sun/tools/attach/ProviderTests.sh
! test/com/sun/tools/extcheck/TestExtcheckArgs.sh
! test/demo/zipfs/basic.sh
! test/java/io/File/GetXSpace.sh
! test/java/io/File/MacPathTest.sh
! test/java/io/File/basic.sh
! test/java/io/FileOutputStream/FileOpen.sh
! test/java/io/Serializable/class/run.sh
! test/java/io/Serializable/evolution/AddedExternField/run.sh
! test/java/io/Serializable/evolution/RenamePackage/run.sh
! test/java/io/Serializable/maskSyntheticModifier/run.sh
! test/java/io/Serializable/packageAccess/run.sh
! test/java/io/Serializable/resolveClass/consTest/run.sh
! test/java/io/Serializable/resolveClass/deserializeButton/run.sh
! test/java/io/Serializable/subclass/run.sh
! test/java/io/Serializable/superclassDataLoss/run.sh
! test/java/io/Serializable/unnamedPackageSwitch/run.sh
! test/java/lang/Class/forName/NonJavaNames.sh
! test/java/lang/ClassLoader/Assert.sh
! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh
! test/java/lang/ClassLoader/getdotresource.sh
! test/java/lang/Runtime/exec/setcwd.sh
! test/java/lang/StringCoding/CheckEncodings.sh
! test/java/lang/System/finalization/FinExit.sh
! test/java/lang/annotation/loaderLeak/LoaderLeak.sh
! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh
! test/java/net/Authenticator/B4933582.sh
! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh
! test/java/net/InetAddress/ptr/lookup.sh
! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh
! test/java/net/Socket/OldSocketImpl.sh
! test/java/net/URL/B5086147.sh
! test/java/net/URL/runconstructor.sh
! test/java/net/URLClassLoader/B5077773.sh
! test/java/net/URLClassLoader/getresourceasstream/test.sh
! test/java/net/URLClassLoader/sealing/checksealed.sh
! test/java/net/URLConnection/6212146/test.sh
! test/java/net/URLConnection/UNCTest.sh
! test/java/nio/Buffer/LimitDirectMemory.sh
! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh
! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh
! test/java/nio/charset/Charset/default.sh
! test/java/nio/charset/coders/CheckSJISMappingProp.sh
! test/java/nio/charset/spi/basic.sh
! test/java/nio/file/Files/delete_on_close.sh
! test/java/nio/file/Files/walkFileTree/walk_file_tree.sh
! test/java/nio/file/Path/MacPathTest.sh
! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/reliability/benchmark/runSerialBench.sh
! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh
! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh
! test/java/security/Security/signedfirst/Dyn.sh
! test/java/security/Security/signedfirst/Static.sh
! test/java/security/cert/CertificateFactory/slowstream.sh
! test/java/util/Currency/PropertiesTest.sh
! test/java/util/Locale/LocaleCategory.sh
! test/java/util/Locale/LocaleProviders.sh
! test/java/util/PluggableLocale/ExecTest.sh
! test/java/util/ResourceBundle/Bug6299235Test.sh
! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh
! test/java/util/ServiceLoader/basic.sh
! test/java/util/TimeZone/OldIDMappingTest.sh
! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh
! test/java/util/prefs/CheckUserPrefsStorage.sh
! test/java/util/prefs/PrefsSpi.sh
! test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh
! test/java/util/zip/3GBZipFiles.sh
! test/java/util/zip/ZipFile/deletetempjar.sh
! test/javax/crypto/SecretKeyFactory/FailOverTest.sh
! test/javax/print/applet/AppletPrintLookup.sh
! test/javax/script/ProviderTest.sh
! test/javax/security/auth/Subject/doAs/Test.sh
! test/lib/security/java.policy/Ext_AllPolicy.sh
! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh
! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
! test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh
! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh
! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh
! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh
! test/sun/misc/Cleaner/exitOnThrow.sh
! test/sun/net/InetAddress/nameservice/dns/cname.sh
! test/sun/net/sdp/sanity.sh
! test/sun/net/www/MarkResetTest.sh
! test/sun/net/www/http/HttpClient/RetryPost.sh
! test/sun/net/www/protocol/file/DirPermissionDenied.sh
! test/sun/net/www/protocol/jar/B5105410.sh
! test/sun/net/www/protocol/jar/getcontenttype.sh
! test/sun/net/www/protocol/jar/jarbug/run.sh
! test/sun/rmi/rmic/manifestClassPath/run.sh
! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh
! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh
! test/sun/security/krb5/runNameEquals.sh
! test/sun/security/krb5/tools/ktcheck.sh
! test/sun/security/mscapi/AccessKeyStore.sh
! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh
! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh
! test/sun/security/mscapi/PublicKeyInterop.sh
! test/sun/security/mscapi/RSAEncryptDecrypt.sh
! test/sun/security/mscapi/ShortRSAKey1024.sh
! test/sun/security/mscapi/SignUsingNONEwithRSA.sh
! test/sun/security/mscapi/SignUsingSHA2withRSA.sh
! test/sun/security/pkcs11/KeyStore/Basic.sh
! test/sun/security/pkcs11/KeyStore/ClientAuth.sh
! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh
! test/sun/security/pkcs11/KeyStore/Solaris.sh
! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh
! test/sun/security/pkcs11/Provider/Login.sh
! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh
! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh
! test/sun/security/tools/jarsigner/emptymanifest.sh
! test/sun/security/tools/jarsigner/ts.sh
! test/sun/security/tools/keytool/printssl.sh
! test/sun/security/tools/keytool/standard.sh
! test/sun/security/validator/certreplace.sh
! test/sun/security/validator/samedn.sh
! test/tools/launcher/6842838/Test6842838.sh
! test/tools/launcher/MultipleJRE.sh

Changeset: 087425441a48
Author:    robm
Date:      2012-12-13 15:28 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/087425441a48

8000525: Java.net.httpcookie api does not support 2-digit year format
Reviewed-by: chegar

! src/share/classes/java/net/HttpCookie.java
! test/java/net/CookieHandler/B6791927.java
! test/java/net/CookieHandler/CookieManagerTest.java
+ test/java/net/HttpCookie/ExpiredCookieTest.java

Changeset: 8d7323a9d8ed
Author:    dholmes
Date:      2012-12-13 21:18 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d7323a9d8ed

8003632: HPROF class file version java.lang.RuntimeException errors
Reviewed-by: mchung, lancea

! src/share/javavm/export/classfile_constants.h

Changeset: de6b54a60d60
Author:    lana
Date:      2012-12-14 13:14 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/de6b54a60d60

Merge

! makefiles/CompileNativeLibraries.gmk
- src/share/lib/security/java.security
- test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java

Changeset: 4ea0ac8e02d2
Author:    erikj
Date:      2012-12-19 09:46 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4ea0ac8e02d2

8004803: build-infra: Cannot use icedtea as boot for closed build.
Summary: Set bootclasspath to javac and not the running jvm
Reviewed-by: ohair

! makefiles/CreateJars.gmk

Changeset: a8012d8d7e9c
Author:    katleman
Date:      2012-12-19 13:38 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8012d8d7e9c

Merge


Changeset: 4d5db5c038b4
Author:    katleman
Date:      2012-12-20 09:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d5db5c038b4

Added tag jdk8-b69 for changeset a8012d8d7e9c

! .hgtags

Changeset: 6b41b40526c6
Author:    amurillo
Date:      2012-12-21 10:27 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6b41b40526c6

Merge


Changeset: 1ad29569d6e9
Author:    erikj
Date:      2012-12-20 13:05 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ad29569d6e9

8005178: build-infra: Dependency on libfdlibm on mac is broken
Reviewed-by: tbell, ohair

! makefiles/CompileNativeLibraries.gmk

Changeset: a68090f0dc1a
Author:    katleman
Date:      2012-12-20 16:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a68090f0dc1a

8004982: JDK8 source with GPL header errors
Reviewed-by: ohair

! src/macosx/native/sun/font/CCharToGlyphMapper.m
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/Block.java
! src/share/classes/java/util/function/DoubleBlock.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBlock.java
! src/share/classes/java/util/function/LongBlock.java
! src/share/classes/java/util/function/Predicate.java
! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java
! src/share/classes/sun/tools/jcmd/JCmd.java
! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c
! src/solaris/native/common/jdk_util_md.h
! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c
! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java
! src/windows/native/common/jdk_util_md.h
! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java
! test/java/awt/Focus/6981400/Test1.java
! test/java/awt/Focus/6981400/Test2.java
! test/java/awt/Focus/6981400/Test3.java
! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java
! test/java/awt/JAWT/JAWT.sh
! test/java/awt/JAWT/Makefile.cygwin
! test/java/awt/JAWT/Makefile.unix
! test/java/awt/JAWT/Makefile.win
! test/java/awt/JAWT/MyCanvas.java
! test/java/awt/JAWT/myfile.c
! test/java/awt/JAWT/myfile.cpp
! test/java/awt/TextArea/DisposeTest/TestDispose.java
! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java
! test/java/awt/TextField/DisposeTest/TestDispose.java
! test/java/lang/Integer/Unsigned.java
! test/java/lang/Long/Unsigned.java
! test/java/lang/Math/CubeRootTests.java
! test/java/lang/Math/Expm1Tests.java
! test/java/lang/Math/HyperbolicTests.java
! test/java/lang/Math/Log10Tests.java
! test/java/lang/Math/Log1pTests.java
! test/java/lang/Math/Tests.java
! test/java/lang/StringBuffer/TestSynchronization.java
! test/java/lang/invoke/remote/RemoteExample.java
! test/java/math/BigDecimal/FloatDoubleValueTests.java
! test/java/math/BigDecimal/StrippingZerosTest.java
! test/java/net/Inet4Address/PingThis.java
! test/java/net/ProxySelector/MultiThreadedSystemProxies.java
! test/java/security/Signature/VerifyRangeCheckOverflow.java
! test/java/util/AbstractCollection/ToArrayTest.java
! test/java/util/Map/EntryHashCode.java
! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java
! test/java/util/logging/LoggerResourceBundleRace.java
! test/java/util/logging/LoggingDeadlock2.java
! test/java/util/logging/LoggingDeadlock3.java
! test/java/util/logging/SimpleFormatterFormat.java
! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml
! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml
! test/javax/swing/JComponent/7154030/bug7154030.java
! test/javax/swing/JTabbedPane/4310381/bug4310381.java
! test/javax/swing/JTable/4235420/bug4235420.java
! test/javax/swing/JTable/6788484/bug6788484.java
! test/javax/swing/JTable/7055065/bug7055065.java
! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java
! test/javax/swing/JTextArea/7049024/bug7049024.java
! test/javax/swing/border/Test7022041.java
! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java
! test/sun/management/AgentCMETest.java
! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh
! test/sun/nio/ch/SelProvider.java
! test/sun/rmi/rmic/classpath/RMICClassPathTest.java
! test/sun/security/krb5/auto/ReplayCache.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
! test/sun/tools/jps/jps-V_2.sh
! test/tools/jar/JarBackSlash.java
! test/tools/launcher/UnicodeTest.java

Changeset: 9dc1990c7d90
Author:    yhuang
Date:      2012-12-20 18:53 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9dc1990c7d90

7195759: ISO 4217 Amendment 154
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! src/share/classes/java/util/LocaleISOData.java
! src/share/classes/sun/util/resources/CurrencyNames.properties
! test/java/util/Currency/ValidateISO4217.java
! test/java/util/Currency/tablea1.txt
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: cbf255324369
Author:    yhuang
Date:      2012-12-23 19:11 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cbf255324369

Merge

- src/share/lib/security/java.security
- test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: a996b57e5541
Author:    katleman
Date:      2012-12-26 14:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a996b57e5541

Merge


Changeset: 8d7651351cfe
Author:    katleman
Date:      2012-12-27 12:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d7651351cfe

Added tag jdk8-b70 for changeset a996b57e5541

! .hgtags


From john.coomes at oracle.com  Thu Dec 27 20:46:33 2012
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 28 Dec 2012 04:46:33 +0000
Subject: hg: hsx/hotspot-main/langtools: 10 new changesets
Message-ID: <20121228044702.26A54473F9@hg.openjdk.java.net>

Changeset: c78acf6c2f3e
Author:    mcimadamore
Date:      2012-12-10 12:10 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c78acf6c2f3e

8004094: Javac compiler error - synthetic method accessor generated with duplicate name
Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/8004094/B.java
+ test/tools/javac/generics/8004094/T8004094.java

Changeset: fcf89720ae71
Author:    vromero
Date:      2012-12-10 16:21 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fcf89720ae71

8003967: detect and remove all mutable implicit static enum fields in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/classfile/Opcode.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java
! src/share/classes/com/sun/tools/javac/Server.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/TypeTag.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/ConstFold.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/main/Option.java
! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/javax/lang/model/element/Modifier.java
! src/share/classes/javax/lang/model/util/ElementFilter.java
! src/share/classes/javax/tools/StandardLocation.java
+ test/tools/javac/T8003967/DetectMutableStaticFields.java

Changeset: cfde9737131e
Author:    jjg
Date:      2012-12-11 15:05 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cfde9737131e

8004828: refactor init of *DocImpl classes
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java

Changeset: 170e486632d9
Author:    jlahoda
Date:      2012-12-12 20:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/170e486632d9

8004504: ListBuffer could reuse List.nil() as the sentinel element
Summary: ListBuffer.last now points to the last elements with client data, or null if none.
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/util/ListBuffer.java
+ test/tools/javac/util/list/ListBufferTest.java

Changeset: 376d6c1b49e5
Author:    jfranck
Date:      2012-12-03 11:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/376d6c1b49e5

8001114: Container annotation is not checked for semantic correctness
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java
! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out
! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out
+ test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java
+ test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out
! test/tools/javac/diags/examples/ContainedByNonDefault.java
+ test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java

Changeset: d7360bf35ee1
Author:    lana
Date:      2012-12-14 13:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d7360bf35ee1

Merge


Changeset: 2001991b1b40
Author:    katleman
Date:      2012-12-20 09:18 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2001991b1b40

Added tag jdk8-b69 for changeset d7360bf35ee1

! .hgtags

Changeset: 7d34e91f66bb
Author:    katleman
Date:      2012-12-20 16:24 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7d34e91f66bb

8004982: JDK8 source with GPL header errors
Reviewed-by: ohair

! make/Makefile-classic
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java
! test/tools/javac/StringsInSwitch/StringSwitches.java
! test/tools/javac/api/T6395981.java
! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
! test/tools/javac/diags/examples/DuplicateAnnotation.java
! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java
! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java
! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java
! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java
! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java
! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java
! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java

Changeset: 47f71d7c124f
Author:    katleman
Date:      2012-12-26 14:25 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/47f71d7c124f

Merge


Changeset: 7d5032c2d747
Author:    katleman
Date:      2012-12-27 12:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7d5032c2d747

Added tag jdk8-b70 for changeset 47f71d7c124f

! .hgtags


From staffan.larsen at oracle.com  Sat Dec 29 06:48:05 2012
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Sat, 29 Dec 2012 15:48:05 +0100
Subject: JDK7 build on mac os fails: JavaNativeFoundation.h: No such file
In-Reply-To: <50DC7A25.7010908@oracle.com>
References: <50DAF8C8.80603@oracle.com> <50DC21C7.8040708@oracle.com>
	<50DC2A60.4060505@oracle.com> <50DC2C14.1090702@oracle.com>
	<50DC38F0.1070308@oracle.com> <50DC3E9F.4060407@oracle.com>
	<50DC41E3.7060806@oracle.com>
	<DDAA35C4-3FD2-4EEE-827F-89B7F5C825CA@oracle.com>
	<50DC7A25.7010908@oracle.com>
Message-ID: <496686FB-D86F-46D4-BDA6-A52D719AA06B@oracle.com>

Can you find JavaNativeFoundation.h under /System/Library/Frameworks/JavaVM.framework/ somewhere? For me it is in /System/Library/Frameworks//JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/Headers/JavaNativeFoundation.h

If it isn't there, maybe installing a version of Apple's Java will add it? Or perhaps it is "Java for OS X 2012-006 Developer Package" from  https://developer.apple.com/downloads/index.action?name=Java%20Developer# that is needed. I remember vaguely installing something like this a long time ago, but can't remember exactly how this fit together...

/Staffan

On 27 dec 2012, at 17:41, mikhail cherkasov <mikhail.cherkasov at oracle.com> wrote:

> David,
> I use OSX 10.7.5.
> I installedX11 package. <http://xquartz.macosforge.org/landing/> But the build failed with the same error again:
> http://dl.dropbox.com/u/23235695/build2.log - this log for jdk8
> without closed part, but  I also tried to build jdk7 and received
> the same error too.
> 
> 27.12.2012 18:21, David Chase ?????:
>> On 2012-12-27, at 7:41 AM, mikhail cherkasov <mikhail.cherkasov at oracle.com> wrote:
>> 
>>> I have installed all software from the following list:
>>> http://wiki.se.oracle.com/display/JPG/Build+JDK+on+Mac+OS+X#BuildJDKonMacOSX-System
>>> I not sure about X11 -does it require separate installation?
>> Yes, X11 requires separate installation.
>> I think you need to get it from here,
>> 
>> http://xquartz.macosforge.org/landing/
>> 
>> though
>> the definitive answer on "where to get it"
>> and "where it gets installed" depends on
>> which version of MacOS you are running.
>> (I saw 10.7 in your logs.)
>> 
>> 
>> 
>